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):

HTML5 as seen in IE8

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):

HTML4.5 as seen in IE8

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.”

One of the disadvantages of using Selectivizr is it rules out using a CDN for one’s style sheets. To quote their site:

Style sheets MUST be hosted on the same domain as the page due to browser security restrictions. Likewise, style sheets loaded using the file: protocol will not work.

Normally, particularly for low traffic sites, this wouldn’t be of great concern. As we share style sheets across sites (both Big Red Tin & Soupgiant use the same CSS) and use the CDN feature of W3 Total Cache on our hosted WordPress sites, it could cause problems down the track.

After umming and ahhing for a couple of days, the following solution involving conditional comments, occurred to us:

<!--[if gte IE 9]><!-->
<link rel="stylesheet" href="http://cdn.example.com/styles.css" type="text/css">
<!--<![endif]-->

<!--[if lte IE 8]>
<link rel="stylesheet" href="/styles.css" type="text/css">
<![endif]-->

With a few lines of conditional comments, browsers supporting the relevant selectors natively can take advantage of the performance boost from a CDN while developers can take advantage of the advanced selector support provided by Selectivizr for IE<9 users.

We’ve set up a quick demonstration in which three paragraphs have different ARIA roles – featured, unfeatured and neverfeatured – different styles are applied to each paragraph using [role=something]. The demo renders fully in: IE 6-9beta, Firefox (Win & Mac), Chrome (Mac), Safari (Mac), and Opera (Mac).

We believe very strongly in semantic mark-up and getting things working as much as possible in as many places. We believe in graceful degradation. I believe in closing tags once they’re opened and I didn’t like how HTML5 didn’t demand a trailing slash on stand alone elements. That just seemed like chaos.

Jeremy Keith‘s new book, HTML5 for Web Designers is a no-nonsense 85 pages of the good and bad in the HTML5 specification. It explains how the spec is a lot more open and forgiving than previous specs. It also explains how much work was done to ensure better semantics than previous versions of HTML.

You’re probably thinking exactly what I was. How can any 85 page book tell me what I need to know about the largest HTML specification thus far? Is 85 pages even a book or is it more like an extended pamphlet? How can I take this seriously?

We bought the book largely because we trust the work Jeffrey Zeldman does. This is the first book he has published under Happy Cog’s new A Book Apart label. I thought that if anybody can get a writer to condense all the info I need into a short read, it’s Zeldman. But no pressure, JZ.

The important things it explains is how HTML5 can be used to include rich media on your websites, how it improves web forms (which got me really excited) and how it improves on semantics. And yes, it does actually explain them.

It explains these topics in enough detail that I could start using them today.

I want to keep learning and improving my knowledge of web-based coding. At the same time, I’m running a business now as well as continuing to produce a weekly podcast and trying to have a life. It’s hard to keep up with all the details of a new spec.

It turns out, all I ever wanted was an 85 page book that explained everything I needed to know and cut out all the stuff I’ll never use. I don’t need a beginner’s book but I also don’t want an expert’s tome. I want an executive summary and that’s exactly what this book is. If that’s all you need, look no further.

HTML5 for Web Designers by Jeremy Keith is available from the A List Apart store in paperback or ePub.

While neither the xHTML nor the CSS on this site validates, we consider it to observe best practices.The HTML fails validation due to the following problems:

• One of the WordPress plugins we use on the site inserts JavaScript with unencoded ampersands in the URL. This isn’t a best practice but unfortunately it’s beyond our control;
• The <html> tag has a class attribute;
• Two of the fields in our comment form have an unrecognised value for the type attribute.

The CSS fails validation due to the following problems:

• We load the YUI 2.7.0 CSS reset, base and fonts files from the Google AJAX API servers. These files contain star hacks for IE targeting;
• We use browser extensions to implement CSS rounded corners and rgba backgrounds;
• Until I started writing this post, we styled a heading with font-size: 145.4545%%.

That last one was a typo, and has since been fixed.

Justifying the invalid CSS

We’d prefer to avoid the star hacks in YUI’s CSS. If we self-hosted the files they’d be moved into the CSS files with our other IE specific hacks and targeted with conditional comments. Our compromise is to load the files from Google’s server with the aim that our site will load faster. Either the user will already have the files in their browser cache, or the user will load the files from a closer, faster server on Google’s global network.

The W3C’s CSS validator also screams at us for using CSS3 browser extensions and rgba backgrounds. While the browser manufacturers are still trying out their implementations of the new specs, we’ve no choice but to use these for the time being. As they iron out their implementations and move them over to the specified properties we can remove these. CSS3 junkies could probably have skipped this paragraph.

Justifying the invalid HTML

This site uses xHTML. We’ve discussed using HTML5 but WordPress, which powers Big Red Tin, isn’t ready to drop the /> from self closing tags. At this stage the HTML5 spec is too dynamic for our liking. Have a late afternoon snooze and the spec is likely to change during your siesta.*

Depending on your point of view, and even what you are coding, it is either fortunate or unfortunate that browsers don’t always follow specs to the letter. We’ve taken advantage of that to throw one of the biggest advantages of HTML5 into our xHTML. In our comments form, we’ve used HTML5 type attributes for two of our fields: <input type=”email” … /> and <input type=”url” … />.

In browsers that do not support these types of inputs the type falls back to the standard of type=”text”. In browsers that do support input types of email and url, it prevents the user from entering an erroneous value. For users of the iPhone or iPad, a special keyboard is presented to make entering an email address or URL easier. In browsers that support the new HTML5 input types, the behaviour is identical regardless of the doc type.

The iPhone displays different keyboards for HTML5 input types

It may be breaking some of the rules of standards. To me it’s not so much about standards as best practices and giving the user the best possible experience on a site, even if this means breaking the rules sometimes.

Don’t take that to mean that we’ll be reverting to table layouts, or insert code such as <a href="#"><h1>Heading</h1></a> into our xHTML. It’s bending the rules around the edges, which is no different to using vendor prefixes to make use of CSS3.

*Yes. I know this is an unfair characterisation. A lot of very important people, with very important lawyers, are working hard to change this.