the html5 switch...Interesting!

Depending on who you talk to, you should have been using HTML5 months, nay yearsago; or it's something you might be using in 2022. As usual the truth is somewhere between the glib extremes.

There's no one-size-fits-all answer to questions of platform choice: you have to consider the benefits for your own scenario. But with HTML5 I'd say if you haven't switched yet,for most people it's probably time - there's a form of "switching" that will work for you.

Some people seem caught up on the problem that many features have very poor support across browsers; or are simply put off by the thought of redoing their entire code base.

Really though, you don't have to rebuild everything, not use everything in HTML5 for it to be worthwhile switching your doctype now.

Over the past few months I've switched a large application and a few small sites to run the HTML5 doctype. Most have been seamless, with just one website exploding on contact with HTML5 - it will remain XHTML until it can be overhauled.

So what have I learned doing this? Basically, the decision to switch comes down to:

• What do you mean by "use HTML5"?
• Which doctype are you running now?
• Is there any value to switching?

Seriously, that's it.

defining "using html5"

I'd suggest considering three basic options for "using HTML5":

1. Switch the doctype, but change basically nothing else.
• This is a "readyness" move - you're not changing anything now, you're just paving the way. This option is mostly useful for organisations where technical changes are slow and/or political.
• Generally it should morph into Option 2 reasonably quickly but might be a required stop-off point.
2. Switch the doctype, then use a subset of the new features.
   • This is what most people are doing right now - cherry picking those things which give you immediate value without too much overhead. Usually this translates tousing features with usable levels of support or where it's easy to provide fallback options.
   • This option is good for iterative change, particularly where you can't easily or quickly replace your entire UI code base.
   • For the average dev shop it's probably the best balance of "new and shiny" and "works within budget".
3. Full switch: replace your UI entirely with HTML5, using all the features (including new elements).
   • So far this option is most popular with blogs and new or small apps.
   • For many projects it's just not viable - it doesn't matter what flavour of markup is in use, they're not getting redeveloped right now.
   • This option will require bridge solutions like HTML5 shiv - that is, you'll be relying on Javascript for rendering.

Option 3 negates the need to ask the next question, but Options 1 and 2 really need to ask...

which doctype are you running now?

If you're switching doctypes on an existing code base, you need to consider what that is actually going to do. The most relevant differences are:

1. The rendering mode it sets
2. The rules the W3C validator will apply

Doctypes also tell humans what kind of code should go in the document, but since it doesn't enforce your actual house style it's a relatively intangible benefit.

rendering mode

HTML5 will set strict rendering mode. If your site or app is currently being rendered in strict mode, happy days. However if it's in quirks mode it's going to hurt; and if it's in almost-standards mode, it's a roll of the dice.

Going from almost-standards to standards mode might be a painless change. Most of my sites were painless; another broke quite badly - particularly because strict rendering made the Cufon headings blow up (beware of the shrink wrap).

I will stress that if you are running in almost-standards mode, you should still try the switch. Do not be put off HTML5, just go ahead with your eyes open.

For more information see:

• 24 ways: Transitional vs. Strict Markup
• strict vs. transitional doctype and rendering differences
• For the tale of how almost-standards mode came to be, check out Eric's Archived Thoughts: Almost Target and the linked Images, Tables, and Mysterious Gaps - MDC Doc Center.

validation

Curiously, if you have a lot of validation errors already you might find HTML5 actually lowers the number of errors - it's extremely forgiving. Personally I think it's far too forgiving; and it repositions the validator as a tool only for finding gross errors like unclosed divs. For actual code quality you'll need to move away from straight validation and try a tool like HTML Lint.

Also be aware that currently if you use the x-ua-compatible meta tag, the validator considers it to be an error (aside: I've raised this as a bug with the validator team). This means if you support IE with the meta tag, you will never get a green test result. If you are reliant on automated testing this could be an issue.

the value of switching

It's a basic question, but you should ask "will (insert shiny new technology here) actually help me build stuff"? Even if you are convinced already, your boss or clients probably aren't; so you need be able to answer the question.

Personally I think it's unlikely that any web-based project would get zero value from migrating to HTML5, although some might not get as much as they'd imagined.

Web applications get the greatest benefits as HTML5 is extremely app-focused. Also many apps already rely on Javascript, so the JS-based solutions for enabling new features and fallbacks don't change their support profile.

Websites with lots of content will probably get more benefit long term, as support improves for the content-focused stuff like new semantic elements (and associated document outline system). Short term, there are some questions about best-practice usage and how search engines will cope with the new document outline. Also you might not be willing to rely on Javascript just to get your content to render.

A few other points to consider...

• It's a great base for progressive enhancement and can reduce your maintenance load.
  • eg. common form validation can be handled by HTML5 elements, so you only have to maintain a JS-based fallback for IE... and you can use conditional comments so you only serve it to IE too.
  • Multiply this out and you can make your apps faster and lighter for an increasing proportion of the market.
• Flipping that around, HTML5 elements make excellent fallback content.
  • eg. I use a Flash audio player on one site; and <audio> gives me a functional fallback on browsers without Flash (including iOS devices). Previously the fallback was a link to the mp3 file. (Jeremy Keith has a great post about using this approach)
  • This approach also removes pushback against using variably-supported features as your core solution - sure it might not be as intellectually satisfying as ditching IE and Flash content users, but it's probably got a greater chance of client acceptance.
• The simplified syntax is nice to write.
  • <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> or<meta charset="utf-8" /> ...I can remember only one of these off the top of my head, how about you? :) 
• Curiously, HTML5 seems to open a new development mindset - switching can be a catalyst for using a swathe of new standards. Sure, it's smoke and mirrors, but you might even be able to push a couple of crap browsers off the bottom of your support chart too.

last thoughts

In its purest form, a platform change decision comes down to how much value you get (or the cost of not changing) vs. the cost of the change. For most people the cost of switching to HTML5 will be trivial, so the long-term benefit of merely being ready to use more features is enough payoff.

If you are kicking off a project today and building from scratch, you should definitely use HTML5 - even if it's mostly plain old (X)HTML despite the new doctype. If you're maintaining an existing app, you may as well switch out the doctypes so you can start legitimately cherry picking new features as you have time and opportunities.

I have no idea what we'll be using in 2022. It probably won't be HTML5 any more. But in 2011, I'm using HTML5.