making your site html5 ready pt1

If you have anything to do with html and/or css you should already know about the recently heightened interest in html5. Of course it's all very cool and exciting, but where do we stand (being the eager web developers we are) if we want to start implementing these new tags? Can we simply start using them and assume that all browsers will handle them seamlessly? Are we really web developers if we dare to ask such silly questions? Here's the breakdown.

clearing the skies

Before I start let it be clear that this article is not about any of the new functional html5 elements. Elements like video and audio are unsupported in older browsers and should be approached with graceful degradation in mind. This are elements which require added browser functionality for them to work. This article will focus on the use of new semantic and structural elements (like nav, aside, header and footer, ...), which require no additional browser functionality to be of any value and, at least in theory, should be ready for practical use.

starting with the good

You would assume that making use of these new elements is quite straight-forward. And for most modern browsers this is actually the case. Even though the new elements lack any standard css styling (fe you still have to explicitly define display:block for header and footer elements in css) they are accessible for use in css and javascript and they automatically carry their semantic weight in them.

Of course, when I say most modern browsers you already know what's coming. None of the IE browsers available today allow you to use these elements in css or javascript. On top of that, FireFox 2 has a DOM issue were the engine will immediately self-close each tag he doesn't recognize as html, completely ruining the html structure. The new html5 elements won't wrap the inner elements any longer but will be placed above them, containing nothing.

/* basic html5 */ <nav class="mainNav">...</nav> /* fixed html5 */ <nav> <div class="mainNav">...</div> </nav>

One possible solution is to add the new elements, but strip them from all classes and ids, also making sure there are no direct references to them in the css and javascript. Then, transport the classes and ids to an inner wrapper (preferably using a div element). This is shown in the code example above. This solution will bloat your html like hell and sounds rather pathetic, but in reality it isn't (... quite as bad as you might think). After all, you're still adding richer semantic and structural information to your html document, which is exactly the purpose of these elements.

Currently this is the only know method to incorporate html5 elements without sacrificing any support from most everyday common browsers. Even FireFox 2 should handle this well, as this setup will only result in some unstyled and empty elements scattered through the DOM. Then again, I believe this has very little real world value, so let's see what else we can accomplish if we try a little harder.

sacrifice

If you plan on taking a different route, you should be prepared to make some sacrifices. Currently there is no flexible solution for FF2 users. That doesn't mean people are not working on a solution, but for now there's not much in the way of FF2 support. You can either write a custom js function, fixing the DOM after it has loaded completely (which doesn't sound too maintainable and might cause design jumps) or you could serve your pages as xhtml. Know that this will kill off any page on your site that doesn't validate according to the xml specs (resulting in a yellow screen of death), so it's best to do this for FF2 users only. A risk I'm willing to take with my blog, but for commercial sites or sites that gather user content I would strongly advise against. A detailed explanation of both methods can be found on the html5 Doctor site.

<!--[if lte IE 8]> <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js" type="text/javascript"></script> <![endif]-->

Then of course there is still the IE problem. Luckily here we have a better change of fixing things (which in all fairness is also an IE constant). Quite early on a little javascript was made available to fix html5 support in all IE versions. The html5 shiv principle is quite simple and works like a charm. The code is hosted on Google Code so you won't even have to download the actual file. The rule above will serve the javascript to all IE browsers, leaving the other browser families alone and providing (near) full support for the new semantic and structural html5 elements. Ain't that sweet!

This just leaves us with a group of IE users that's cruising the net without javascript support (for whatever reason). There's not much we can do for them, but there is something. What we're going to do is serve them an extra css file based on the non-html5 elements. This means serving them a seriously degraded design (as you won't have as many structural elements to work with), but it does give you an opportunity to even out any graphical nonsense resulting from styles that could not be applied. How much you'll have to degrade your design will depend on how many html5 elements you used and where you added your classes and ids, but it will never be as bad as leaving the site as is. The result will still be a fully functional site, only with a bare bones design.

conclusion

Actually providing this extra css file is a little harder than you might expect, especially if you want to be a gentleman about it, so I'll leave that for the next article. Still, this article should have given you a good enough idea of the current issues with implementing new semantic and structural html5 elements. Reading all this might discourage you, which isn't all that strange as there are still plenty of ifs and buts here, but for personal and non-commercial projects I would say that things are looking bright enough to start experimenting with these new elements. Alternatively, be sure to check FF and IE stats before you consider sacrificing browser support. You might be surprised how many people out there are still using outdated browsers.

The next article will delve a little deeper and will provide a method to serve IE users without javascript support with an alternate layout and a nice warning message. So stay tuned.