For most of my career as a web developer I’ve produced websites that work without JavaScript. For the JavaScript impaired the sites may be missing a minor visual feature or be a little clunky in places, but they work and the meaning remains clear. It doesn’t bother me that, sometimes, the cost of allowing for sites to load without JavaScript can mean missing out on the latest web fashion. I’m not a big fan of fashion.
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.
I really tried to adopt the commonly advocated view that it’s okay to require website visitors have JavaScript enabled. It was going very well, right up to the final hurdle when I couldn’t resist checking the site I was working on without JavaScript.
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. <header>, <section>, <nav>, <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
If given the choice between an unusable website for some visitors or a little tag bloat, I’ll take the bloat any day of the week. In the demo the bloat adds an extra 14 bytes. On the home page for the site I was working on, it’s 40 bytes. I save plenty more than 40 bytes by minimising my JavaScript and CSS (a single key combo with the YUI Compressor TextMate bundle), so I’m not too concerned about the side effects.
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.”
Comments
15 responses to “HTML5: I couldn’t (quite) do it”
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.
There was also this alternative, which is something I personally wouldn’t consider using: http://www.debeterevormgever.nl/html5-ie-without-javascript/
Thanks for the great links John.
I really like the idea behind the first one, it’s certainly worth consideration. I do have some concerns about generic styling for – the current default – IE8, even if it does only apply to those without JavaScript enabled.
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.
Drew’s article on 24ways linked to research showing 2% of visitors to the Yahoo! home page have JavaScript disabled. I think it acceptable to use that as a benchmark figure for visitors without JavaScript.
It’s not just visitors consciously disabling browser features that we need to worry about, we also need to worry about servers — such as the Google Libraries API/CDN — going down, or bugs in our JavaScript that prevent it from running.
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:
<div id="aside">
<div id="section">
<div id="nav">
Half of those we all probably used before HTML5 was thought of :)
I’m with Peter. While it’s only a small percentage that disable Javascript and some percentage that use IE I just can’t bring myself to develop a site that won’t work with Javascript off. I do basically the same solution that Peter has come up with here and documented it myself some time back.
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.
I’m fine with using JavaScript to emulate HTML5 and CSS3
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:
So, in IE, either the native HTML5 element ONLY will be styled if javascript is on (because the ‘no-js’ class will no longer exist on the HTML tag) or the inner div will be styled and the native element ignored if javascript is off.
It’s a bit messy markup-wise with all those double conditional comments, but I’d rather that than have a page where the layout structure relies upon javascript being activated.