Anthony Short — Friday 18th December, 1:21pm

A Real-World Case Study on HTML5

There’s a lot of talk on the web lately about HTML 5, but not many real-world case studies about its implementation. We’re talking about it, but it seems few people are actually doing it.

From a business point of view this is completely understandable - it’s risky. Being dependent on Javascript is the one roadblock stopping most people from implementing it everywhere.

I won’t discuss the fundamental aspects of HTML 5 (ie. the new elements), instead, I’ll discuss about the ups and downs of the real-world implementation of HTML 5.

We recently designed and built a site entirely with HTML 5 for Melbourne law firm, Grigor Lawyers. It’s a single page website and fairly straight-forward, so we decided to take a leap of faith and use this as a learning experience.

Go and take a look at the source of Grigor Lawyers and then come back. I’m sure there will be comments on the structure and some arguments about semantics, and these are all welcome! It’s a learning experience for everyone and discussions like this help iron out the creases in our knowledge and possibly even the spec. It’s not every day we build a site with the HTML spec sitting in another window!

A New Way of Thinking

HTML 5 comes with more than just a bunch of new elements to increase the semantic juice of your site, it brings with it a whole new way of thinking.

The ‘header-section-footer’ approach to markup is one that actually makes a lot of sense when talking strictly about the semantics of information. A section is a block of content, which usually includes an introductory overview of the forthcoming content and additional meta-information about it’s content.

A lot of HTML 5 is about following this header-section-footer approach. That is, the page can have a header, section and footer, and within those sections can be another group of headers, sections and footers which take the scope of the parent sectioning element.

<header>
<section>
	<header>
	<section>
		<header>
		<section>
		<footer>
	<footer>
		<header>
		<section>
		<footer>
<section>
<section>
<footer>

Of course, not every sectioning element needs to have all 3 elements. You can use any combination of them or none at all. In fact, it gets quite complex, so you might just want to take a read of the HTML 5 spec yourself.

At first, I wasn’t happy with the elements of HTML 5. It feels as though it’s directing the page layout. But you need to move past what you know is a header and footer. Breaking down your content to this fundamental level, regardless of design, allows you to structure it with semantic meaning, but still create whatever design you’ve come up with. With HTML 5 I think we need to be extra careful that we don’t fall into the trap of uninspiring design patterns.

The Ups and Downs

We were weary of embracing HTML 5 because of the single fact that IE requires Javascript for it to work properly. As much as I’d love to ignore it we just can’t. There were a few other downsides…

The Mysterious Unknown

We don’t know if certain browsers will freak out when targeting new elements with CSS or if that Javascript we’re using will fail completely. All of my knowledge tells me this is unlikely to happen, after all they’re just elements like everything else, but there is a whisper in the back of my mind telling me that something could go very wrong. We just don’t know. It hasn’t been used widely enough for these potential bugs to surface.

Findability

One thing we do as designers and developers, apart from creating beautiful and functional sites, is help people find them. With clean, semantic markup and interesting content, we allow Google to find the site and tell the world. Using the new structure for headings (<hgroups>’s can have a whole set of new headings inside them whose ranking is nested inside the previous heading level of the section), Google might thinking we’re spamming h1’s all over the page in an attempt to fill keywords.

This could possibly be detrimental to a site’s ranking. Apart from this problem, Google doesn’t yet recognise the semantic value of the new elements (to my knowledge), so it’s not really providing much functional benefit over HTML 4.

Our solution to this was to not use <hgroup>s and stick to the heading structure of HTML 4.

Semantic goodness

The improvement to the page semantics is huge. It’s also much easier to scan and read. When everything isn’t a <div>, your code becomes much less of a mess. <div>’s with id’s and classes add some semantic meaning, but they’re still just meaningless <div>’s.

This alone makes HTML 5 worth it for me. It’s possibly just because it allows our styles-heets to be cleaner. Most of the time, we wouldn’t feel safe doing something like this:

#our-special-element div { }

That div could be anything! It’s meaningless. For people reading the CSS, it’s much easier to understand exactly what is going on. This takes me to my next point…

Meaningful CSS

What I really like about HTML 5 is the fact that it also gives our CSS more meaning and context. Rather than using seemingly random class names and ids, we now have a consistent and meaningful way of targeting elements. Due to the structure of HTML 5 it naturally gives our CSS implied meaning about the structure of the content, something that we didn’t have when just using classes and ids.

Our approach

Hopefully, you’ve taken a look at Grigor Lawyers by now so you can follow along. You’ll notice that the design can fairly easily be broken up into sections. There’s the top blue area, ‘About’, ‘Our People’, ‘Areas of Practice’, ‘Contact’ and the meta information about the content.

Here’s the basic structure:

<div id="document">
	<header><header>
	<section id="about_us"></section>
	<section id="our_people"></section>
	<section id="areas_of_practice"></section>
	<section id="contact"></section>
	<footer></footer>
</div>

HTML 5 is all about scope. This <header> and <footer> describe the page as a whole, because their parent element is the <body>. Remember, <div>’s are meaningless and provide no scope. I was tempted to use :nth-child or child selectors to target each section, for example, the ‘Our People’ section could have been targeted like so:

#document > section:nth-child(2) {}

Or like this if you want to support IE:

#document > section + section {} 

For obvious reasons, this wasn’t a good idea. This brings me to my next point - you shouldn’t try and avoid ids and classes completely just because you have these new elements. I think naturally, my first instinct was to try and avoid them as much as possible because I had these new elements instead. But you quickly realise this is a really bad road to go down.

Marking up ‘Our People’

The ‘Our People’ section has the most interesting markup of all the sections. I marked it up trying to completely forget the fact there was going to be a Javascript effect on the profiles.

<section id="our_people" class="alt">

	<header>
		<h3>Our People</h3>
		<nav>
			<a class="back-to-top" href="#document">Back to top</a>
			<ul>
				<li><a href="#about_us">About Us</a></li>
				<li><a href="#our_people">Our People</a></li>
				<li><a href="#areas_of_practice">Areas of Practice</a></li>
				<li><a href="#contact">Contact Us</a></li>
			</ul>
		</nav>
	</header>

	<section class="content">
			
		<article id="persons_name">

			<figure><img/></figure>

			<header>
				<h4>Name<h4>
				<p class='position'>Position</p>
				<p>Intro paragraph</p>
			</header>

			<section class="content">Content</section>

		</article>

	</section>

</section>

These profiles don’t really look like articles do they? But here’s what the W3C think we should use the <article> element for:

The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

This seems to fit that description no? Awesome, instead of using a meaningless <div> for marking up these profiles, we’ve now given them much more meaning.

The way I approach the decision of making something an article, section or div is this: Does it need it’s own scope? In this case, each of these profiles could use their own scope - a heading, section and footer relating to the profile itself. If something has an introduction paragraph or a heading, it’s usually a section or article.

One thing I’m not entirely happy with is the <nav> element here. In this scope, the nav should really be navigation for the ‘Our People’ section. It needed to be in the section, but I wish I had a way of manually defining the scope of the element. <nav scope="body"> or <nav scope="#document"> - something to that effect.

All of this, and I haven’t even thought about the styling yet.

Styling it up

One thing I noticed when using HTML 5 was that I became much more dependent on advanced selectors like the direct child selector (‘>’) because I used less ids. However it does give more meaning:

#document > header 
{
	background:url('../images/bg-header.jpg') bottom right no-repeat;
	border:1px solid rgba(255,255,255,0.4);
	border-width:1px 0;
	padding:0 0 36px;
	height:354px;
}

So we know we’re targeting the header of the entire page. Sure I could have added an id - #page_header - but that doesn’t give as much information about the structure of the document… arguably.

I won’t go through the progressive enhancement I’ve used on the site, as that topic has been done to death for the last couple of years and I’m sure we’re all aware of it’s benefits by this point. Using this new-fangled HTML 5, I wanted to go all out with CSS3, but it just wasn’t possible with IE creating an uncomfortable social situation similar to having a weird guy in the room that no one likes but everyone is too be polite resulting an awkward silence… But I did get away with using webkit’s multi-columns in the staff profiles and some nice transition effects :)

Our conclusion

The Javascript dependency of HTML 5 in it’s current state (thanks to IE), will make it entirely unfeasible for most projects. However, whenever you get an opportunity to use it (on your own site for example), take the leap and give it a go. You’ll learn a lot about the different approach to marking up a document and will hopefully take something worth knowing back to your plain ol’ HTML 4 builds. At the very least, it will give you a leg-up on others in the field by being ahead of the curve.

I’ve found myself looking at print work, like brochures, posters and cards and thinking how I would mark them up in HTML 5. It may seem strange, but it’s getting me thinking about how I would structure designs which don’t follow the stock-standard approach. A trend that is appearing on the web lately is breaking out of the standard ways of thinking about ‘what does a website look like’, and it’s one worth following.

What I’d like to do for future projects where HTML 5 isn’t feasible, is use a pseudo-HTML 5 approach. Using the same header-section-footer approach with classes instead of elements will allow us to keep practicing the way we build our sites and structure our CSS, while remaining technically sound. We’re going to need to practice, refine and rework our current thinking and style of coding when HTML 5 gets into full swing.

Blog

• Announcements
• CSS
• ExpressionEngine
• General
• jQuery
• Testimonials
• Tutorials
• Archive