By Craig Buckler

The W3C and the “HTML5 Isn’t Ready” Backlash

By Craig Buckler

The following InfoWorld article spread like wildfire throughout the web yesterday — W3C: Hold off on deploying HTML5 in websites. The story was prompted by comments from W3C official Philippe Le Hégaret. The community has been in uproar although I suspect many of Le Hégaret’s quotes were used selectively or taken out of context. Even so, let’s go through each statement made in the article…

The problem we’re facing right now is there is already a lot of excitement for HTML5.

Agreed. There’s also much hype and confusion. To most people, HTML5 means “the future of the web”. You can take a 5 year-old quote about “Web2.0” or “Ajax” and interchange it with “HTML5” today. The mainstream media neither knows or cares about the technical realities and there’s little point trying to explain that CSS3 != HTML5.

It’s a little too early to deploy it because we’re running into interoperability issues, including differences between video on devices.

I don’t think it’s ready for production yet, especially since W3C still will make some changes on APIs. The real problem is can we make [HTML5] work across browsers and at the moment, that is not the case.

Le Hégaret is quoted as saying one browser is not the same as another. Is that news? We’ve struggled with differences since the dawn of the web.

There are 4 major rendering engines: Trident, Gecko, Webkit and Presto. The chances of each matching the other feature-for-feature are nil. Browser changes are a fact of life on the web — it’s not a problem with HTML5.

HTML5 is viewed as a game changer. Companies now can deploy HTML5 in their applications or in intranets where a rendering engine can be controlled, but it is a different story on the open web where interoperability is an issue.

Interoperability always has and always will be an issue. It’s easy to support one browser but the best developers can make a site work on any device, whether it’s Firefox 4.0, a screen reader, mobile device, Lynx or IE1.0. It’s not always worth that effort but HTML5 does not change the process. Many sites use XHTML1.0 or 1.1, yet neither is supported by IE8 and below.

Of course, developers should use common sense. If you’re developing a system where 90% of your audience are IE6 users, don’t expect the HTML5 video tag to work. You’ll have fewer issues with other elements, such as header.

The HTML5 specification itself features support for video and Canvas 2D. But other technologies such as CSS and MathML are considered part of the “open Web platform” along with HTML5, even if they are not covered by the actual specification. SVG is referenced by the HTML5 specification.

This quote is most telling. It’s a long meaningless statement in the middle of the article, but what point is it making? Is Le Hégaret saying CSS and MathML can or cannot be used because they’re separate from HTML5? Or has the reporter simply plucked a random statement from the interview?

We’re not going to retire Flash anytime soon. It will take years before all Web clients support HTML5. IE6 is still being used on the Web today and it is 10 years old.

Over time, however, HTML5 will become the standard for websites and you will see less and less websites using Flash.

Ahh, the good old “HTML5 is a Flash replacement” statement. Was this started by Apple? If not, their marketing department must love it!

I’m not sure why the article needed to mention Flash, but HTML5 is not a Flash replacement! The video tag and newer CSS3 features may reduce reliance on Flash, but that doesn’t mean Flash can’t or shouldn’t be used. Flash will offer the most reliable cross-browser video medium and gaming platform for many years to come.

Digital rights management also is not supported in HTML5. This means some video producers will not deploy their videos in HTML5 without this type of protection.

If we are going to develop a solution for DRM which is open, it would be broken by a hacker within two days. There is a possibility for DRM in HTML5 at some point, however, but it is not in the plan at the moment.

Is this for real? An open standard is, by definition, open. DRM has never been a feature of HTML. If you want to control media distribution, use an alternative such as Flash or Silverlight — like you’re doing now.

HTML5 also lacks authoring tools at the moment.

What about Notepad? It’s true that few WYSIWYG editors produce HTML5 but few produce decent HTML4. The best developers use a text editor or IDE. There may be a few color-coding quirks and validation difficulties, but there’s little to stop you writing HTML5 code today.

Where are we going?

Whereas Web2.0 and Ajax were vague terms, HTML5 refers to a real set of technologies with specifications and version numbers. The InfoWorld article succumbs to the belief that, at some point, HTML5 will be “complete” and ready for production. This is not the case.

Browsers continually evolve and new features are ultimately copied, tweaked or rejected by others. If at least two vendors agree, a single feature may become part of a W3C specification — whether it’s HTML5, CSS3, SVG, MathML or whatever. However, a W3C Recommendation does not automatically mean the facility will appear in other browsers. Fortunately, there are always workarounds, fall-backs, or shims when we need them.

HTML5 is not a destination — it’s the journey. We’re not sure where we’re going, but at least all the browser vendors are on the same bus.

  • jeffedsell

    For me the backlash changes little. I’ll continue to use HTML5 for my freelance clients (taking advantage of the wonderful HTML5 Boilerplate), but at my day job, where I’ve been dragging us kicking and screaming towards current standards, I’ll hold off.

    I just recently managed to convince them to drop active IE6 support, and to use CSS3. HTML5’s advantages are hard to explain to the layperson, and all I need is for someone to read a “W3C says HTML isn’t ready for Prime Time” headline — then I’ve got a fight on my hands.

  • Dave

    For God sake…. I am getting tired of reading sh**ty articles and declartions about HTML5. It’s even more true how I feel when I read about “Don’t use it now because browsers lack of support”.

    Ladies and gentlemen, HTML5 was born from browsers and web apps makers. Sooner or later – most probably sooner than later – all web browsers will support those features.

    Also people should know about the difference between technology and development.

    If you hire a good development service/professional, your product probably will be made using “progressive enhancement” or “graceful degradation”, “javascript/dom featuring testing”, and with lots of fallbacks.

    The problem isn’t using HTML5, CSS3, new javascript APIs and so on. The problem is bad development. A bad developer can make a XHTML / CSS 2 website that sucks.

    • Jenn

      Thank you for stating this. Agree 110%!

  • Jeffrie

    Never fails to amaze me how media can make an ice cube seem like the tip of an iceberg. Regardless, I completely agree that HTMLx is always a journey of growth and maturity. As developer’s, we do what we always do: Develop solutions regardless of the challenge or tools presented. Not surprised that some of us forget that it is always the results, not the tools, that we are graded by.

  • >HTML5 also lacks authoring tools at the moment.

    But what kind of website, other then those small ones put together by amateurs, use HTML authoring tools? I mean any well done site will use a template engine.

    But most the quotes are just stating the bleeding obvious, risks that are always there whether HTML5 is used or not. We are used to dealing with them by now.

  • Muhammad

    Big problem for update the Web technology is Microsoft Internet Explorer. If Microsoft drop IE project we will see a big mutation. Just boycott the Microsoft Internet Explorer, all versions!!!

  • My ‘problems’ with HTML 5 runs deeper than the simple reasons presented so far, though yes the largest of them remains that it’s in DRAFT, and that means “not ready for real world deployment”! It’s like the people who install beta versions of software JUST because it’s the newest version and then bitch when it chews up their data. COMPLETELY MISSING WHAT THE WORDS BETA AND DRAFT MEAN!!!

    But from there I have a lot more issues with it. 90% of the new tags are nonsensical/unneccessary garbage many of which just seem to exist to cater to the people who can’t write HTML4 properly in the first place… especially those who love throwing extra wrapping elements around existing tags for no good reason.

    As it sits it often seems the majority of developers are blissfully unaware of tags like th, caption, tbody, thead — you repeatedly see people building new websites abusing tables or defintion lists because they don’t know about label, legend, fieldset… Much less the plethora of other tags that go unused or worse, abused in the wrong circumstances like DL, CODE, DFN — hell most people can’t even seem to figure out how to put heading tags in the correct order!

    So adding more tags is going to make this BETTER?

    Worse, literally it’s throwing a lot of the progress made with HTML strict right out the window… One of the entire points of STRICT was to simplify by reducing the number of tags needed. Applet, Embed, (and eventually even IMG) were supposed to be supplanted by Object — so here we are ten to twelve years later wasting our time adding AUDIO and VIDEO, tags that should be redundant to OBJECT?

    Tags like ‘nav’ which exist solely to placate the people who slap div’s around their UL for no good reason (If you were going to do that to target it, make it a REL value!)… Vague elements like ‘details’ that tell you nothing that paragraphs after a heading tag wouldn’t tell you (of course, if people would stop slapping paragraphs around non-paragraph elements willy-nilly).. crap like keygen that’s ultimately useless since that’s entirely client side and as such you’d still have to run a separate check server side (defeating the point), tags like ‘summary’ that by all rights are redundant to HEADING tags…

    Hell, it’s even taking the deprecated EMBED and bringing it back! WHISKEY TANGO FOXTROT!!!

    Much less the sloppy half-assed removal of ‘formedness’ rules which is why the validator lets goofy mixes of HTML 3.2, 4 and XHTML 1 right past as if nothing is wrong. The entire reason I use XHTML 1.0 Strict and why I’m staying with XHTML 1.0 Strict is that the rules of the language and stuff the validator catches prevents you from making stupid mistakes in the first place. It’s one of the things that always bothered me about HTML prior to XHTML was the structural rules so loose you can’t help but screw up… All the crap tranny lets you get away with — and now for all intents and purposes you have HTML 5 which appears to be nothing more than a bunch of goof-assed extra tags slopped atop HTML 4 tranny.

    Net result can be seen on the handful of sites that have already been put up with HTML 5, most of which are such sloppy train wrecks anyone with half a brain would go screaming back to using HTML 3.2

    Nope, can’t say I like it. Can’t say I like it one bit.

    Of course, the worst part is it’s chock full of “gee ain’t it neat” trash that has all the developers working on it so they can say “look at how flashy this is” when not one of the browser makers even has HTML 4 and CSS 2 working properly yet! Here’s a tip, before you have people wasting time working on flashy bullshit that won’t be real world deployable for another decade, just MAYBE you should finish off the decade old specifications FIRST!?! (yes 915, I’m looking at you!)

    • Agreed…
      I’m not quite as passionately opposed to HTML5 as you but I am concerned about industry pushing their own agendas through support of a DRAFT that has no timetable (I’m still looking at you Apple).

      I’m also with you regarding well formed documents and tag soup… There is still a decade of garbage left over from the millions of bloated sites that came before standards based development practices took hold. Now we’re encouraging well meaning cutting edge developers to dive into an un-hardened spec. It kind of reminds me of IE5.5 ten years ago and all the crap we had to fix as a result.

      Regarding HTML5 as a standard, I’m sure at some point it will become a standard but at the moment it’s still in DRAFT which is why when you go to and select the ‘HTML & CSS’ menu, it talks about XHTML which is a standard that can be relied upon for decent cross-browser support. Yes a bunch of the draft spec is supported but what about all of the browsers that aren’t? My clients don’t care about HTML5, XHTML, CSS2/3, etc… They care that what they see on browser X looks the same as it does on browser Y. Period. They want videos embedded that work in all browsers and some still want IE6 support for the 5% of their visitors. I wish I could snap my fingers and everyone’s browser would be using webkit but that just isn’t the case.

      If a client wants a site built in HTML5, of course I’ll do it. If they want to use something that isn’t widely supported, I’ll explain the downside and if they still want it, then I’ll deliver it however the majority of my clients will get websites marked up in a spec that has become a standard. Period.

    • mhitza

      So true, so true indeed.

    • Paul McKeown

      Quote: “Tags like ‘nav’ which exist solely to placate the people who slap div’s around their UL for no good reason (If you were going to do that to target it, make it a REL value!)”

      Not so fast, there, buddy…

      This almost certainly depends on css with attribute selectors. That would be fine, but:
      a) IE 6 doesn’t support attribute selectors at all
      b) IE 7 aborts dramatically on encountering spaces, nulls and various other values in attribute selectors
      c) attribute selectors are less specific than classes or ids in the cascade, which means that they can easily be overridden unless their use is not carefully thought through
      d) more functional uses depend on CSS3 (e.g. the “$=” “ends with” attribute selector, which makes it easy to do stuff specific to a MIME type as a download ends with .pdf or .doc or .wmf or whatever)
      e) your suggestion of using, for instance, rel=”navigation” (or whatever) on an unordered list used for navigation, rather than wrapping the ul in a div doesn’t actually save on markup – and ultimately, in the real world, requires workarounds to be provided for the other problems listed above.

      So, ultimately, in the long term, I will be using the html “nav” tag. You can do whatever you want.

      A better signal to noise ratio would be quite welcome…

  • I forgot to subscribe to the thread in my previous comment so… This is the easiest way to do so.

    Also here is the current status of HTML5 according to W3C:

    Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

    The entire document can be found here:

    • You should note that it’s the specification document which is unstable — not necessarily browser implementations.

      For example, H1 is a valid HTML5 element but you won’t have any problems with it. HTML5 is backward compatible so it’s unlikely to be removed from the spec. Even if it were, vendors have little reason to remove it from browser rendering engines.

      Are you avoiding CSS3 properties because it’s a draft specification? Or have you used the odd rounded corner or box shadow? Why is that different?

      • Well I suppose all that is preventing me from using HTML5 in production is being responsible for my client’s websites.

        The currently W3 recommended standard of HTML does everything I need, loads fast and renders with accuracy regardless of browser and OS. HTML5 adds some wiz-bang features and a few bytes less markup but at the moment there is no compelling reason to switch particularly in light of the spec being in draft… Their words not mine: “Implementors should be aware that this specification is not stable.” Yes that has more to do with producing browser engines based on the spec but all the same, there is a trickle down effect and I’d rather be safe than sorry when it comes to my clients web presence.

        Would you install a beta of Windows 8 and IE 10 (beta) on a client’s corporate workstation and say “Ok sport, knock yourself out.”? My guess is you wouldn’t.

        The other reason I’m not particularly keen on using HTML5 in production is because the really neat CSS3/HTML5 features don’t work particularly well in the majority of browsers. For instance that really cool Arcade Fire HTML5 demo… Super cool in Chrome, Safari 5, Opera, FF3+. Not so cool in older browsers, doesn’t work in IE7/8 either and as we’ve seen with IE6, there are lots of older browsers in the wild. What was the latest on IE use on the web? just under 50%? I’ve seen that IE6 is down below 5% but what about IE7/IE8 and what about FF2, older Safari, Opera, etc… Yes HTML5 can fool the browser into thinking it’s HTML4 but the fun and compelling features will not be present.

        Of course I’ll keep it (HTML5) in my peripheral vision so I can implement when it becomes a recommended standard but for production, unless a client specifically requests it or it is a make or break feature, I’ll stick with hardened standards.

      • As you say, there’s little wrong with HTML4 — although you can write HTML5 using HTML4 syntax and benefit from a shorter doctype and script tags.

        In most of the swanky demos I’ve seen, it’s primarily CSS which is used for the effects — and causes the most cross-browser problems. Yet, some parts of CSS3 are very stable and useful, e.g. rounded corners.

        HTML5 is no different. Video tags may cause a few headaches in IE6, but many of the elements are there for semantic richness and you won’t encounter problems. I’m not saying that’s a reason to adopt HTML5, but there are few reasons to ignore it entirely.

  • phrenetical

    In response to tag complexity, it really is a rock and a hard place. On one hand you have search engine developers and other industries screaming for relevancy in web mark-up. So the OBJECT tag, is completely useless as it describes nothing, it is semantically obfuscating the ??? the what???

    Video and Audio tags allow some extra semantic control, that is the point of the extra tags. You won’t find many new tags in HTML5 that are not directly important for better semantically correct HTML. Header, Nav, Section, Article, I use them in all projects now, I love the way the mark-up looks and behaves without semantically useless DIV tags wrapping what is essentially a NAV element that is now easily discernible by indexing algorithms.

    That said, yes it will be a headache should they change the names of those tags, yes it adds some complexity back into writing web-pages, but I’m prepared to risk it for the extra SEO benefit that my sites see by using HTML5.

  • simonbanyard

    Wow, some very ill-informed ranty comment! Plus ca change…

    What Remy says;

    • Umm… I read Remy’s post. It’s not bad but it’s just an opinion (perhaps as ill/well informed as the opinions here) and perhaps more ranty or so it seems as it is punctuated with words that start with “F”.

      That said, it doesn’t change the fact that HTML5 is a Draft, subject to change before it becomes a recommended standard. So yes by all means learn it, use it for experiments or even for your personal/business website… However, give it careful consideration before producing a client’s production website with it to ensure that it works well in their audiences browsers.

      That’s all.

  • Stomme poes

    If you’re going to use it, use it right: learn how to make it accessible (cause right now, it ain’t): helps show where pitfalls are

    Eric Eggert has made a JS library to help:

    Mostly, test test and test. I’m sure Bruce Lawson cares enough to test his sites, but what about most of these early adopters?

  • aking10

    @deathshadow60: Hey, you said it yourself: “not one of the browser makers even has HTML 4 and CSS2 working properly yet!” So, to use the logic on display in the Infoworld article and Monsieur Hégaret’s mind, CSS2 and HTML 4 are not ready for implementation and developers should hold off on deploying to these specifications. Is that right? Should we all go back to trying to code in HTML 1.0, use the “table” element for layout, the tag for styling our typography? Would that satisfy people like you and Philippe Le Hégaret (who probably doesn’t go to watch movies in 3D or HD television at home, because not everyone has these technologies yet)?

    • The disconnect in your logic is simple.

      HTML4 and CSS2 are standards; they are stable and won’t change. HTML5 is a draft that will undergo change before it becomes a standard.

      Read the 4th paragraph under Status of This document: Link

  • aking10

    Include in the above, second last sentence: “the ‘basefont’ tag”

Get the latest in Front-end, once a week, for free.