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.
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.
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.
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).
