The Pain of HTML5(blog.caplin.com)
blog.caplin.com
The Pain of HTML5
http://blog.caplin.com/2012/07/16/the-pain-of-html5/
11 comments
> 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.
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.
I don't think that new APIs are readily available to most users within weeks on Windows Metro or Android.
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.
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.
Disagree entirely
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.
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.
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.
Yea, I am thinking "HTML5" even as a buzzword is a misnomer:
http://news.ycombinator.com/item?id=4238188
http://news.ycombinator.com/item?id=4238188
And as for people keeping up what works and what doesnt, we need to make sure that everyone knows about resources like http://caniuse.com/
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...
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...
> Version numbers do little to prioritize engineering work.
Then the problem is bigger, because in the larger software world version numbers are used and matter.
Then the problem is bigger, because in the larger software world version numbers are used and matter.
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)
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.
"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].
[1] http://msdn.microsoft.com/en-us/library/ie/hh673549(v=vs.85)...
[1] http://msdn.microsoft.com/en-us/library/ie/hh673549(v=vs.85)...
Here are links re: HTML5 implementations and shortcomings:
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...
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...
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.
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.
What does Tim mean by "node.js code trusted apps"?
Wouldn't this be better titled "The Pain of Modern JavaScript"?
I'll admit I skimmed the article, but I couldn't find anything about HTML.
I'll admit I skimmed the article, but I couldn't find anything about HTML.
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.
I work for a casual gaming company.
I work for a casual gaming company.
> Slap a works best in Chrome next to the link (it works okay in Firefox too, but no reason to confuse users more)
Hasn't the web moved past "Best viewed in X"..? Please don't do that.
Hasn't the web moved past "Best viewed in X"..? Please don't do that.
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.
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.
I don't think "Best viewed in X" is a problem when you're trying to force people to use standards-compliant, modern browsers.
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".
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".
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.
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.
That would confuse our users when there is no reason to.
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.
It works in more than two different browsers, which makes it a defacto standard.
The real reason is that W3C is way too slow in standarlizing these things. It shouldn't take nearly as long.
The real reason is that W3C is way too slow in standarlizing these things. It shouldn't take nearly as long.
"Variety of offline storage options, all insecure" -- true, and annoying.
flash developer here
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...
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...
This sounds more like a wish-list then anything.
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!