Now that we’ve seen how to use some of the newer whiz-bang features of the draft HTML5 standard, it’s time to take a few steps back and take a look at some of the other differences between HTML4 and HTML5.
This article is intended to be a useful overview, not an exhaustive reference, but remember that things are still and always changing. The complete, up to date list of all the technical differences may always be found on the W3C’s site. You also may want to refer to this document for the actual details of the HTML5 specification itself.
The first thing you should know is that, perhaps for the first time, the development of a language standard is acknowledging the real world. In order to keep file compatibility with the current standard – which is technically HTML 4.01 – the brave decision was made to separate the way the web browser renders files from the way we, as developers, must write them. So the browser, or “user agent”, must still process HTML4 constructs like the center element, because there will still be millions of files on the Internet that happen to use it. But we won’t be writing any more HTML with center; it’s simply being dropped from the language (use CSS instead). This compatibility goes both ways: older browsers can (and will) simply ignore HTML5 code without screwing things up.
No More Frames
This is great news to those of us who slogged through the 1990s. To be exact, the elements frame, frameset, and noframes are being removed from the language, as well as acronym, applet, basefont, big , blink, center , dir, font, isindex, strike , tt and u. All of these can be handled using CSS or other methods.
You’ll also have to learn to get along without using tables for layout; while tables themselves are still part of HTML5, they’re not intended for placing pixels any more. Here’s what the spec says:
“Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming, because tools attempting to extract tabular data from such documents would obtain very confusing results.”
So all the attributes that let people create those perfectly laid-out, tinted tables are gone, like align, bgcolor, border, cellpadding, cellspacing, height, nowrap, rules, valign, and the big one: width. The mantra: use CSS instead.
I’ve been trying my best to break it to you slowly, but frankly, all presentational elements are coming out of HTML5. My advice: learn lots more CSS, until you can quote chapter and verse in your sleep.
Good News
The good news is that even though this is a big change, it’s a change for the better. Browsers of the future (just another month or two!) will become more powerful because of the move towards the cloud, so that they’ll be able to handle more on their own. We’ve already seen that with things like Ajax, and now with video/audio embedding and such, it will be far easier for us to code in a straightforward manner and let the browser figure out the details. For instance, new structure elements include article, aside, figcaption, figure, footer, header, hgroup, nav, section, and summary, all of which refer to the structure of the document itself and leave rendering to the browser.
There are still some new elements that deal with text on a detailed level, however: you’ll code wbr when you think it’s possible to do a line break, but the browser will decide for you. Another hint element is bdi, used to mark an area where bidirectional text formatting can be done (primarily for mixing left-right and right-left languages in a single document). Its complement, bdo, lets you explicitly override and force a particular directionality. For even more slick internationalization, the elements ruby, rp, and rt are included for ruby annotations, which are meant for pronunciation aids rather than for Ruby On Rails programmers.
The more high-level new elements include things like canvas, meant for specifying an area for drawing a bitmapped graphic on the fly, such as a data graph or game graphic; meter is a placeholder for a numeric measurement of an expected size (and is eerily similar to format in ancient FORTRAN), while progress is its graphical counterpart, to be used where you want a progress bar. Last, but not least, there are the multimedia elements (audio, video, source, embed) that we covered in detail in the last article.
