The Pain of HTML5
blog.caplin.com
blog.caplin.com
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!
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.
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.
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.
> instead vendors work on what they think is important --
> or cynically what will get them the most recognition.
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...
Then the problem is bigger, because in the larger software world version numbers are used and matter.
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)
[1] http://msdn.microsoft.com/en-us/library/ie/hh673549(v=vs.85)...
Browser vendors approach to innovation in the browser is top-down rather than bottom-up: http://news.ycombinator.org/item?id=4233711
Poor WebSocket, IndexedDB implementations: http://news.ycombinator.org/item?id=4067779 and http://news.ycombinator.org/item?id=3642764
Lack of integration with native applications: http://news.ycombinator.org/item?id=3642734
And, Tim Berners-Lee on giving power to web apps, if we can't give power, they can't compete: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
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.
I'll admit I skimmed the article, but I couldn't find anything about HTML.
I work for a casual gaming company.
Hasn't the web moved past "Best viewed in X"..? Please don't do that.
What made it a problem in the past is that people would rely on weird, kludgy, non-standard behavior of Browser X and slap on a "Best viewed in X".
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.
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.
The real reason is that W3C is way too slow in standarlizing these things. It shouldn't take nearly as long.
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, Javascript will always be a mess.
TL;DR: i'm not going anywhere anytime soon...