Thursday, January 8th, 2009

Backwards compatibility and HTML 5

Category: Ajax, HTML

John Allsopp has a thoughtful piece that races some old concerns about the new tag set in HTML 5, and how we will ever be able to jump on that train when the cabooze still has IE.old train cars.

It is great to have new semantics for <section> and all, but what will browsers do with these new tags?

John walks through a simple example with the new tags, shows some issues, and then wonders if we could use the existing extension points (attributes):

Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:

<div structure="header">

Let’s see how our browsers fare with this.

Of course, all our browsers will style this element with CSS.

  1. div {color: red}

But how about this?

div[structure] {font-weight: bold}

In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.

John then goes on to discuss the potential use of the role attribute, and more.

It feels like there are two issues here:

  1. Are new tags the right way to provide new semantic value
  2. Are there work arounds to back/forward compatibility.

Without compatibility, it will be impossible to get this off the ground for many people. What if we mix both worlds, and a shim is put in place to convert the new tags to divs and the like at runtime for browsers that don’t support it. Is that enough?

You can get IE to support new tags as shown in this example by using document.createElement().

Posted by Dion Almaer at 7:39 am

4.3 rating from 11 votes


Comments feed TrackBack URI

Your suggestion to “convert the new tags to divs” at runtime for browsers that don’t support them is exactly what we’ve done at Shepherd Interactive so that we can serve XHTML5 on our company website. We’ve made an XHTML5 Support WordPress plugin which does exactly this. It adds a JavaScript shim to the HEAD for IE7, but for IE6 it replaces all HTML5 elements with DIVs, so that:
SECTION becomes DIV.html5-section
ARTICLE becomes DIV.html5-article
Additional CSS rules, of course, can then be included to style these classified DIVs for IE6.

Comment by westonruter — January 8, 2009

I say go for the new tags and sod IE6! Consider if all webdevelopers deployed the newest of technologies, it would help force along the development and stability of browsers… Git er done!

Comment by oopstudios — January 8, 2009

@westonruter, why did you choose XHTML5 over HTML5?

Comment by Amenthes — January 9, 2009

@Amenthes, because we have inline SVG and, more importantly, HTML5 block elements are parsed correctly in Firefox 2 when in XHTML mode. See FF2 bug

Comment by westonruter — January 9, 2009

And what happens when your visitor has JavaScript disabled or is on a mobile device without JavaScript?

Comment by zachleat — January 9, 2009

@zachleat, If they’re on a mobile device, they won’t be using IE7, so that shim won’t be necessary (at least that one). If they’re on IE7 with JavaScript disabled, then they’re out of luck, and should switch to Firefox, Safari, or Chrome ;-)

Comment by westonruter — January 12, 2009

Leave a comment

You must be logged in to post a comment.