Protocol-relative URL in CSS for multiple subdomains

Question

Our php-driven website has recently added ssl certificates to support the https protocol and we are having problems with IE6 through IE8 although our pages do not have resources called through http.

I have read this post : http://paulirish.com/2010/the-protocol-relative-url/

So, basicaly, I need to replace all the

background: url('/images/whatever.gif');

With :

background: url('//www.mydomain.com/images/whatever.gif');

I'm not quite a fan of using my domain name across several hundred css files to start with, but suppose I do : what would be the best practice to do so for my development, test and staging environments which are all on different subdomains than the production site. I would need to use dynamic representations of the domain name in the css files, most probably driven from some sort of config file, but how ?

Answer 1

You don't have to add your hostname to use protocol-relative URLs. The form you're already using is protocol-relative, because it doesn't specify a protocol.

Can you detail the problems you are having? Have you confirmed with a test that the URL with a domain name will solve your problem?

PS: If you have hundreds of CSS files, you'll probably be happier with a dynamic generation system anyway, but that's a separate matter.

Answer 2

The problems are popups in IE6, 7, 8 that say there is mixed content in the page (which should be http resources included in an https page). Chrome, FF4 and up and IE9 do not show those popups, and this is correct. There are no http included resources.

Several blog posts seem to point to background urls as the source of this problem. One of the posts (http://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-mixed-content-in-ie8.aspx) has a comment from Eric Law at MSFT, who states :

The debugger reports that the following is the URL that is triggering the prompt:

"about:/images/lightview/inner_slideshow_play.png"

Of course, that URL doesn't actually exist in your markup. It looks like there's dynamic creation of an IFRAME and injection of content into that frame. The default URL for an empty frame is about:blank, which leads to the prompt.

and ...

Other quirks to be aware of: In IE6, we treat "about:blank" as insecure content, as well as "javascript:" and "res:". In IE7, we fixed the "about:blank" case, but we have not (yet) changed javascript and res.

So the problem is known and confirmed by MSFT for their older browsers, which create an IFRAME and inject content that then generates the error.

Most workarounds I have stumbled upon point to using protocol-relative urls, like in the first url I showed. I'm not sure you can consider 'background: url('/images/whatever.gif');' as a protocol-less call, because of this infamous IE6 to 8 bug.

--Edit : Working on a solution. We have found this in our javascript files and it seems it has been the real problem from the beginning :

<input target="_blank"class="sub" type="button" style="background-image:url(../images/name.gif);">