HTML 5: Hail or Fail?

Those who have worked with the Web for many years usually have a wish list of things about HTML they would change. Personally, I loved the proposed XHTML 2. It was a very nice spec. It seemed that if Web browsers would finally support XHTML properly, the potential would be limitless.

Instead, that dream died, and we got HTML 5 in its place. Granted, we could be dealt much worse.

There are a lot of things I love about HTML 5, but there are also some things I am not so fond of:


Early in HTML’s history, different browsers understood different elements, so the W3C decided to introduce the DOCTYPE. The idea behind a DOCTYPE was that a browser that didn’t understand a specification could download it from the Internet and display the page anyway. In order to keep older webpages without DOCTYPES working correctly, Internet Explorer (and later other Web browsers) displayed all documents with a DOCTYPE in a new standards-compliant way and those without a DOCTYPE in an old-fashioned way, called “quirks mode”. Now, HTML 5’s DOCTYPE is long enough to keep browsers from displaying the page in quirks mode, but since it doesn’t include a URI,  it’s not useable by browsers that aren’t designed to work with HTML 5.

New Semantic Elements: Hail!

In HTML 4, if we wanted to break up a section, we used generic elements like <div> and <span>, which became so ubiquitous that they had no real meaning. HTML 5 gives us all sorts of alternatives, like <aside>, <article>, <header>, <footer>, and <mark>, which say so much more about the structure behind the content of the document.

Keeping Old Presentational Elements: Fail!

Some elements, like <b>, <i>, and <br> are being retained in HTML 5, even though it is simple to obtain the same effects using CSS, which is supported by every Web browser. This encourages sloppy coding practices. Thankfully, some presentational elements, like <font>, <center>, and <big>, have been removed.

Plugin-less Video and Audio: Hail!

It will be nice not to have to download a whole slew of browser plugins in order to view video and audio on the Web. That is, when the entire Web changes to accommodate the new HTML 5 <audio> and <video> elements.

Figures: Hail!

One element sorely missing from HTML 4 is the ability to associate a picture with a caption. Now, one can do this using HTML 5’s <figure> and <figcaption> elements.

Canvas: Hail!

Already supported in many modern Web browsers, one of the fastest HTML 5 elements to be adopted is the <canvas> element, which allows content to be drawn directly in the browser. Brilliant!

Breaking Form Input Labels: Fail!

The main purpose of the <label> element is to associate a form control (like a checkbox, for example) with text that describes it (the label). In HTML 4, clicking a label for a text field will automatically move the caret (blinking cursor) to that text field. Similarly, clicking on a label for a checkbox will check that checkbox, and so forth. Many operating systems also do this, so this behaviour is expected on a webpage. In HTML 5, this is no longer so. Not only will this change greatly annoy Web users, but it will cause developers to eventually forget to use them, which will be a disadvantage to those with visual disabilities who need assistive technologies to read websites to them. (Recently, HTML 5 has been updated to say that using a label to select a form control is permissible if it is native functionality for the operating system to do so.)

Custom-Numbered Lists Are Back: Hail!

HTML 3.2 allowed the developer to start a numbered list at a specific number (e.g. 2). HTML 4 deprecated this, for some ridiculous reason. HTML 5 again says it’s okay. (Lists can also use the new reversed attribute to indicate that a list is in descending order rather than ascending order!)

No More Frames: Hail!

Usually people don’t rejoice when they lose options, but in this case,  the elimination of frames will mean a better Web experience for everyone.

No Head Profile Attribute: Fail!

While a minor attribute, it was useful in a number of microformats.

DOM Updates: Hail!

Anyone who’s worked with the JavaScript DOM knows how nice it would be to be able to access all elements of a particular class on a page. Now we can, with HTML 5’s getElementsByClassName(). Also, commonly supported attributes innerHTML and contentEditable are now officially standardized.

So, what are your thoughts on the HTML 5 specification? What do you like, and what would you change?

2 thoughts on “HTML 5: Hail or Fail?

  1. Howdy!

    Even I found the doctype change strange.

    Input labels, on the other hand, appear to be handled by current browsers the same as before. This is one area where I don’t expect browsers to follow the specification.

    I’ve been developing using HTML5 for the last little while; the profile link on this post links to WebCore, whose default theme uses HTML5. So far, with a little JavaScript kludgery for older browsers like IE, everything appears to work fine.

    — Alice.

  2. Thanks, Alice! That’s good to know. Thankfully I also haven’t seen any browser drop the functionality of being able to select a form input by its label, and I hope I never do. By the way, nicely laid-out site you linked to.

    — Jon

Leave a Reply

Your email address will not be published. Required fields are marked *