"It seemed like a good idea at the time": Berners-Lee 'sorry' for slashes

You need the slashes. Otherwise how do you differentiate between: site:port/file (example.com:8080/myfile.htm) and protocol:site/file (http:example.com/myfile.htm) ? You could guess, based on where the full stops are, what's a numeric, etc. But you wouldn't be sure. Having dots for one separator, slashes for another and a double slash for the third makes it entirely clear where the breaks are.

It's a smug joke!<p>It's like Ritchie being asked what was the main fault in the C language - he said the 'CREAT' flag to open() should have been 'CREATE'

But them slashdot would have been colondot. Somehow it doesn't work as well.

Actually, the double slash is useful for at least one thing. You can use it in web pages to make relative URLs which preserve the protocol, but change the server.<p>Suppose you have pages on a server www.example.com that reference images on an asset host assets.example.com. Usually, you would use a full URL in your HTML to reference your images:<p><a href="http://assets.example.com/image.png" rel="nofollow">http://assets.example.com/image.png</a><p>This is fine if all your accesses to www.example.com are done over HTTP. But what if you want to use HTTPS sometimes? Unless you change those URLs to use the HTTPS protocol as well, the browser may give the 'mixed secure and insecure content' warning.<p>If you specify the image URLs as relative URLs in the form:<p>//assets.example.com/image.png<p>then when a user visits <a href="http://www.example.com/" rel="nofollow">http://www.example.com/</a> their browser will fetch the image from <a href="http://assets.example.com/image.png" rel="nofollow">http://assets.example.com/image.png</a> . But when they visit <a href="https://www.example.com/" rel="nofollow">https://www.example.com/</a> their browser will fetch the image from <a href="https://assets.example.com/image.png" rel="nofollow">https://assets.example.com/image.png</a> .<p>Without the double slash, this kind of relative URL would be indistinguishable from the more common relative URL which just means a different path on the same server:<p>/assets.example.com/image.png

I was completely oblivious to the // being a problem at all. Since it isn't necessary for &#62;99% of non-geeky url usage, it only comes up once, when I explain that browsers are pretty smart and that part is optional with a couple of exceptions... and that is it.<p>Weird.

It's an implementation detail. It's not the "//" that matters, it's that web browsers weren't offering reasonable abstractions; so this weird detail affected more people than it should have.<p>These days, you can type "foobar" instead of <a href="http://www.foobar.com/" rel="nofollow">http://www.foobar.com/</a> in any browser, and it works. The "//" isn't a big deal.<p>There's more that browsers could be doing. Why ever display "&#60;anything&#62;://" in a browser, when it could be a menu of protocols?

What someone really needs to apologise for is making the order of "least to most specific term" go from right-to-left in a domain name and left-to-right in the path component of a URL.

I saw this story/fluff and didn't even think it was worthy of bbc, but they have been grasping at straws lately!<p>It amounts to: "OMG! Tim speekz!"

And what about having superfluous www-prefix in hostnames?