1. it can be turned off (in most instances)
2. bugs could be pushed (as was the case with the Firefox canvas drawImage bug - and version has massive memory leaks in drawImage).
3. browser platforms become moving targets.

Big corporate environments that rely on poorly coded applications that only run in a specific browser version of yesteryear may of course pass on the updates. That's a big problem.

But these things considered I still think autoupdates will benefit the spreading of HTML5 (and what other standards may come) greatly.

Matt Wilcox said on January 24, 2008

I'm sorry, but 'backwards compatible' while technically true, is also utter rubbish in terms of practicality.

If you use HTML5 in a manner that a HTML4 parser won't stumble over, then you can't use any of the features that differentiate HTML5 from HTML4. So, why would you do that? What's the benefit?

What I say still holds true - while you can use HTML5 in name now, there are absolutely no benefits to doing to, and nor will there be for many years to come. Because in fact you are merely using a sub-set of HTML5 - HTML4 itself. And what's the point of shoving a different DOCTYPE on the top of what is otherwise an HTML4 document?

Please, if I am missing something that's advantagous about that idea someone let me know - I'd love to get excited about it. But from my understanding, HTML5 for the next 4-5 years is nothing more than HTML4 with a new doctype.

Jonathan Snook said on January 24, 2008

@Matt, like every new spec, it will take time for browsers to jump on board but we're already seeing parts of the spec appear in browsers such as CANVAS and VIDEO support. Likewise, there's plenty of CSS3 stuff that we have to wait on. You can't wait until the entire spec gets implemented before you decide to use it or you'll be waiting forever.

HTML5 is designed for progressive enhancement just like CSS is. The idea being that new features will slowly get added over time without having to sacrifice what's already there.

incontridamore said on January 24, 2008

Nice article, im now going to search info for html 5 coding :)

Alistair said on January 24, 2008

One of the advantages to coding in some standards-based way is that your code doesn't have to be updated as often. By removing the presentation from the content, you can live on existing code for a lot longer, as design changes can be done through CSS.

Investing in HTML5 today goes against this principle and forces you to do your work twice. Once for the features that are available today, and again when a sufficient percentage of browsers support this new spec, allowing you to utilize the new elements. That might be fine for those of us that have a few blog templates to tweak or a small site with 10 or so pages in it, but for those developers that support hundreds or thousands of pages, this could be a costly and time-consuming change. "Progressive enhancement" also means "continuous upgrades" which generally equates to "major hassle" for any site with more than a few pages in it.

For this reason, I am likely to wait until there is greater support for HTML5 before embarking on a site-wide change to the code - something I would rather do as little as possible given the number of pages that need to be updated.

Also, saying that HTML5 is 'backwards-compatible' because you don't have to use the new HTML5 elements is a ridiculous statement. That's like saying that my new iMac is backwards compatible because I don't have to run the software that was designed for my Mac Plus in 1987.

Matt Wilcox said on January 24, 2008


I understand the concept, but the trouble is that HTML is not like CSS. I am struggling to see how HTML5 can be used in a Progressive Enhancement way.

When the user agent doesn't understand CSS3 you are sacrificing a little visual flair, and nothing more. Instead of seeing rounded corners you get straight ones, for example. We use CSS3 elements in a way that is not detrimental to users with an agent that can't render CSS3 elements. But how is that possible with HTML? HTML is semantics, and if the user agent doesn't understand the semantics of new elements then meaning is lost. It's just not the same as losing a presentational effect. The user experience is harmed. The HTML4 agent can't recover or fall-back from meeting a <section> - so what does it do? Throw out the content, not rendering it? Render it as a block element? Render it in-line? What do screen readers do with that? Can a user agent that doesn't support a HTML5 element apply styling or behaviour to it? HTML5 elements in a HTML4 parser = fail.

I have been trying to figure out in what ways you could practically use HTML5 today, and I can't think of any. Unless you can afford to throw away the content of whatever unsupported element you're trying to use, HTML5 isn't viable because that new element is encapsulating semantic data, and we have no idea what will happen to that data in a user agent that doesn't support that particular HTML5 element.

I stand by my opinion that despite the claim of the people involved, HTML5 is not backward compatible in any useful way. Yes, you can use it now but only at the expense of using any of the new HTML5 elements. That being the case, what's the point of using a HTML5 DOCTYPE in an otherwise HTML4 page?

Matt Wilcox said on January 24, 2008

Sorry, I don't want to get too far off topic so I've posted the above comment on my blog as I think the conversation has drifted a bit. If anyone would like to tell me their thoughts on the issue of HTML5 backward compatibility it may be better doing so on my blog rather than hijacking this post any further.


Cheers Jonathan :)

Damjan Mozeti?? said on January 24, 2008

I am always excited when I hear of new standards on the horizon. Now all we have to do, is wait for the "old" browsers to die off, and get to enjoy the greater flexibility the new wave of browsers bring.

I don't really care about backwards compatibility, because this is the way new features were always implemented - you just have to wait for them to be widely accessible and then go for it.

mattur said on January 25, 2008

When the user agent doesn't understand CSS3 you are sacrificing a little visual flair..

You're potentially sacrificing the entire layout if you're using the Advanced Layout module. Adding new features means older browsers won't understand them (otherwise they wouldn't be new, would they?). Does this mean we should never add new features ever? 11 years waiting for new HTML functionality is more than long enough. If you're frustrated with the long wait blame the W3C.

As Olly points out, the idea is to use javascript/CSS shims for backwards compatibility for some if not all HTML5 features so potentially we'll be able to use these features without having to wait for old IE's to completely die out. See AVK's post. Compare and contrast with the XHTML2 path.

I have been trying to figure out in what ways you could practically use HTML5 today

There isn't any support in IE or Firefox at the moment, so it's like trying to deploy any other future feature that isn't supported: mostly pointless. The spec has only just reached first published working draft status. Things may change. Wait for browser support.

Matt Wilcox said on January 27, 2008

@mattur - I took it as read that the advanced CSS was being applied in a progressive enhancement way. So that means not relying on it for layout, because we expect it to not work. And that is the crux of my argument - that parts of CSS can be used in a progressively enhanced way, but no new HTML5 element can be used in that way. (I do not consider using JS as a fix for hooking in backward compatibility with new features, as with any page I design - it has to work on all benchmark browsers with JS and CSS off)

Thanks for the link :)

Thomas said on January 30, 2008

More and more Standards. Why must it be so? Now I?′ve learning html 5 :-(
Thanks for your information.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.