I still don't understand how HTML5 will become viable within the next three to five years, and so I find it really hard to care about it at the moment.

It is not backward compatible. An agent not understanding HTML5 will find a <section> element and have a fit, for example. Therefore in order to use any of the new HTML5 features we will have to wait until the number of browsers that don't do HTML5 is extremely low. No corporation on earth is going to throw away even a couple of percent of people when those people are potential profit, and it isn't personal blogs that will be the decider on whether HTML5 is successful or not. It's corporate land that decide that.

So we have to wait for IE6, IE7, Safari 3, Firefox 2 &3, all to die off before HTML5 is viable on the corporate web. We're going to have to wait for browsers that aren't even out yet to become statistically irrelevant before we can use HTML5 without either duplicating the site in XHTML or throwing away customers/visitors/revenue.

And that's one reason for my giant 'meh' feeling over the entire topic. Not to mention the more pedantic/picky issues of questionable accessibility regressions, weird choices for 'semantic' tags, and any of the other HTML5 issues that have been argued back and forth on the mailing lists.

It's an interesting thing to see that HTML5 will skip the meta-tag mode. I don't see how that's viable, surely it will end up creating the same position we are in now, all over again?

That is good news... it puts some things into perspective, given thoughts and opinions of the last couple of days. More investigation is now required into HTML 5 on my part.

Thanks Snook

As excited I am about it, Matt has a pretty good point, we'll still be twiddling our thumbs till the browsers catch up.

I'm with the others here. I can't understand how they are supposed to do this, it will take forever for HTML5 to come without it being backwards compatible.

What are we developers supposed to do? Make one site with HTML5 and one site with XHTML?

An important point is being missed by the fellow commenters, here. You don't have to use any new aspect of HTML 5 in order to get the standards-mode benefits of using the HTML5 DOCTYPE. This DOCTYPE is able to push Firefox, Safari, Opera, IE6, IE7, and IE8 into standards mode and allow us to (as best as we can) develop web applications in a standards-based way (CSS, HTML, JavaScript, DOM). You don't have to use a single one of the new features in order to make this happen and can begin doing so today.

@Matt Wilcox -- HTML5 is backward compatible. You don't have to use the new constructs if you don't want to. Most of the existing HTML4 bits and bobs are still there. See http://www.w3.org/TR/html5-diff/

What's more, Ian Hickson has some interesting ideas about creating an HTML5 compatibility layer for IE7 (see the last paragraph).

Hey, http://www.w3.org/TR/2008/WD-html5-20080122/ is the actual Working Draft the W3C published (also has the right date and all). You're pointing to the latest editor's draft. Ian has made some changes since yesterday already which is why the date changed there ;-)

...actually, that sounds like a pretty sensible idea and even sounds a bit forward thinking. It's still backwards using the html5 doctype for page coded in html 4 or xhtml 1 just to get a browser to display a website the way it's supposed to be displayed [and is displayed correctly in all other browsers].

Gecko doesn't break the web, Webkit doesn't, so I'm certain the smart folks at Microsoft could make a browsers that does all the new stuff and doesn't break the web, either. (yep, I'm still on that side)

Not quite. We know that documents with the HTML5 DOCTYPE will render in IE8's least-quirky mode, but what about IE9?

It's entirely possible that an HTML5 DOCTYPE will lock you into IE8 behavior.

John you make a good point, just simply throwing this (!DOCTYPE html) above the html element will be enough regardless if it is coded for html 4. Has anybody heard what versions of browsers plan to support HTML5?

As someone who actively believes HTML5 to be the very best thing since sliced bread, I'm rather delighted at the news. The corrections regarding backwards compatibility are one of the reasons why I love it. In fact, HTML5 is the very antithesis of what Microsoft have created with their meta nonsense; HTML5 reflects the evolving web where the new features will become usable in evolutionary steps, rather than all at once. It is a spec very much in tune with the progressive enhancement techniques we've used since the turn of the millennium, techniques that Microsoft appear to be suggesting we just disregard for their browser.

I see both sides of the IE9 issue. This does solve the problem in the short term whilst pushing the web in the direction of HTML5 which which I'm in favour of. That said, we still need to fight Microsoft on the principal on this. Their implementation is very clearly designed to be used again and again in future versions of IE. As such, sitting back starting a fresh riot in 2010 is perhaps not the wisest idea.

Better to protest Microsoft to see the problems with their suggestion now and resolve it at the source, than have to re-energise everyone on the same issue in two years time. And of course, any site out there now which is progressively enhanced with CSS features that IE7 doesn't support, will still never be rendered properly by IE8. Gotta fight for pages now, not just in the future.

@John: Thanks! That's part of the 'more investigation' I was going to do. I thought HTML5 retained the HTML4 elements and could be used.

HTML5 it is then!

As for the twiddling-our-thumbs part I'm crossing my fingers for browser vendors implementing autoupdate features like Firefox. Opera is planning on having it in upcoming versions (it's on their most wanted lists at least) and MS could force a windows update with IE7 (I never thought I'd be rooting for MS to do this!?).

Of course autoupdating has it's drawbacks:
1. it can be turned off (in most instances)
2. bugs could be pushed (as was the case with the Firefox 2.0.0.10 canvas drawImage bug - and version 2.0.0.11 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.

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.

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

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.

@Snook

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?

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.

http://mattwilcox.net/archive/entry/id/957/

Cheers Jonathan :)

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.

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.

@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 :)

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