This page is an archive of my old blog. Please visit DavidTucker.net for my current blog.
This site is no longer being maintained and commenting is disabled.

An Honest Open Discussion on Web Standards and HTML 5

If you monitor the web, you likely think that the Flash Player and Silverlight are on life support, and that HTML5 is rapidly changing what is possible on the web. In reality, many people who are commenting on HTML5 don’t fully understand the current landscape. Did you know that HTML5 editor Ian Hickson stated that HTML5 won’t fully be implemented in all browsers until 2022? Did you know that iPhone developers can start fully using HTML5 now? Did you know that all features in HTML5 were originally from web plugins? Did you know that Google uses a web plugin for Google Wave?

We need an open honest discussion about HTML5 and what it means for the web. Unfortunately, you aren’t going to get the truth from fanatics on either side, but instead we all need to examine all of the evidence and come to our own conclusions. I have spent a great deal of time analyzing the facts, and in the process I have made several observations.

DISCLAIMER: In full disclosure, I must mention that currently I am Flash Platform developer (primarily Flex/AIR). I also write a regular column for the Adobe NewsFlash newsletter. However, before I became a full-time Flash Platform developer, I was a traditional web developer who spent all day dealing with HTML, CSS, JavaScript, and PHP. I feel that I have an understanding of both sides of the discussion (but obviously am open to any input anyone has on the matter).

The Present

After much effort by many dedicated developers, HTML5 is just about ready for prime time. This process started about a decade ago, and gone through many iterations. Today, HTML5 is available and ready to go on a few platforms/browsers. However, not all browsers implement all of the standards, and some browsers haven’t even announced when they expect to have full HTML5 support6. In reality, version 3 of the iPhone OS is the only solid platform that has full HTML5 support (as well as some other fixed development platforms). What does this mean for developers? It means that HTML5 is still very much in the future (and not the present) for a majority of developers.

I was struck when reading Jeff Croft’s posting, Two Thousand and Twenty-Two, last September. It shed a lot of light on the frustration many developers are having with web standards as a whole. While, I haven’t even talked with Jeff directly, I have always been a fan of his work. After learning of the bleak timeline1 put forth for full HTML 5 browser adoption, Jeff stated: “it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use”.

Developers who have to build solutions for clients don’t care about the theoretical, they care about the reality. On that same vein, a solution is not a solution if it only applies to 10% of the target audience. It isn’t a solution if only applies to 90% (and leaves out 10%). Clients want sites/applications that work well for every member of the target audience – and they want it today. This brings me to my first observation:

Observation 1: Developers won’t be able to use HTML 5 in solutions they build for their clients (unless they are on a fixed-platform as described above) until at least 2014. For full HTML 5 functionality, this will be much later even than this.1

Developers could look at creating solutions that leverage both HTML5 and the current HTML/JS model. However, this would mean that for a single solution a developer would have to create:

  1. Browser detection to determine if the user is HTML5 capable
  2. A full HTML 4.1/XHTML 1 application for current and older browsers:
    1. Multiple CSS files (including hacks) to support IE6, IE7, Firefox 3, Safari 3
    2. JavaScript that is compatible with all browsers listed above
  3. A full HTML5 application (which will have little code overlap from the HTML 4.1 application)

For developers who already have to deal with the CSS and JavaScript craziness, this would just add another layer of complexity. In reality, HTML5 won’t be an option for traditional developers until 90%+ of the web is using an HTML5 capable browser. Keep in mind that most all sites still have to check for IE6 users, even though it was released eight years ago (2001).

The Truth About Plugins

At the heart of this discussion are the web plugings that we use today. Many articles5 have been written lately claiming that HTML5 will kill off traditional web plugins. In reality, this is far from the truth. Before I address that issue directly, we need to take a closer look at what is a web plugin.

When listing the common web plugins, most people realize that this includes the Adobe Flash Player, Microsoft Silverlight, and JavaFX. However, this also includes Google Gears, Google Native Client, the Google Earth plug-in, as well as the Google audio/video chat plug-in. In addition, to the Google plugins, there are countless plugins by other vendors. These plugins have been vilified due to the fact that they are ‘closed source’ projects. The truth is that the plugins have a rapid development cycle that leads to innovation. I am not saying that this can’t happen with an open source project, but I develop cutting-edge solutions for real clients. I can’t look to web standards for real innovation – only more of what has already been implemented:

Observation 2: Web standards will never innovate – they will only implement what plugins have already successfully included. This is due to the fact that the standards process is run by Microsoft, Google, Mozilla, and other companies that aren’t going to invest in implementing a feature unless it already has a proven place in development. The term standardization implies that you are taking something that already exists and creating a uniform process for implementing it.

In addition, many developers fail to acknowledge the role plugins have played in the HTML5 standard. This brings me to an observation:

Observation 3: Every new feature in HTML 5 (except maybe 2) were added because developers wanted functionality already available in a plugin. This includes offline cache (Google Gears), canvas (Flash Player), media playback (Flash Player and others), drag and drop (Flash Player and others), etc…3

At the recent forefront of this debate has been Google Wave, recently announced by Google at the Google IO Conference. This rich Internet application has been hailed as a great example of what web standards can do. However, virtually no one has commented on the fact that it requires a plugin to function. Yes, the example of what HTML5 can do requires Google Gears for some of its functionality. In reality, it is only for a small portion of the functionality (drag and drop), but it brings to light an important observation.

Observation 4: Google had the option to go through the standards process and try to add the drag and drop functionality before releasing Wave, but they decided that the user experience would suffer without the functionality. Instead, they chose to use the plugin to provide the best overall user experience.2

The truth is that plugins can ‘upgrade the web‘ in under a year. In reality, an idea can go through production, QA, released to users, and then pushed to 85%+ of the web within 16 months4. This is not the case with web standards:

Observation 5: Because of the major corporations and entities (as well as egos) that are involved, any major change (that requires browser creators to change functionality in a uniform manner), is guaranteed to take at least a decade from idea inception to actual implementation (across all browsers). The time required to allow for users of older browsers to upgrade, can add another 5+ years to the process.1

If HTML5 were completely implemented by all major browsers today, and if all users had these upgraded browsers – the web plugins would take a serious beating from HTML5 (although even then – it wouldn’t kill them). In reality, HTML5 can’t even compete with the web plugins – because it is currently only viable on fixed-platform solutions (like the iPhone).

Quality vs. Standards

One of my major points of anger on this topic is that many developers are ignoring quality in pursuit of web standards. That is at the center of the video codec debate (and there are many examples of these types of issues around HTML5). Developers are choosing to evaluate solutions based on their relative openness rather than their actual functionality. What have the last five years taught us? We are finally entering an era where we understand that user experience is the key, and now some developers want to sacrifice quality for openness. This beings me to one of my most vehement observations:

Observation 6: Many open-source solutions are at the top of their respective field (Apache, MySQL, Linux, the Flex Framework, etc…). Inferior solutions (like the Ogg codecs) should not be tolerated just because they are ‘open’. If you want all browsers to implement a video codec, make one that is better than h.264. Developers should never sacrifice the user experience for the warm feeling they get when using ‘open’ solutions.

When a potential client looks at my body of work (or my company’s body of work) they will not care about web standards – they will care about the quality and functionality of the work. In addition, when a user uses my application, they won’t care about ‘openness’ but only about the overall functionality and user experience. As a developer and an employee of a company – I cannot recommend an inferior solution. I have to evaluate all solutions based on functionality to stay competitive. This means that in the future, HTML5 will be a solution that I consider if it provides better functionality – but, I will not choose it simply because it is open. It will be on equal footing with the other solutions that are available.

The Future

I hope that these overall observations have shed some light on this issue. The crux of the issue is this: fixed-platform developers can enjoy HTML5 now – and they should embrace it and start learning / working with it now. Traditional developers will have to wait around 5 years before it is a real option for them. In that time, we will probably have Flash Player 13, Silverlight 5, and JavaFX 3. Who knows what these versions will include – but, we can assume that the functionality they will include will probably be included in a future version of HTML.


1 HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more
2 Google Wave (video described Wave’s use of plugins)
3 HTML5 Versus Flash Versions
4 Adobe Flash Player Version Penetration
5 HTML 5: Could it kill Flash and Silverlight?, HTML 5: Could it kill Flash and Silverlight?
6 Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies, Implementations in Web Browsers




23 Responses to “An Honest Open Discussion on Web Standards and HTML 5”

  1. Thud says:

    Excellent points. I look forward to the time when we won’t need Flash as a plug-in to do what Flash does, but that time is still a good long way off.

    And even if it does “die”, it will do so because the features that used to be Flash-specific are done as well as or better by the Browser. And without the probably two-decade contributions of the Flash plugin, that might never have happened. The features of Flash will survive, even if the plugin doesn’t.

  2. David Tucker says:

    @Thud – great points – and well stated. We might disagree on what would be best in the future – I totally agree with the concept that the ‘features of flash’ will survive into the future, and that the best solution (both in functionality and usability) should win irrespective of who developed it.

    Thanks for the comment!

  3. [...] Update: David Tucker has done a much better job of conveying most of what I was trying to say here. [...]

  4. John Ryan says:

    So, wouldn’t the ideal solution be HTML rendering engine as plugin?

    I get that there’s already a bit of this going on with Gecko and WebKit, but why not just tear the rendering engine out of the core of the browser so that it can be upgraded without a recompile?

    Then throw an extra layer on top for browsers to hook into and create unique features with.

  5. David Tucker says:

    @John Ryan – I agree that this is an ideal solution – however, you still cannot force users to update – and we also cannot choose to ignore a segment that is just using an older browser. I generally see this in corporations where the user can’t update it themselves – and the IT department has no interest in updating a browser.

    It also seems the browser makers have been unwilling to consider this idea – although I am not entirely clear what their reasoning is on this.

    Thanks for the comment!

  6. Excellent article!

    With so many “HTML5 is going to kill Flash” articles popping up lately, I think you address some very key points. It’s obvious we’re still very far from support, yet alone standardization of HTML5. Even now it’s extremely difficult to provide a consistent user experience across all the different browsers, yet plugins like Flash and Silverlight offer that now. Plus open source libraries like swfobject and swfaddress have given Flash features it has long been knocked for lacking (forward/backward navigation support, SEO, bookmarking, etc.).

    With a huge community of developers behind, it’s becoming easier to create an accessible and consistent user experience using Flash and a few open source libraries/techniques than using HTML/CSS (HTML5/CSS3 in the future).

    Nice job. I will be frequenting your site from now on.

  7. Justin James says:

    As others have said, excellent post.

    What’s really interesting, from the viewpoint of someone who’s been reading the HTML 5 Working Group list for well over a year now, is just how much of a premium is put on existing implementations. In fact, it is a de facto requirement for something to appear in the HTML 5 spec at all. So really, it is essentially stated on the mailing list (you can dig it up in the archives, if you really care to) by Ian Hickson, is that everything you say here isn’t conjecture, it’s fact.

    The flip side to this is, is that HTML 5 stands a good chance of merely rubber stamping proprietary extensions to HTML. For better or for worse, many companies are choosing to do this the plugin route and not bother trying to go to the HTML 5 spec with it (Flash, Silverlight), and other companies are using the HTML 5 effort to formally ratify what they’ve already done (Google in particular).

    Also, big kudos for correctly understanding the 2022 number, which Jeff Croft failed to comprehend in his banal rant. The whole spewing of his was so rediculous, because if he had read two more sentences past where he claims he stopped reading, there would have been no need for his post. 2022 is indeed not when the HTML 5 spec will be “done”, but when it is expected to be fully implemented by at least 2 browsers. Plain and simple. HTML 5 is well on its way to “Last Call” already.

    J.Ja

  8. Tomas says:

    So its you who we should blame for c*r*a*p*y A*d*o*b*e F*l*a*s*h Plugin that crashes everything on its way! I will hunt you down MTFK!!!

  9. John Dowdell says:

    “Tomas”, if you’re crashing, then you should be able to regain normal performance.

    I don’t know what browser or operating system you’re on, much less your full configuration, but just on a hunch, try doing a reinstall… that corrects any damage to the Player. More with search term “site:adobe.com player troubleshooting”.

    But back on-topic, thanks for the article, David.

    jd/adobe

  10. John "Z-Bo" Zabroski says:

    Excellent article… every developer at our company was linked to it.

    I think you miss out on explaining one thing, though.

    HTML is monolithic, whereas Silverlight, Curl, JavaFX (aka HotJava 2.0) and AIR are all VMs with rich extensibility points. If you look at how Javascript frameworks are using HTML, they are only using very rudimentary HTML capabilities + CSS and the DOM. In this sense, HTML5 is somewhat backwards, I think. I could be wrong on some details, but I am pretty sure I understand the “big picture”.

    Here’s why.

    It’s been said in the past, and every developer has probably heard it before, but all you really need is a canvas element. With canvas, you can get rid of a lot of unnecessary stuff. Then toolkits like GWT would draw on canvases instead of manipulate block and inline elements. I could see Gears having GWT-detection abilities that could parallelize some canvas drawing stuff, too.

    So HTML5 is in many ways a step in the wrong direction. It should be broken up into pieces, rather than one spec. That’s the way CSS sort of works now – broken into pieces with compatibility levels. This would allow vendors to support HTML5 incrementally and iteratively. Even then, it will still be monolithic and not extensible.

  11. Jens Wegar says:

    Great article, well laid out, referenced and thought through. The best I’ve read on the HTML5 vs. plugins debate. Thanks!

  12. [...] DavidTucker.net » Blog Archive » An Honest Open Discussion on Web Standards and HTML 5 [...]

  13. Hi David,
    when choosing a technology for a project, first comes user experience, then comes developer experience, then at a distant third come open standards. HTML sucks for the first 2 points, so I’m sticking with plugins, be it HTML 4 or HTML 5. I actually find writing something using HTML + CSS + javascript for the client side so painful that unless I’m desperate I’ll pass on it.
    Ariel

  14. Ian Hickson says:

    “Did you know that HTML5 editor Ian Hickson stated that HTML5 won’t fully be implemented in all browsers until 2022?”

    I did not know that! :-) I thought that what I said was that 2022 was when I estimated that we’d have two complete and bug-free implementations. This is in fact just a guess. It’s worth noting that we’ve never had two complete and bug free implementations of any prior version of HTML, so this would be quite ground-breaking if we managed it.

    “Did you know that iPhone developers can start fully using HTML5 now?”

    They can’t; the iPhone supports some HTML5 features, but not all of them.

    “Did you know that all features in HTML5 were originally from web plugins?”

    This is flat out wrong. Some features were, others were not. Most were not, I would estimate.

    “Did you know that Google uses a web plugin for Google Wave?”

    Google Wave can use Google Gears for drag-and-drop support, but it is not required to use Wave.

    “This process started about a decade ago”

    Work on HTML5 started in late 2003.

    “Web standards will never innovate – they will only implement what plugins have already successfully included.”

    Web standards should not innovate, though it does happen. However, plugins aren’t the only place where innovation happens. Most innovation in fact happens straight in the browser. For example, drag-and-drop in IE, XBL in Mozilla, canvas in Safari, etc.

    (There are a number of other things I could correct in this post, but I’ll leave that up to others.)

  15. [...] Web Design – An Honest Open Discussion on Web Standards and HTML 5 – David Tucker (Suggested by Umut Muhaddisoglu) [...]

  16. Truffle Apps says:

    Nice read

    Thanks

  17. Amer Dababneh says:

    The issue of browser compatibility still is an issue. but if they follow a common standard for compiling the HTML5 i think it will have a huge success.

  18. Excellent post. As you say, people seem to get very fanatical about plugins, Flash vs Ajax, HTML5, open/closed-source etc. Most of the arguments are academic, because as you say the rest of us just get on with building apps with whatever works best in the real world. Those who want a neat, standardized and elegant ecosystem on the web are doomed to be forever disappointed. The web is somewhat messy and it will stay that way as it matures, HTML5 or not. Can;’t we all just get along?

  19. [...] Here’s a good article from an RIA developer who argues that predictions in this area, especially those slanted towards the death of plug-ins like Flash, are probably premature. You can also read it on read it on the original author’s blog. [...]

  20. Hi, I came across this blog article while looking for help with Microsoft Silverlight. I have recently changed internet browser from Google Chrome to Firefox 3.2. After the change I seem to have a issue with loading websites that have Microsoft Silverlight. Everytime I go on a page that needs Microsoft Silverlight, my computer does not load and I get a “npctrl.dll” error. I can’t seem to find out how to fix the problem. Any aid getting Microsoft Silverlight to work is very appreciated! Thanks

  21. [...] as we intended « Home DDM Blogroll A great commentary on the whole HTML5 v Flash debate! here Here is a cool comparason of flash banners with HTML5 and CSS3 Banners. Some of the posted comments [...]

  22. Amer says:

    Awesome article….