Currently, web development is undergoing some major transitions: the HTML5 spec is being developed and CSS3 is being implemented. The browser wars have returned, although this time around, it’s a battle to win developers’ hearts by implementing the newest standards.
Now is the time for developers to re-evaluate their past practices; moving on from the old and embracing the new. I kept that ethos in mind when upgrading the Soupgiant WordPress base theme recently. Among other things we were porting it to HTML5.
Everything looked fine in Chrome, Firefox, and Opera. It was, predictably, Internet Explorer that threw a spanner in the works. For an artist’s impression, visit the demo in IE8 (screenshot via WebPageTest):
Without Remy Sharp’s HTML5 enabling script the site I was working on was unusable, if anything, it looked worse than the demo provided.
I couldn’t, in good faith, sell a website to a client that some visitors would find unstyled, half styled or difficult to follow in places. I didn’t want to throw out the baby with the bathwater, the additional meaning provided by HTML5 elements is just too great.
<article>, etc all provide meaning to a document that it’s difficult to justify going without.
It’s with the additional meaning in mind that I decided to go with – what I’ve dubbed – HTML4.5. HTML5 provides the meaning while using traditional HTML 4 tags as hooks for styling. It introduces a bit of tag soup, as instead of
<article id="content"> ... </article> the code becomes
<div id="content"><article> ... </article></div>.
The improvement to site I was working on was immediate, as you can see by visiting the html4.5 demo in IE8 (screenshot via WebPageTest):
I don’t care about tag soup
A technically beautiful site is the ideal but if a portion of your visitors can’t use it, then the beauty isn’t even skin deep. As Drew McLellan said recently on 24 ways, progressive enhancement is “also known as doing our jobs properly.”
Great stuff, Peter!!
I’m glad someone else doesn’t see JS as an adequate stop-gap for supporting non-HTML5 browsers. ; )
The XHTML buff in me likes the term HTML5 Transitional, though. ; P
You might be interesed in Nicholas Gallagher’s HTML5 fallback strategy for IE.
Thanks for the great links John.
Like you, I’m not sure I’d use the second one. While elegant, it does add a similar amount of code bloat as the method described above.
What about being forced to dumb down your code for a sub
par & historically behind the curve browser?
I disagree that I’m dumbing down my code to support a sub-par browsers, I’m dumbing down my code to support the current standard browsers (IE7 & IE8).
On Big Red Tin, 7% of visitors use IE so we could ignore it without pushing our luck too much. On a clients e-commerce site, 61% of visitors use IE so — sub-par or not — it can’t be ignored.
What is the chance that an average web user is going to
know how to turn off js or CSS? Most don’t even know that there are
other browsers than IE. The only people who turn off js know
they’re doing so, are most likely developers or advanced users, and
are handicapping their online experiences. There’s going to have to
be a line of where we stop support for random cases, otherwise your
work will never be finishable.
It’s because most users don’t know there are any other browsers than IE that we need to take special care to allow for it’s particular problems. I used IE8 in the examples and screen shots above in recognition of it’s status as the current default.
I agree, if we allow for too many use cases we’d never finish our work. If a solution is practical, however, and will take minimal additional code to solve it, we should do so.
<div><nav>is a perfect example of minimal work to solve a problem.
Hmm is 2% really worth supporting then? I do understand what you mean about Google’s API going down, even though that happens more rarely then the possibility of your entire server going down.
I guess it would depend on your site and target audience and whether or not that downtime would seriously hurt anything.
As for the issue, why not have cleaner code by doing what A Book Apart suggests in HTML5 for Web Designers and just IDing your divs with the new HTML tags? For example:
Half of those we all probably used before HTML5 was thought of :)
Chris’s post is Getting Ready for HTML5. At a little over a year old, it demonstrates how long we’ve been having, and will – no doubt – continue to have, this discussion.
Thanks for this. I too struggle with the idea of unstyled
HTML5 elements rendering a page unusable to IE users with JS turned
off, even if they are paranoid fringe case users of a crappy
browser. :) My plan is to wrap the fall-back divs in conditional
comments, use Modernizr, and add selectors for the fall-back divs
descended from the .no-js class to the same styles that _should_ be
applied to the HTML5 elements.
features when doing so is progressive enhancement, but I agree that
it shouldn’t be used to make the site readable and usable. Keep in
mind that 2% of Yahoo’s visitors is probably millions of people, or
at least in the upper hundreds of thousands.
Yeah, I realise Yahoo’s scale means 2% has rather more of an effect when compared to 2% of visitors to, our corporate site, Soupgiant.
A relatively small ecommerce site, on the other hand, could find 2% of its income is the difference between profit and loss.
I’m with Derek Pennycuff on this. I’ve been working on putting together a Base Site for my projects — sort of a stripped-down HTML5 Boilerplate more tailored to my own needs. My approach also involves Modernizr (so the HTML tag will either have a js or no-js class) and the following markup (I’ve used section as an example HTML5 element):
Then styling is applied thus:
Comments are closed.