While these points are valid, and indeed very insightful in some cases (the logging / encryption issue hadn't even occurred to me before now), I do wonder if the author would ever be happy. Using bleeding edge features will always cause cross-browser problems like this, no matter what year you're in, no matter which browsers are currently popular, no matter how useful the features are. The other way to look at it is that every single year, there are more things you can safely use than the year before. In 5 years time when 95% of your users support all of the features he mentions, will he be rejoicing, or complaining that HTML6 support is spotty?
Also worth mentioning that for some of the issues (like differences in cross-domain feature detection) they should really be handled by libraries to abstract the differences between underlying browsers from the point of view of your business code. Browsers will always have differences, fix the problem once and abstract it away!
> Using bleeding edge features will always cause cross-browser problems like this
Well, the problem is that these aren't bleeding edge features. FileSystem API is the most bleeding of all mentioned and that's been in stable Chrome for almost a year. The others have been available in some combination of stable browsers for multiple years. (And most were specced 3+ years ago)
Compare this sort of behavior with something like Windows Metro, iOS, Android, where apps are using newly introduced APIs within weeks of release, and I think he's justified in wanting better compatibility out of the web platform.
This post does an excellent job of explaining, unintentionally, why the decision to remove version numbers from HTML was a bad idea. There are so many new technologies being worked on and browser vendors all have different priorities on which to put resources on implementing.
Think about if HTML5 had been finalized in 2010, with anything proposed in 2011 or 2012 be considering HTML6 (or HTML5.5 or whatever -- who cares). Wouldn't there be a lot of pressure on browser vendors to support all HTML5 features? As it stands today no one can possible keep up with standardization so instead vendors work on what they think is important -- or cynically what will get them the most recognition.
Removing version numbers simply exposed how HTML evolves explicitly, browser vendors will never be forced to implement a particular web standard, they all have their own agenda and goals, while that may bring problems, this fuzzy concencus is the reason web standards are as ubiquitous as they are, and still evolving at a huge pace.
Putting a version number on a specification and dictating that all vendors must implement it by X date (or what?) is just confusing developers about the chaotic way in which standards are built.
Very few developers are even aware that version numbers were removed so I don't think it's had any real effect on developer confusion. It's probably made it worse. This article complains about WebWorkers which was proposed in 2009 but with the way standards evolve it's hard to know what capabilities it has. Meanwhile Firefox has a solid implementation of CSS calc() but not WebWorkers (which I believe they came up with).
In my experience it has helped reduce confusion, I dont see how it could possibly make it worse, unless you count the confusion as developers begin to realise how the web evolves as 'worse', I dont.
As said, browser vendors are have no governing body that force them to implement exact specifications at exact times, I dont see how putting a version number on html and pretending that they do is anything but confusing.
Version numbers do little to prioritize engineering work. Take CSS 2.1, which still doesn't have 100% conformance by any browser: http://test.csswg.org/suites/css2.1/nightly-unstable/report/... and the CSSWG is now working on many CSS Level 4 specs now...
The demands of application developers are much of what drives feature prioritization inside browser developers. Scores and benchmarks certainly contribute, but it'd temper that a bit.. see the recent Maxthon kerfuffle on how browser's have their feet held to the fire on their scores: http://www.favbrowser.com/maxthon-scams-its-score-in-html5te...
Sorry if you took my comment as the implication that version numbers don't matter; they certainly do. But the relationship between specifications and browsers is complex.. My point is only that putting version numbers (instead of timestamped commits) on a spec doesn't assist browser makers.
Specification test suites are really our greatest hope at early cross-browser compatibility and right now they're not in a great state. See also testthewebforward.org which aims to assist this (and movethewebforward.org which birthed it)
> instead vendors work on what they think is important --
> or cynically what will get them the most recognition.
This was always the case and exactly the reason for the removal of version number.
I am not even sure if any browser has a full implementation of HTML4 (most likely not).
"Only IE10 is really comparable with ‘modern browsers’ and that won’t even run on anything older than Windows 8." - actually it will run on Windows 7 too, but not Vista[1].
Fully agree with your comments (although not particularly with the indexedDB ones)
I see the problem is that we have built up the web to be a place to trust software, while someone may be able to steal my password, I know that a web app isnt going to be able to wipe my hard drive. That is mostly because right now web apps have little privileges to actually do anything (and even with those little privileges we have still been plagued with xss / csrf attacks)
I fully agree that we need to have lower level API's in place so users can build technology from the bottom up, but I think before that happens we need to build the parts of the platform that allow that access without leaving users open to abuse.
This is happening right now with b2g, since it has a mail client there is mozTcpSocket being exposed, however obviously not every web app is going to have access, and afaik it will only be exposed to signed / trusted applications. But I am excited to see the ball rolling.
Do what the company I worked for did. Slap a works best in Chrome next to the link (it works okay in Firefox too, but no reason to confuse users more), and any user who attempts to lock on with an IE browser less than 9 gets a 'you need to install this plugin to continue' and then they have Chrome Frame.
The web didn't move past it for all the years it required flash to be installed to run games.
Now we are talking about installing a different plugin to run games (but only if you use a certain browser). So this is an improvement on the status quo regarding web games.
I figured someone would complain. The reason is simple -- our users are normal people and there is no reason to suggest that they first compare Opera, Safari, Firefox and Chrome and then select the one that best fit their needs.
But it sounds like this is exactly like those kludges.
Instead of detecting which browser the user has and saying "best viewed in X" where X is some other browser, how about detecting which features you need, and then giving a clear error on which were missing? This is better in many ways, for example if the next update to a browser adds the missing features to it, then it will just work on your site.
What would confuse them? You can customize the warning message to be as clear as you want. The benefit your users get is your page will actually work the second their browser can support it, not when you officially define browser X to be "acceptable".
Article starts off complaining that IE8 doesn't have EcmaScript 5 support, when ES5 was finalized after IE8 came out. Not exactly a winner on detail here... Much of the stuff he complains about not having access to is a working draft or non-standardized browser-specific API.
people have been saying since about 2008 (and before) that Flash has a diminishing future to HTML5. it bugs me. heres why
the fundamental problem with "Javascript", or as it truly is, "Every Different Web Browsers Custom Implementation of ECMASCRIPT 4", is that it will never be the same across all browsers and all versions. period. any app done in HTML5 will ALWAYS take extra development time and upkeep compared to code in Actionscript and Flash. Period.
Also worth mentioning that for some of the issues (like differences in cross-domain feature detection) they should really be handled by libraries to abstract the differences between underlying browsers from the point of view of your business code. Browsers will always have differences, fix the problem once and abstract it away!