The Pain of HTML5

http://blog.caplin.com/2012/07/16/the-pain-of-html5/

by sprogcoder • 14 years ago

67 31 14 years ago

blog.caplin.com

This sounds more like a wish-list then anything.

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

jasonhanley• 14 years ago

"Variety of offline storage options, all insecure" -- true, and annoying.

MatthewPhillips3• 14 years ago

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.

daleharvey4• 14 years ago

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.

daleharvey4• 14 years ago

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/

MatthewPhillips3• 14 years ago

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

rimantas• 14 years ago

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

paulirish3• 14 years ago

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

MatthewPhillips3• 14 years ago

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

_urga• 14 years ago

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

daleharvey4• 14 years ago

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.

eevilspock• 14 years ago

What does Tim mean by "node.js code trusted apps"?

ZoFreX• 14 years ago

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!

paulirish3• 14 years ago

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

_ea1k• 14 years ago

I don't think that new APIs are readily available to most users within weeks on Windows Metro or Android.

mikegirouard• 14 years ago

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.

tomjen34• 14 years ago

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.

azakai3• 14 years ago

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

azylman• 14 years ago

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

tomjen34• 14 years ago

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.

slurgfest• 14 years ago

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.

kevingadd• 14 years ago

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.

tomjen34• 14 years ago

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.

nicetryguy• 14 years ago

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

The Pain of HTML5

Related Stories