Digithoughts

HTML5: What Has Changed and How To Adopt It

June 11, 2010 by Nicholas Davison

This is the final part of a week long series. The overview can be found here.

HTML4 To HTML5 – What Has Changed?

HTML4 has been around for a long time. In that time, some aspects have become out dated, it has become apparent that others have the potential to do more and some simply merited clearer, more concise usage rules.

We have already covered most of the new element. The changes are generally many but subtle so probably a little excessive to cover here. That leaves us with “What’s gone from HTML4?” The list is below, along with links to the official documentation for each of the other sets:

Three main classes of elements have been removed:

  • Removed for being purely presentational: basefont, big, center, font, s, strike, st, u.
  • Removed for negative usability issues: frame, frameset, noframes.
  • Removed due to lack of use, confusion or duplicated functionality: acronym (use abbr), applet (use object), isindex, dir (use ul).

 

Two main classes of attributes have been removed:

  • Obscure attributes you probably didn’t use anyway like nohref on areas and scope on tds.
  • Attributes that were used to convey style and can be better handled via CSS such a many uses of align, background, bgcolor, cell padding and cell spacing, etc.

Adopting HTML5

Not Finished Until 2022?

A lot of people panicked when Ian Hickson, the editor of the HTML5 specification, produced a timeline that said HTML5’s proposed recommendation wasn’t expected until 2022.

You can pretty much ignore that figure.

Getting every browser manufacturer to implement every last feature of a specification – and not just implement it but perfectly implement it – takes a very long time. By that standard, HTML4, XHTML, CSS2, all things we consider practically usable and have done for years are either not ready or have only just become so.

The 2022 date is meant as the expected point where multiple browsers have a full implementation of every last feature. So long as you’re careful about what you use, most of the best bits are already available today or very soon will be.

What Happened To XHTML?

Programmers like the well formatted, XML based, nature of XHTML. They hated the messier, lazier, SGML based, nature of HTML. That was understandable – it is MUCH easier to write code to parse consistent XML than messy SGML and so made developing great new tools much easier.

About a year ago, the XHTML2 working group gave up on XHTML2 and told everyone to go with HTML5.

There was a lot of initial panic. The good days of XHTML were giving way to the bad old days of HTML!

Then it was pointed out that XHTML2 was mostly just a whole new set of tags for XHTML – something HTML5 was already doing just fine with. Just like XHTML was really just HTML4 with XML rules applied, there was no reason you couldn’t write HTML5 with XML rules applied and create a kind of XHTML5 if you will.

So, in short, HTML5 doesn’t mean the death of XHTML. You can (and should) still write clean XHTML styled HTML5.

Backwards Compatibility

HTML5 has been written to make it as easy as possible for older browsers that don’t support given features to fall back in relatively sensible ways.

For example:

The new layout elements can be simply regarded as <div> elements.

The new input types can simply be regarded as type="text". It won’t be ideal but forms will at least still work (albeit losing validation, helpful pickers, etc.)

<video> and <audio> elements have simple structures defined so that fallback text can be provided for older browsers that don’t know what to do with the newer tags.

Current Support

Generally speaking, you can assume HTML5 code will be forced to fail back for Internet Explorer 8 and lower. Internet Explorer 9 will be bringing a lot of HTML5 support but isn’t out yet.

Firefox supports a lot of HTML5 though it gets patchy in places (for example the video player doesn’t handle variable speeds). It also doesn’t support Web SQL DBs yet.

Safari and Google, both running on Webkit, support a lot of HTML5, though they have issues with geo-location, and a lot of online/offline features.

Opera supports a lot of HTML5 though it falls behind on geo-location, drag and drop and a few other minor areas.

The spec hasn’t hit its first final draft and won’t do so for another year or two. Features like video, audio, canvas and semantic layout are pretty solid and so most browsers (except for IE until v9) support them. The more cutting edge features like the new API code is further off and thus more patchily supported.

In conclusion, for now: With the exception of IE8, most modern browsers should be pretty stable with basic usage of the more common features. Going beyond that, test and confirm your target platforms will support anything too wild that you might want to try.

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.