
The Pain of HTML5 - sprogcoder
http://blog.caplin.com/2012/07/16/the-pain-of-html5/
======
ZoFreX
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!

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

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

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

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

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

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

~~~
yuhong
Yea, I am thinking "HTML5" even as a buzzword is a misnomer:

<http://news.ycombinator.com/item?id=4238188>

------
AshleysBrain
"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)...](http://msdn.microsoft.com/en-
us/library/ie/hh673549\(v=vs.85\).aspx)

------
jorangreef
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...](http://lists.w3.org/Archives/Public/public-
webapps/2012JanMar/0464.html)

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

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

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

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

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

~~~
tomjen3
That would confuse our users when there is no reason to.

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

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

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

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

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

------
macspoofing
This sounds more like a wish-list then anything.

