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.