Of all the standards that a front-end team might want to implement, those that concern the identification and graceful degradation of cross-browser feature sets can be the hardest to define.

With that in mind, I’ve been poking around the front-end community looking for possible solutions. By far the most common approach—and one that gains an astounding level of attention in the community—is to implement Modernizr, a JavaScript feature sniffer created by Faruk Ate?, Paul Irish and Alex Sexton.

Unfortunately, despite my respect for the developers involved, I just can’t advocate Modernizr as a solution. Let me explain why; but first, let’s revisit some concepts that are going to be quite relevant…

The web standards trifle

The separation of structure, presentation, and dynamic behaviour is imperative to web standards. To that end, Andy “Malarkey” Clarke wrote a fantastic post detailing a method he liked to use to explain this fact to clients. He entitled it “the web standards trifle”.

In Andy’s metaphor, the separation of concerns can be imagined as follows:

1. Sponge

   This layer is your content, marked-up with well structured and valid semantic HTML. This HTML provides more information about each piece of content and allows any device reading the code to output as appropriate.

2. Fruity jelly

   This is your presentational layer. This separates all your presentational code into CSS, potentially allowing a user to override it with their own, or for you to serve something different based on context, e.g. a print or mobile stylesheet.

3. Custard

   This is the layer that accommodates any on-page behaviours. In the world of web standards we use this layer to progressively enhance our HTML and CSS layers with more interactive magic. I’ll come back to this later.

The true virtue of this divide is that the presentational (jelly) and behavioural (custard) layers can potentially be removed or overridden without affecting each other, or the content and markup beneath. This is hugely important if we want our websites to maintain client agnosticism and improve accessibility.

Progressive enhancement

Following the publication of this article there have been several suggestions that I explain the difference between graceful degradation and progressive enhancement. Suffice to say, this is something I have covered previously in another article.

Browser vs. Feature Sniffing

Browser “sniffing” is the act of attempting to discern a user’s browser by some means. This “awareness” can then be used in conditional code to control output or interaction for a specific browser. This technique was used a great deal in days of yore, when browsers had very different rendering engines and didn’t all conform to web standards. However, it was only ever really required in JavaScript.

The old school way:

if (document.all) {
    // IE4
    height = document.body.offsetHeight;
} else if (document.layers) {
    // NN4
    height = window.innerHeight;
} else {
    // other
    height = 0;
}

Not a good solution

There are problems with the method used above; for one thing, it is not the most direct method of identifying a browser. However, putting that aside for the moment, there are issues even with the theory of browser sniffing:

It’s quite obvious that browser sniffing does not scale. As new browsers are released, the sniffing code will need updating.

To make matters worse, many manufacturers developed their browsers to identify themselves incorrectly to get around legacy browser sniffing code. This ultimately meant that sometimes browsers were misidentified.

Ultimately browser sniffing is not a good solution. If you adopt it, you will usually end up maintaining separate streams of development whenever you need to add or update features. There are ways to mitigate that pain, but what if there was a better solution?

Feature sniffing

A more scalable approach is to use object detection in JavaScript to discover if a feature is available before you use it. An example of this might be:

if (document.querySelector) {
    element = document.querySelector(selectors);
}

The obvious advantage here is that it is browser agnostic; there are no assumptions as to which browser is involved at all. Using this technique, we overcome the scalability and maintenance headaches incurred through browser sniffing, and we can develop for graceful degradation from the outset.

CSS is a DSL that lacks features

Now, that’s all very well and good when we’re talking about JavaScript, but what happens when we need to affect the presentation layer?

CSS is a very simple domain specific language (DSL) that functions as a series of rules that override each other in a variety of ways (the cascade). There is no mechanism to detect a specific feature or a user-agent; only media types and potentially the odd CSS hack where a user-agent has imperfectly implemented an interpreter. There are also no conditionals; you just have to use the cascade to provide alternatives based on specificity or even just source order.

With these limitations, it is impossible to implement either browser or feature sniffing in CSS. This means we need to find an alternative method to affect the cascade based on the user’s feature set.

The Modernizr method

Step in Modernizr. In the words of the documentation:

Modernizr aims to bring an end to the UA sniffing practice. Using feature detection is a much more reliable mechanic to establish what you can and cannot do in the current browser, and Modernizr makes it convenient for you in a variety of ways:

1. It tests for over 20 next-generation features, all in a matter of milliseconds.

2. It creates a JavaScript object (named Modernizr) that contains the results of these tests as boolean properties.

3. It adds classes to the html element that explain precisely what features are and are not natively supported.

Following along so far? For the most part, that all seems fairly good. What’s more, Modernizr is definitely being pushed as the solution of choice amongst the front-end community:

• Mark Pilgrim’s Dive into HTML5 “Detection” chapter
• Faruk’s “Taking Advantage of HTML5 and CSS3 with Modernizr” on A List Apart
• Web Designer Notebook: How to use Modernizr
• Image Gallery tutorial on Sitepoint

So with all that in mind, let’s go back to why I will not be recommending Modernizr as a best practice:

Sniffing CSS features with JavaScript

The real issue is that Modernizr uses JavaScript to do the feature sniffing. This method is absolutely fine if we were only looking to test for the features in JavaScript. However, Modernizr is marketed on its ability to detect CSS3 and HTML5 features so that you can write gracefully degrading CSS:

Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.

If Modernizr had sold itself as a JavaScript feature sniffing solution that also detected CSS features perhaps I could be more forgiving. In that context, it would be the developers’ responsibility to use Modernizr correctly. However, since the Modernizr site and documentation are selling it specifically as a CSS feature sniffing solution, for primary use within CSS, the error is clearly with the Modernizr team themselves.

It’s all down to the final step outlined in the documentation I quoted earlier:

It adds classes to the html element that explain precisely what features are and are not natively supported.

Modernizr uses JavaScript to add those classes to the html element; one for each of the features detected in the current browser. If we examine the generated source we see the following:

<html lang="en" dir="ltr" id="modernizr-com" class=" js flexbox canvas
canvastext webgl no-touch geolocation postmessage websqldatabase indexeddb
hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize
borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns
cssgradients cssreflections csstransforms csstransforms3d csstransitions
fontface video audio localstorage sessionstorage webworkers applicationcache
svg inlinesvg smil svgclippaths">

When I first saw that, I was horrified. Not only is it ridiculously cluttered, it also feels decidedly unsemantic and looks like a terminal case of classitis. However, let’s try to be pragmatic here; it’s a means to an end, potentially a minor side-effect to a process that will win us some power in the bigger picture. In fact, it’s one step on from Paul Irish’s proposed work around to the FOUC (flash of unstyled content) which I’ve advocated as a reasonable fallback to marking progressively enhanced objects with an “enhanced” class.

Making use of the classes

The Modernizr method allows you to assign styles based on these new classes on the document’s root element like so (example lifted from the Modernizr docs):

button.glossy {
   background: #ccc url(gloss.png) 50% 50% repeat-x;
}
.cssgradients button.glossy {
   background: #ccc -webkit-gradient(linear, left top, left bottom,
         from(rgba(255,255,255, .4)),
         color-stop(0.5, rgba(255,255,255, .7)),
         color-stop(0.5, rgba(0,0,0, .2)),
         to(rgba(0,0,0, .1)));
}
.cssgradients button.glossy:hover {
   background-color: #fff;
}

Here we can see that button.glossy is first defined with a standard png as its background. The Modernizr-added .cssgradients class is then used to increase specificity and assign a WebKit gradient instead.

What happens if we approach the problem without the .cssgradients class:

CSS allows us to define a property twice in the same rule. It also contains built-in error handling that will ignore a property it doesn’t understand; so browsers that do not understand -webkit-gradient(), for example, will simply ignore a property that uses it. This allows us to progressively enhance our CSS like so:

button.glossy {
   background: #ccc url(gloss.png) 50% 50% repeat-x;
   background: #ccc -webkit-gradient(linear, left top, left bottom,
         from(rgba(255,255,255, .4)),
         color-stop(0.5, rgba(255,255,255, .7)),
         color-stop(0.5, rgba(0,0,0, .2)),
         to(rgba(0,0,0, .1)));
}
button.glossy:hover {
   background-color: #fff;
}

However, because we can no longer target the .cssgradients class specifically, we cannot target the button:hover styles only when CSS gradients are detected. Clearly this is an issue we’ll have to find some way around and is exactly what Modernizr is attempting to solve.

This all seems as if Modernizr is giving us a great deal of power, however, it comes with a significant cost.

Dependency on JavaScript is bad

Fellow web developer and good friend Mike Davies wrote a really great article containing a good summary of obstacles potentially preventing JavaScript from executing back in October 2010. This followed a somewhat presumptuous post by Nicholas Zakas on the YDN regarding the number of users with JavaScript disabled.

In short, there are a large number of obstacles that can affect the execution—or even rewrite the source of—JavaScript included in your pages. Hence, dependancy on JavaScript is bad because it introduces many significant points of failure.

As an example of why dependency on JavaScript can be catastrophic, I recommend you read another of Mike’s posts on Gawker’s JavaScript dependent URIs and how it broke their sites quite considerably. It’s worth noting that the Gawker sites have since seen the error of their ways and are attempting to fix the damage.

Styling dependant on JavaScript

By adding styles that are specific to classes that have been inserted with JavaScript, we are making those styles dependant on JavaScript. This means those styles will fail to apply if JavaScript itself has been disabled or, more commonly, the JavaScript file applying the classes has failed to load or execute successfully due to one of the reasons above. In essence, we may just as well add those styles with JavaScript directly because we’ve already broken the web standards separation of concerns.

Do we really want to remove the majority of CSS items covered by Modernizr if the Modernizr JavaScript include fails for some reason?

It would only be the feature-sniff-dependant CSS rules that would fail, since those classes would now be missing. Potentially this only means the loss of a few nice in-browser rendering optimisations. However, it also means there is a significant loss in the overall structure of specificity within your stylesheets, which could easily cascade unintended effects through to other elements. This could easily result in some content being styled to be unreadable, or worse, incorrectly hidden. This would be very bad indeed.

Alternative solutions

Modernizr is clearly unfit for purpose. If it were simply a JavaScript feature sniffing library for use only in JavaScript, it would be a suitable solution although only really useful for JavaScript progressive enhancement.

With that in mind, what other options are available that allow us to target our CSS?

Server-side browser sniffing

We could browser sniff on the server and add a class to the html element as we generate the HTML that is delivered in the HTTP response. This could result in something like the following:

<html lang="en" dir="ltr" class="firefox">

This means we can target CSS with the .firefox class in much the same way that we used the feature classes that Modernizr provided. There is no way for us to perform feature sniffing on the server; the best we could offer is a feature lookup based on the user-agent string that we’ve used to sniff the browser, but that would ultimately still be browser sniffing.

In fact, the best browser sniffing solution would allow us a little more flexibility on browser versions:

<html lang="en" dir="ltr" class="moz ff ff3-6">

Note I’ve added several classes this time; one for the rendering engine, one for the browser, and one that contains the major and minor versions. This would allow us more specificity.

Update: Matthew Pennell has written an interesting post on server-side browser sniffing with .htaccess and environment variables. Definitely worth a read.

Cache issues

However, server-side browser sniffing means that you’ll run into issues if your pages are publicly cacheable. This server-side solution results in a different HTTP response (the HTML) for each differing browser.

If you utilise any intermediary caching (Squid, Varnish, or a custom origin CDN) for static pages, and you use server-side browser detection, you need to make sure those caches don’t inadvertently send the wrong content to the wrong browser. To do this you’ll need to Vary: User-Agent header in the HTTP response. This instructs any intermediary caches to store multiple copies of the page (one for each User-Agent string that it sees) and to inspect the incoming User-Agent string when looking for cached responses to the current request.

IE targeting with conditional comments

If we’re entirely honest with ourselves as web developers, we can probably admit that the majority of woes we experience in CSS are as a direct result of features that any given version of Internet Explorer has not implemented. In fact, I regularly interview developers who advocate maintaining a separate stylesheet for IE that is included through the use of IE’s conditional comments. Having attempted to use this method in the past, I can confidently say that it is a maintenance nightmare and quickly becomes pretty unmanageable.

A better technique would be to adopt conditional comments to add IE specific classes in much the same way we have with Modernizr or server-side browser sniffing. This method was first proposed by none other than Paul Irish back in 2008 in his article “Conditional stylesheets vs. CSS hacks? Answer: neither“. With that method, our html element would look like this:

<!--[if IE ]>
<html lang="en" dir="ltr" class="ie">
<![endif]-->
<!--[if !IE]>-->
<html lang="en" dir="ltr">
<!--<![endif]-->

This looks a bit odd, and often (for the true markup perfectionist) takes a bit of getting used to. However, it does give us what we need without requiring JavaScript or multiple cache versions.

We can even make it more specific if we so desire:

<!--[if lt IE 7 ]>
<html lang="en" dir="ltr" class="ie ie6">
<![endif]-->
<!--[if IE 7 ]>
<html lang="en" dir="ltr" class="ie ie7">
<![endif]-->
<!--[if IE 8 ]>
<html lang="en" dir="ltr" class="ie ie8">
<![endif]-->
<!--[if IE 9 ]>
<html lang="en" dir="ltr" class="ie ie9">
<![endif]-->
<!--[if gt IE 9]>
<html lang="en" dir="ltr" class="ie">
<![endif]-->
<!--[if !IE]><!-->
<html lang="en" dir="ltr">
<!--<![endif]-->

Quite clearly this gets ever uglier, but the solution is entirely encompassed in the structural layer; we will always have the correct class, even if CSS or JavaScript are unavailable for some reason. We also have the same markup regardless of user-agent string, which means caching is not a problem.

The only flaw with this solution is that we can only target versions of Internet Explorer. No other browser implements conditional comments.

Use CSS properly and make use of the cascade

As previously stated, CSS is designed to cascade. This means the built-in error handling will ignore properties the interpreter does not understand, and we can override rules based on specificity and source order. In most cases, these key features are more than adequate to develop gracefully degrading stylesheets.

Most capable front end developers are already doing this and coping just fine. Add this to the previous IE targeting approach and you’ll find that you do not need to over-engineer a solution.

In summary

So, in summary then, I absolutely cannot recommend implementing Modernizr as a best practice for front end development. It attempts to solve a problem from the wrong direction, and introduces a new potential point of failure. What’s more it breaks the fundamental ethic of web standards; the separation of concerns.

I continue to recommend well crafted, gracefully degrading CSS, backed up by conditional commented classes on the html element for targeting IE.

Modernizr may still be a worthy solution for JavaScript-only feature sniffing, if only it allowed the developer to disable the injection of classes on the html element.

Although this behaviour has been fixed in the beta of version 3, any users still browsing with version 2 or below still suffer this needless blight on web accessibility.

I’ve recently reworked the JavaScript used in Steve Marshall’s tasty channelled search solution, which requires the label to be clickable, as it hides the corresponding radio input. For this reason, I’ve written a quick bit of JavaScript to activate this behaviour.

The Requirements

As a Yahoo! developer, I’ve written this implementation using the YUI JavaScript library. There’s really no reason why you couldn’t re-jig it to work with any other JS library — including one you’ve written yourself.

The YUI objects we will require are: the YAHOO Global Object and the Event Utility. To include these files (in their minified form), insert the following lines of code in the head of your html document:

<script type="text/javascript" src="http://yui.yahooapis.com/2.3.0/build/yahoo/yahoo-min.js" ></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.3.0/build/event/event-min.js" ></script>

Alternatively, if you wish to include more of the YUI objects, you can use one of the following files:

<script type="text/javascript" src="http://yui.yahooapis.com/2.3.0/build/yahoo-dom-event/yahoo-dom-event.js"></script>

or

<script type="text/javascript" src="http://yui.yahooapis.com/2.3.0/build/utilities/utilities.js"></script>

The yahoo-dom-event.js file contains only the YAHOO Global Object, the DOM collection, and the Event Utility.

The utilities.js file includes the YAHOO Global Object, the DOM collection, the Event Utility, the Element utility, the Connection Manager, the Drag & Drog utility, and the Animation utility.

Personally, I tend to include the utilities.js file so that I have as much of the YUI functionality included as I may need. In the essence of avoiding script bloat though, I would recommend including only what you need.

The Method

We want to activate a form element when its corresponding label is clicked, so we need to bind an onclick event to any label elements within our page. To do this, we can either loop through all label elements in the DOM, and attach a separate event to each of them; or we can attach a single onclick event to the body of our page and use “event delegation” to discover our target element (the label) — a nice side effect of “event bubbling”.

If we click a label element in our page, the onclick event doesn’t occur on just that element alone; it bubbles up the DOM tree through each of the label element’s parents. This means an onclick event will fire on the form element, any container elements (div elements, for example), and finally the body element because, in effect, we’ve clicked all these elements as well.

Event delegation is the process of discovering the element at the bottom of the event bubbling tree — the “target” element. This is fairly straight forward and requires only a few lines of code, whether you’re using a JavaScript library or not.

Using event delegation will require less code, less memory, and will ultimately run much faster. This is because we do not need to discover all label elements in the page in one go. If we used the other method, our script would become slower and slower the more label elements were included in the page.

Once we have our target element, we can make sure it’s a label, obtain the form element it’s related to, and finally activate that element.

The Code

Firstly, we need to create our namespace. In this case, I’ve decided to create an extra layer entitled “browserfix” because we’re essentially fixing an oversight in the browser. Creating the extra layer means that I could possibly bind other browser fixes to the same namespace (although, if we were trying to improve IE, that namespace could get pretty big).

To create our namespace, we do the following:

NEF = window.NEF || {};
NEF.browserfix = window.NEF.browserfix || {};

This either reuses existing objects, or creates new ones using the object literal.

Next we bind a method to our browserfix object to encapsulate our code:

NEF.browserfix.Label = function() {
  …
}

The first thing our method needs to do is bind an event to the body element of our page. To do this, we use the addListener method of the YUI Event Utility:

YAHOO.util.Event.addListener(document.body, "click", function(e) {
  …
});

The addListener method expects three parameters by default; the element we wish to attach our event listener to (document.body), the event we’re listening for (“click” — we remove the “on” because only certain specific browsers require it and the addListener method will handle that for us), and the function we want to bind to that event (in this case, an anonymous — or “lambda” — function). We can also pass an arbitrary object to that function (should it require parameters), or scope the execution of our listener to a specific object. In this case, we’re not doing either of those.

Now we’ve bound a function to the event we need to populate it with some functionality. Incidentally, the e parameter that is passed to our function is an identifier of type “Event”. This is a special object that contains contextual information about the event. You can find out more about this in the W3C docs for the EventListener interface.

The first thing we need to do is work out which element we originally clicked; which is surprisingly straightforward. Using the getTarget method of the YUI Event Utility, we can get that element in a single line — in fact, without the YUI, this code is still surprisingly simple; the YUI just sorts out all those nasty cross-browser differences for us:

YAHOO.util.Event.addListener(document.body, "click", function(e) {
  var target = YAHOO.util.Event.getTarget(e);
  …
});

The getTarget method returns the element at the bottom of our event bubbling tree and requires only a single parameter; that special “Event” object I was talking about earlier. It needs this to identify which event we’re tracking. In effect, we’re passing the event from function to function.

If you’re interested in the code behind getTarget, I’d recommend delving into the YUI Event Utility code in the API documentation.

Now that we’ve obtained our clicked element, we need to check to see whether it’s a label; and if it isn’t, we return harmlessly — allowing default behaviour and other events to continue regardless. To do this, we’ll do a comparison on the tagName property of the element, which we’ll convert to uppercase to combat case sensitivity:

if (target.tagName && target.tagName.toUpperCase() !== "LABEL") {
  return;
}

To force a best practice of using explicitly defined label elements, we make the assumption that the htmlFor property will exist. If it doesn’t, the JavaScript will throw an error — which is a good thing. Obviously, we could check for the existence of the htmlFor property, or even write a DOM walking loop to handle implicitly defined label elements; but, to be honest, that would be slow and cumbersome, and would allow for a situation we don’t really want. This assumption allows us to return a new target element; that which is referred to in the for attribute of the opening label tag in our HTML:

target = document.getElementById(target.htmlFor);

Finally, we need to activate our new target element. For most elements, this will involve simply firing the focus method, but if our element is an input of type “radio” or “checkbox”, we’ll need to fire the click method:

if (target) {
  if (target.type) {
    switch (target.type) {
      case "radio":
      case "checkbox":
        target.click();
        break;
      default:
        target.focus();
        break;
    }
  } else {
    target.focus();
  }
}

First we check for the existence of the target element — if it doesn’t exist, we don’t want to attempt doing anything. Next we check for the existence of a type property — this will tell us whether we’re dealing with an input element or not. If we are dealing with an input element, we perform a switch statement on the type property to ascertain what sort of input we’re dealing with. If we’re dealing with a “radio” or a “checkbox”, we utilise the fall-through behaviour of the switch statement to fire the click method. Also, because we’re using fall-through, we make sure we supply the switch statement with a default clause that fires the focus method. Finally, if our target doesn’t have the type property, we also fire the focus method.

Lastly, we run our function when the DOM is in a usable state, using the YUI onDOMReady method:

YAHOO.util.Event.onDOMReady(NEF.browserfix.Label);

Rather than waiting for a window.onload event (which will have to wait for images to load etc.), this will trigger our function as soon as the DOM is loaded thus making sure the behaviour is available as soon as possible.

So here’s all that code in full:

NEF = window.NEF || {};
NEF.browserfix = window.NEF.browserfix || {};
NEF.browserfix.Label = function() {
  YAHOO.util.Event.addListener(document.body, "click", function(e) {
    var target = YAHOO.util.Event.getTarget(e);
    if (target.tagName && target.tagName.toUpperCase() !== "LABEL") {
      return;
    }
    target = document.getElementById(target.htmlFor);
    if (target) {
      if (target.type) {
        switch (target.type) {
          case "radio":
          case "checkbox":
            target.click();
            break;
          default:
            target.focus();
            break;
        }
      } else {
        target.focus();
      }
    }
  });
};

YAHOO.util.Event.onDOMReady(NEF.browserfix.Label);

And for anyone browsing with Safari, here’s a handy demo of NEF.browserfix.Label in action…

My first port of call is the underlying structure of my HTML – it’s ok, but it could definitely be improved.

I recently had a fantastic conversation with Mike Pearce – an old colleague (who’s now a good friend) – regarding document structure in HTML. Whilst peer-reviewing some of his code, I noticed some not-uncommon structural characteristics that, although not wrong, definitely didn’t convey the best semantics within the document. For this reason I thought I’d document some of the stuff I’ve learned about structured HTML and open it up for comment.

The Point

So what do we gain from enforcing good structure in our HTML documents? Well, to begin with, it aids accessibility by describing and organising our content. This means that screen readers, normal browsers, and even search engines are able to understand our content and can navigate and classify it better.

Good structure is often overlooked as being important because we can easily emulate it visually with styling – in fact it’s often the case that a badly structured HTML document is, in fact, inferring structure using paragraphs or table cells styled as headings. This is simply down to developers not understanding the importance of structure within HTML. A well structure HTML document is the base for good web standards, as it allows us to set out an organised template for more semantic content. In fact, it’s the very beginning of semantics.

Semantics

Semantic is one of those words you’ll hear a lot from web standards developers and standardistas; it defines our existence and, without it, we’d all suffer an existential crisis and degrade into a depressed rabble of alcoholics… oh wait…

In all seriousness, it’s a word I’ve heard people use without truly understanding the meaning. So let’s take a look at a dictionary definition:

se·man·tic
adj.

1. Of or relating to meaning, especially meaning in language.
2. Of, relating to, or according to the science of semantics.

Great – but what does it mean in regard to HTML? Well basically, it means using HTML properly – to describe our content with the elements supplied in our HTML DocType; rather than describing presentation. Good HTML should be as semantically correct as possible, which means using elements that describe headings, lists, content inflection, and organisation, instead of using elements to arrange content visually. A good example of this would be table-based design. Once our content is described properly using semantic HTML, we can improve presentation using external stylesheets.

Perception

To really understand the importance of structure in our HTML documents, you need to alter your perception. I’m not talking about taking excessive amounts of mind-altering drugs (unless that kind of thing floats your boat – I’ve met a few space-cadet web developers in my time), but simply changing your point of view in regard to your vision of the internet.

As humans, we’ve begun to perceive the internet as a series of sites, when in fact it is nothing more than a complex network of single pages; totally oblivious to the domain and file structures we use to organise them. Each page is mutually exclusive; it exists as a single entity and links to many similar entities. As humans, we perceive sites because they imply organisation; browsers and search engines only see pages and are generally unconcerned with site structure. This means that each page is a unique document and, as such, may require structure to make sense within context.

This is also the case for anyone landing on our sites from search engines – the site structure is not instantly conveyed, yet the structure of the single page is. If we want people to understand the page they are looking at, we need to organise it accordingly.

Headings

Heading elements are our key method of outlining structure. Much like any other type of document we may be writing, headings allow us to develop a document map – a set of titles for key points or content groupings. This map of our document could be compared to the “contents” section of a text book, since it outlines the hierarchy of our content – and in some cases, could even be used for navigation purposes.

A handy tool I’ve discovered for viewing the structure of a page is the Document Map Extension for Firefox. If you’re using Firefox, I recommend you install it and have a bit of a play – it will help you to visualise what I’m talking about!

The Heading Elements

HTML provides us with six heading elements; <h1> through to <h6>. It’s invalid to start with anything but an <h1> since our heading tags are required in order by the DocType. A basic structure might only need <h1> elements. Here’s an example:

<h1>Introduction</h1>

<p>This is the beginning of our document. This could be
any kind of content you so desired - but it would all
fall under the heading "Introduction".</p>

<h1>Summmary</h1>

<p>This is another section. Note that, in this example,
both "Summary" and "Introduction" exists at the same
level in the hierarchy</p>

Should we need to, we can add further layers to our hierarchy using the extra heading elements like so:

<h1>The Ten Word Review</h1>

<h2>What is it?</h2>

<p>It's an excellent site where users review various
things in 10 words. No more, no less.</p>

<h2>What's the point?</h2>

<h3>Information Resource</h3>

<p>Find out what other people think about something.</p>

<h3>Voice Your Opinion</h3>

<p>Speak your mind as succinctly as possible.
Voice your opinion without all that needless waffle.</p>

<h2>Where can I find it?</h2>

<p>That's easy - you can find it here:</p>

<p><a href="http://thetenwordreview.com">
  The Ten Word Review
</a></p>

Here you can see that a good peppering of heading elements allows us to structure our document meaningfully. Obviously it’s of more use when there’s a lot more content, but I hope you get the idea.

Notice that the numbers in the heading elements correspond to the level of the heading within the page – not their order of importance as content. This is a common mistake that I’ve seen made in the past and it’s a fundamental misunderstanding of the elements themselves. It’s also worth pointing out that, even though a site-wide heading (like “Bedtime Reading” on this site) may be an <h2> on one page, there’s no reason it shouldn’t be a different level on different page. For this reason, it’s worthwhile thinking about content structure well before you start styling things up with CSS. I’ve always been a proponent of markup before styling and this is a good example of where this method is particularly valid.

Understanding the heading elements is the key to applying structure. The real problems arise when we try to decide where to place those elements. This is the most common stumbling block for web developers.

Rules of Engagement

When trawling through the burgeoning number of standards-based sites on the internet, I’ve noticed that most developers place the title of the site within an <h1> element. For home pages, this is certainly the correct thing to do; but on other pages in the site, it really isn’t.

Unfortunately, this phenomenon is a side-effect of visualising site structure instead of page structure – as developers we’re always aware that the page we’re developing is situated within our site, therefore we surmise that the site name is always our top-level heading. This is definitely something I’m personally guilty of in my current structure and is one of the first things I’m going to address with my redesign/realign.

If we alter our perception and view our site as a number of unique (yet still related) pages, we begin to understand that the title of the page itself should be our top-level heading (the <h1> element). In fact, as a side-note, if you make sure the title element and your first <h1> element match, you’re instantly boosting your SEO. This is because, as I pointed out earlier, search engines have less concept of your site structure than they do of your page structure.

Case Study

With all this in mind, let’s take a look at the home page of this site:

So what do I use as the top-level heading on this page? Obviously I don’t have the words “home page” anywhere in the content – and why should I? It’d be pretty meaningless in terms of context; the best heading to use here is the title of the site, since the home page is an overview of that. In this particular instance I’d like to use a logo graphic as the heading, rather than just plain text, so I am presented with a number of options. For instance, I could wrap the text “Nefarious Designs” in the <h1> element and then use image replacement in CSS to introduce the logo; or (the option I chose) I can wrap the logo image in the <h1> element – this is still perfectly valid HTML. I chose this option because the graphic has importance as my logo – if it were simply a graphical representation of heading text, I’d probably have used image replacement.

Now that I have defined my top-level heading, I usually do a quick scan of the content to make sure there are no more headings that I wish to exist at the same level. This does not occur often but it’s always worth checking. In the case of my home page (and for most other home pages), I want the title of the entire site to exist at that level, as discussed before. The next step is to look at the next level of headings.

The next level of headings are associated with my content modules – these are defined chunks of related information that I organised together when defining my information architecture. These include the latest three posts, my portfolio, my del.icio.us feed, my flickr feed and my bedtime reading – these are all completely different groups of content and, as such, deserve to be categorised beneath different headings. This method continues within my content – needless to say I probably don’t need to go any further for you to understand my methodology; in fact, if you’re interested in seeing further levels of heading, you’re probably best off looking at the source behind one of my posts.

Within the text of my posts, the actual post title is the most important element and is marked up as such. In this particular type of page I no longer require the importance I bestowed upon the site title on the home page, since it is not really as relevant here. In fact, I’m more likely to place the title of the post in the title element, therefore I should think about doing the same in my <h1> element. Further headings beneath this will reflect this change in structure – this does, however, mean that we can’t use any headings before our <h1>; but if you think about it, this makes perfect sense since the title of the page should always be the first heading.

Finally our content modules, which are repeated from the homepage, have the choice of being marked up at the same level as my post title; or I could mark them up as a level below since they are content items within a page with that title. In fact, it’s probably preferable to use this method as the content is repeated throughout the site and should probably maintain a constant structure.

Summary

Currently the document map of each page of my site is structured more towards the site than the page itself. This ultimately means that my document structure is inefficient and confusing. By correcting this I will improve both the accessibility of my pages and their search engine optimisation. Both of these goals are key when redesigning my site.

Hopefully, using my own site as an example, I’ve laid out the fundamentals of document structure; and equally how important it is to good web standards development. By improving our understanding of document maps we can improve our pages for navigation by all our users and their respective internet browsing clients; be they standard browsers, screen-readers, or even search engine robots. You can also see how easy it is to improve your structure by taking these things into account – and also how easy it is to get it wrong without realising.

Internet Explorer 7 has been on full release for about a week now and Mozilla have managed to jump on the proverbial bandwagon and release Firefox 2.0. If you haven’t already downloaded it, you can find it here:

http://getfirefox.com

I was originally writing a blog post on getting FF2 to run simultaneously with FF1.5 (for testing purposes), but Stupot beat me to it. So instead, I’m collating a short list of resources to help you get the most out of Firefox 2.0.

Resources

• Run Firefox 2.0 and 1.5 Side-By-Side – Handy for all that browser compatibility testing.
• Top Firefox 2.0 Config Tweaks – Learn how to force FF to restore your tab session even without a crash.
• Web Developer Toolbar Extension – Invaluable for web developers. If you haven’t already got this, you need it.
• IE Tab Extension – Run IE in a Firefox tab. Brilliant. Saves on all those superfluous browser windows.
• Fangs Screen Reader Emulator Extension – Handy for accessibility testing but not replacement for the real thing.
• Firebug Error Console/Debugger Extension – Forget about Console², this is the console of choice.
• HTML Validator Extension – Validates your (X)HTML whilst you work. A wonderful time saver.
• Tails Microformats Extension – Microformats are the next big thing. Tails will let you know when there are Microformats present.Update: It would appear that Tails hasn’t been properly ported to FF2.0 as yet, and, as a result, suffers some rather strange behaviour.

Firstly, I’d like to say a great big nefarious hello to all the developers and designers I met on the day, and a special hello and thanks to Graham Bancroft, Ben Ward, Steve Marshall and Fatty – it’s nice to put faces to the names at last guys!

I enjoyed most of the presentations although some more than others. I’m not going to review them in depth here – I’ll just outline my thoughts instead. You should definitely listen to the d.Construct 2006 podcasts (although the presentations themselves don’t appear to be live yet) and formulate your own opinions.

The most pleasant surprise, for me, was Jeff Barr‘s talk about Amazon’s APIs – I went in expecting nothing but an hour long advert and, although the theme was entirely Amazon based, the content of the talk was pretty educational.

Derek Featherstone‘s talk on accessibility was probably of most use since my boss (who also attended) picked up on the potential accessibility nightmares that are JavaScript enhanced interfaces. Nice one Derek; you managed to communicate successfully in one hour what I’ve been failing to outline to him for years! I shall be taking notes on your technique.

Jeremy Keith managed to fire up my desire to muck about with API’s and Microformats over the course of both his talk and the Microformats picnic he hosted in the Brighton Pavilion gardens. Expect to see all kinds of madness incorporated into this site over the coming months (whenever I have time to play). I’m really looking forward to the Microformats themed WSG meetup that Stuart‘s planning in the next month or so.

Finally, as expected, Jeff Veen‘s talk on designing the complete user experience was, undoubtedly, the best of the presentations on the day. This probably isn’t much of a surprise though, as it’s well known in the industry that Jeff could sell Microsoft products to Mac users (ok, that might be a slight exaggeration but still…).

Once the event had finished we all wandered down to the seafront to attend the excellent after-party at The Terraces on Madeira Drive. It was here that I met up with Graham and gradually got incredibly drunk; which I hadn’t really noticed until buying the train ticket home became a monumental task of applied concentration. Thanks for that Graham – it was a top evening!

So, in summary, the event was excellent; the company outstanding; the knowledge obtained exemplary; the after-party awesome; and the hangover unpleasant. Looking forward to next year!

Swift is the first WebKit based browser for Windows – WebKit is the rendering engine behind the popular Mac browsers Safari and Shiira.

As any Windows web developer knows, cross-browser compatibility can be a real nightmare to test without a Mac handy. Hopefully the release of Swift will make things a little easier.

You can download the current alpha release from the website; although the last time I checked, the download seemed to be unavailable. This is probably due to bandwidth limits being exceeded – I notice Ann van Kesteren has just linked to the site and Vitamin linked there earlier (which is how I discovered it myself).

Here’s a nice screeny of it running on my Windows 2000 Pro machine at work:

Oh what a shock I got!

The Fonts CSS file is billed as offering cross-browser typographical normalization and control. A nice ideal but I’m not sure I agree with the method adopted.

You see, the first rule in the Fonts CSS file is as follows (I’ve added some carriage returns and indented to make it a little easier to read):

body
{
  font:13px arial,helvetica,clean,sans-serif;
  *font-size:small;
  *font:x-small;
}

This is nasty, in my opinion, for one major reason; it’s using hacks to get around IE’s problem with resizing fonts declared using pixels.

I’m not going to get up on my soap box about this (neither do I wish to pontificate – you never know when you might be wrong), but I’m pretty certain most of us are aware that hacks are a bad method to adopt when trying to solve cross-browser issues. If you’re interested in reading a little more, there’s some informative posts at Vitamin, Digital Web and Muffin Research.

It’s a real shame, in this particular instance, because the Yahoo UI is so good for so many other things.

Another Method

Unfortunately, I’m not sure there is one perfect method for solving this particular problem. In most cases, I personally make a major assumption to solve the issue – that the user has never changed the size of the default fonts in their browser. This is not a great solution but I certainly think it’s better than using hacks.

If this is the case, most browser defaults (at least that I’m aware of) are 16px, which means the following rule sets all font sizes to 10px:

body
{
  font: 62.5%/1.0 "Trebuchet MS", tahoma, verdana, sans-serif;
}

This then means that you can size everything else using percentages and still easily understand what their pixel equivalents would be:

100% = 10px
140% = 14px
160% = 16px
200% = 20px

This allows you to improve your typography easily – a good example would be Mark Boulton’s excellent tutorial on weight and size.

It’s also worth resizing fonts for form elements. This is something the Yahoo Fonts CSS does too. To acheive this, you should use something like this:

select,
input,
textarea
{
  font-size: 99%;
}

I’m using 99% in that rule simply because Safari doesn’t seem to like 100% for some reason.

So using Yahoo’s Fonts CSS is bad?

Not really, it’s just that I prefer the above method. You should definately make up your own mind about it.

In summary, it’s just the Fonts CSS part of the Yahoo UI that I disagree with – the rest of the interface is awesome and I’m a particular fan of their javascript event handling functions. They’ve brought all kinds of new features to the table with the newest release and, if you’re a web developer, you should definately download it and take a look.

However, when it comes to font-size normalisation (English spelling please), don’t just trust their method because it’s not perfect.

But then, neither is mine…

I can’t heartily recommend them if, like me, you couldn’t get to the web development conference “Web Essentials 2005” in Sydney.

Unfortunately, although it has some nice features (like the Ruler – love it), it still isn’t as comprehensive as Web Developer for Firefox.

Ah well.

Nice start though Microsoft – I’m afraid there’s quite a lot more for you to do to get us developers back into using your browsers though.

However, as of today, that has changed. In a move that will instigate a little competition for the many other free browsers out there (such as Firefox, Safari, Internet Explorer, Netscape etc) Opera has dropped the advert and the download fee.

Get your free Opera here…