The // prefix is actually used for protocol-relative URLs. So //google.com leads to https://google.com on a page with SSL, and it leads to http://google.com on an unencrypted page.
See:
See:
And you can't be sure. Here's why: if someone saves your page on their hard drive and you're using protocol-relative URLs, the implied "http" just became "file". (Which in fact may be a nice excuse for some clever hacks.)
Test it yourself! Save the following snippet to your computer and see how your browser resolves the URL:
<!DOCTYPE html>
<title>Testing 1 2 3</title>
<p><a href="//google.com/">Linky</a></p>I'm saying that those who need to worry about such things should and the rest of us should not. Nothing more and nothing less.
http://dev.w3.org/html5/spec/Overview.html#the-base-element
And accordingly, adding `<base href="http://example.com/ >` to that test above seems to work well on modern browsers.
A "//" link in an HTTPS site would be required to be the same protocol anyway. It's only the spdy->http fallback that could prove to be a nuisance.
// has another meaning in XML XPath, a language for navigating XML documents. // selects nodes anywhere in a document. For example, //p would select all paragraphs in an XHTML page.
I don't have a copy of IE6 to test on at the moment, but what makes you think IE8 is required for relative protocols?