No, don't, unless you want bad things to happen when a whole bunch of corner cases start sprouting up. I did this for a while and ultimately gave up after seeing the error rate spike on my server. There are lots of people out there using stuff which just does not get the protocol-independent // scheme. I went back to doing either the whole thing (http[s]://host/path) or a relative thing (/path) but nothing in-between.

http://rachelbythebay.com/w/2012/09/15/rel/

I disagree with your conclusion. The fewer sites this works with, the quicker developers will fix it. Supporting the wrong way is not the right thing to do.

Your two viewpoints are reconcilable, I think.

From the standpoint of the individual developer, you handle edge cases like this so you don't break your clients' experience.

From the standpoint of the ecosystem, broken tools are bad, and they cause individual developers to have to handle more edge cases.

If one individual developer doesn't handle these edge cases, their clients will just think they are bad. If all of the individual developers decided not to handle these edge cases in a coordinated fashion, sure, they could trigger a change. But I don't think that's how it happens in the real world.

To look back on the days of IE6/IE7, most developers didn't just stop supporting these browsers and hope that their clients would stop using them; they supported the browsers until larger forces caused their clients to shift to newer browsers.

Getting back to my original point, I think it's possible for each of you to have the viewpoints that you have, but also for rachelbythebay to say, "Sure, if I could coordinate with all other devs to stop handling broken edge cases at the same time, I would do that," and for you to say, "Sure, I can see how you would want to keep your job and handle edge cases until they are fixed upstream."

I half-agree with rachelbythebay's position, but, in my experience, users will definitely say "hey, this site doesn't work with your service", the developer investigates and fixes it. It'd also probably be worth it to just email the devs of the service, it'd probably get fixed a significant proportion of the time.

> The fewer sites this works with, the quicker developers will fix it.

That turned out really well in the past.

Yeah, online services, desktop software, it's equally hard to upgrade both.

We are running one of the largest sites in the Netherlands with protocol-independend css/js/img: http://www.marktplaats.nl/ Haven't heard real complaints from the users about broken things. Probably anecdotal but it saves quite some complexity

And in your spare time you are one of the best Dutch cartoonists around?

What kind of "stuff"?

IE7 and IE8 will download stylesheets that use protocol relative urls twice.

http://stackoverflow.com/questions/4831741/can-i-change-all-...

But only for uncached resources - see Eric Lawrence's comment:

“Internal to Trident, the download queue has “de-duplication” logic to help ensure that we don’t download a single resource multiple times in parallel.

Until recently, that logic had a bug for certain resources (like CSS) wherein the schema-less URI would not be matched to the schema-specified URI and hence you’d end up with two parallel requests.”

http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem...

You could use a resource loader if you really cared but with IE8 under 10% and dropping I'd recommend keeping your site clean and maintainable – anyone using IE8 at this point is used to the web being slow and ugly so something like this will be the least of their worries.

IE certainly has strangest of bugs.

You really care about that? Well, relative URLs (and maybe using a basename meta tag) might be a workaround. But seriously, I wouldn't care about these Microsoft's bugs.

If this is a concern, you've made some very poor decisions.

What about large assets, like big splash images? Those can be quite a bandwidth hog.

EDIT: from the post, IE8 only downloads stylesheets twice. Nevermind.

Like what? Supporting ie 7 & 8? Using relative urls?

like worrying about twice as many hits to stylesheets (which are typically static content)

It's cached by URL, so I would assume (but haven't tested) that a different protocol would be cached separately.

From a security perspective it certainly should be.

Why not just use https:// ?

That way, if you load the file using file:// it will still work. Any downsides?

You will often need to dynamically generate all URLs depending on the current state of the page. A common example is an econmerce site where normal pages are HTTP, but things like the shopping cart and checkout are HTTPS. Your template will need to know to load resources as HTTPS when on a secure page. It's not the end of the world, but certainly annoying.

And are there any considerations nowadays to not just run the whole site under HTTPS?

Many CDNs charge a lot (10x for all bandwidth, including non secure) for https. If you are fronting one of your sites with these, it is not economically viable to switch over.

A shame many linkification scripts won't support this in editors, though: //news.ycombinator.com/item?id=5514784.

Does anyone have any experience writing regex for this?

Just always use the https version then. There is nothing wrong in embedding https resources in http. `//` is just shorter and more flexible (e.g. you could switch of ssl if you want).

Hint: Local testing/loading of html files might require a local server then, since file:// is then used for resources, too, and this is rather problematic.

You'll have to explain why local servers are problematic. More like file:// is.

Well, if you double-click on a html file on your computer, it will open that in your browser using file://. If you use the short `//example.com/foo.bar`, it is quite problematic.

`//fonts.googleapis.com/css` becomes `file://fonts.googleapis.com/css` → doesn't work

Additionally, JavaScript files might not load or work due to browsers' (security) limitations. Not sure about the exact details here.

Definitely sounds like file:// is problematic, then.

Using a local server (instead of file:// access) would be a solution to that problem, not another problem.

That's not great...

A lot of folks get started editing HTML by downloading an existing page, editing it in some small way, and viewing the resulting page to see if it worked.

This would break that approach.

I agree, and I think not just for novice people editing HTML pages. Being able to load HTML pages locally, or send them in a zip file is important some times.

When I built Giraffe[1], a front-end for Graphite, one of my aims was that people can launch the dashboard from their desktop, then add dashboards to it by editing one file locally. So most of these people will use a server one day, but forcing them to launch a local server before they even start, really decreases the ability to play with it instantly and try it out... the code in giraffe's index.html needs to work both on the server and locally.

I already experienced strange behaviour with loading JSON/JSONP from a file:// based url, and I know it's an edge case, but it's still a useful use-case in my opinion.

[1]http://kenhub.github.io/giraffe

Firefox saves all assets to a _files directory then fixes the URLs to point in there.

If you really, really want to use //:

  busybox httpd -p 8080

or python -m SimpleHTTPServer 8080

Hell, even new PHP comes with a packaged local dev server.

But it would suck that you'd have to launch a server just to view an HTML file locally... (actually, the problem is already here for some time, thanks to JS requiring protocols to match to fetch data).

It's not file:// that's problematic, it's that you're using relative protocol URLs without an actual server to be relative to

Guy, you haven't got this right.

Good thing Tim-Berners Lee put two slashes in there.

Not only are even smart people sometimes wrong about stuff, they're wrong about when they're wrong about stuff.

If there were zero or one slashes there, we could use urls starting with a colon for the same purpose.

I agree that using protocol relative URLs is the way to go, but there is one particular situation to watch out for: if the user saves the page to disk and opens it again then // will become file:// and all relative links will be broken.

So on something like an "invoice" page that the user is likely to want to save you may not want to do that (or use a piece of javascript to rewrite the links dynamically)

Egad! Yet another edge case to remember.

  some still don't...

Most still don't!

Annoyingly there's an obnoxious popup on IE6 when doing this

http://paulirish.com/2010/the-protocol-relative-url/

Not using protocol relative urls causes a great amount of pain. Unfortunately when you're building content for third party pages you need more graceful degradation than focus stealing dialogues.

Unless you are supporting China, IE6 usage is below 1% in virtually all countries: https://news.ycombinator.com/item?id=5511627

That article says the problem is with the way SSL is set up on the host in the example, not with scheme relative URIs.

No, protocol relative URLS work fine in IE6. (The article you linked to doesn't say they don't)

>and they don't redirect properly

You can't redirect SSL > non-SSL without a browser warning though, right? Unless you get a cert, at which point you may as well put it to use.