At the time of writing my current project is the new ecommerce store for Lockonego, which is based on Pinnacle Cart. Work began by creating a new skin based on the ‘out of the box’ skin but there’s so much in there that’s inefficient or just plain wrong, the new skin for Lockonego bears no resemblance to its origins. So it’s fair to say I’m a standards junky.

But there are times when you do need to bend the rules slightly and this is the the case at Arcadia, a £150 million online business with in excess of 5 million page views every day. There are two areas where we’ve had to compromise and the reasons for each are different:

Separation of style from content

One of the founding principles of good development is separating the markup, style and behaviour out into distinct layers and the main benefit of this is that you can easily update any of the layers without having to update the others. Having an H1 element with style embedded into the markup for example isn’t best practice. Say you had 50 pages that had an H1 styled in a certain way, you’d need to add that style to all 50 of those pages and if you changed it, you’d need to change it in all 50 places. Separating style away to an external CSS file enables us to define the style in one place, making updates easy.

Even with the use of a CMS template system, you still want to avoid the use of inline styles because if you want to change the layout of a template, you still need to get in there and fiddle with the markup, which should only be used for semantic structure, not styling.

However at Arcadia, we’ve had to bend this rule slightly. The custom CMS we’ve built in Adobe Flex enables our business users to upload images into templates that are built in XHTML and Apache Velocity. This is fine for inline images where we can simply render the image path into an image element in the markup, but not so hot for background images.

At the time of writing each page published from the CMS uses template markup file and one or more template CSS files. However it’s only the markup file that has data injected into using Velocity. So for a user to insert an image as a background image, we can’t inject the image information into the external CSS file.

So we bend the rules by externalising every possible style definition to the CSS files and then add the image path (and possibly the dimensions for some template designs) into the markup as an inline style.

So instead of this kind of markup and CSS:

<!-- markup in the template file -->

<h1>My Headline</h1>

/* styling in the CSS file */

h1 {
 background: url(my-headline.gif) left top no-repeat;
 height: 50px;
 width: 300px;
 text-indent: -9000px;
 }

We have to do something like this:

<!-- markup in the template file -->

<h1 style="background-image: url(my-headline.gif);">My Headline</h1>

/* styling in the CSS file */

h1 {
 background-position: left top;
 background-repeat: no-repeat;
 height: 50px;
 width: 300px;
 text-indent: -9000px;
 }

Pesonally I hate it as the rendered markup looks cluttered and unprofessional. But the benefit we gain in being able to offer our business users this kind of flexibility outweigh the concerns of my professional conscience.

I take solace in the fact that the markup is still valid agains the XHTML Transitional doctype, and that if need to update the layout of a set of pages that use a template, I can just edit the template markup file to update each of the pages that use it.

We could do it another way by putting the image inline in place of the live text, but for that’s a step too far. The only inline images I use are those that make sense when the CSS is disabled. A product photograph for instancem, isn’t style; it’s content and therefore lives in the markup. A headline that’s styled in a fancy font however, is design, not content and therefore belongs in the style layer.

Of course, we could (and need) to develop a way to render our external CSS files based on user input, but for now, this a web standards rule we have to live with.

Location of JavaScript calls

The second web standards convention we’re considering going against is this: that all calls to external JavaScript files should be contained in the head element of the document.

The W3C specify that script elements can be placed anywhere in the head or body, but industry best practice dicates that all of our script should live in the head of the document.

However there is a performance issue to consider, as Yahoo’s Exceptional Peformance Team point out, scripts block asynchronous HTTP downloads. What this means is that when your browser downloads a page, it attempts to download elements in parallel: one thread might be downloading your CSS file while another is downloading your logo. However when the browser encounters a call to a script file, it blocks all other downloads until it completes as it needs to establish whether the script file is going to need the browser to write content to the view in the form of document.write commands.

The pause may be negligible but in order to optimise the performace of a site, the suggestion from Yahoo is that the scripts of your page should appear at the bottom of the body element so that everything else can download safely.

This is only going to be a viable option if you don’t use document.write (and let’s be honest, we should all be using DOM manipulation instead), but one thing we need to investigate further is the impact this has on initiating the scripts themselves.

jQuery and all of the other popular JavaScript libraries provide a way of working with the DOM before the document’s images downloads, which is great as the behaviour layer can be applied almost instantaneously. But if the browser has already started downloading the imagery for the document, by moving the scripts to the bottom of the body element, have we missed out on that speed of execution? Possibly not, but it needs some further testing so we haven’t yet moved away from the conventional head location.

Windows Update isn’t as pervasive as Mozilla’s method though. I’ve seen regular users of the web completely ignore the Windows Update icon in their system tray so the IE8 message isn’t going to be on their radar. Then there’s the huge number of corporates out there that have Windows Update turned off or who have not yet rolled out IE7 onto their standard build, let alone IE8.

Finally, there’s the lowest common denominator: the computers whose specifications are so low that IE8 simply aint gonna be an option. It’s all too easy to think that those on these kind of computers aren’t going to be the type of visitors you’re seeking – perhaps they’re not your typical online gamer or don’t buy all of their luxury items online – but they’ll also include public environments such as libraries and community centres that don’t have the budget to upgrade their kit.

I expect to see IE8 gain a fairly rapid hold on the IE market but I’m still expecting to have to continue coding around the inadequacies of IE6 for some time. As much as the prospect of CSS3 and HTML5 amongst other things is exciting, from a commercial point of view, in the world of ecommerce I can’t afford to ignore a part of my user base that spend money with us using IE6. But there is a tipping point.

A fair amount of time and effort (and therefore money) goes into ensuring sites offer the best user experience in both modern and legacy browsers; how much will depend on the site and its business. While that cost is outweighed by the income derived from IE6 visitors, it’s fair to say that we should still look to support IE6. The point at which each business decides it’s no longer commercially worthwhile is going to differ on a case-by-case basis, but some have already made the leap.

37signals have given up the ghost. That’s not to say that their site is no longer usable in IE6, but it’s not got the same level of polish, as indicated by the difference in design caused by IE6’s lack of support for PNG transparency.

37signals.com in Firefox 3

37signals.com in IE6

There are others (like Yahoo’s Christian Heilman and the popular web design magazine .Net), are keen to see IE die, and there’s even talk of a return to scripts that will detect IE6 and alert the user that they should upgrade. For me this is a step too far back to old days when sites had to have a particular browser. Ironically enough it was typically Firefox and Safari users who were blocked from accessing sites because they weren’t using… IE6!

And then there are those that think IE6 should be saved. OK, so maybe this one’s toung-in-cheek, but I think we’ll be stuck with IE6 for a little while longer yet.

These days we’re much more aware of the semantics of our pages and should ensure we choose our hand-coded markup carefully before we even look at the CSS. But sometimes the semantic structure of a fantastically-designed web site is not always clear to the designer and/or developer. The designer might design a masthead that is visually the key element on a page or set of pages, but that doesn’t mean it should necessarily be the H1 in your page.

As lead developer at the Arcadia Group, I’ve been involved in a number of commercial site audits for natural search optimisation and accessibility. Each of these audits has made the same recommendation: markup of your page affects how your page is interpreted by all user agents and should be written to ensure that these agents can interpet your page content. These agents include search spiders and screen readers, and it’s these that are easily overlooked if we take a graphical design too literally.

Working semantically

The easiest way I’ve found to develop in a purely semantic way that balances the needs of design, SEO and accessibility is pretty straightforward: I work from the bottom up. By that I mean that I work through each "layer" of the site interface in turn, starting with the markup that defines the structure of every page. I’m primarily a front end developer so although I do plenty of work with PHP and work closely with Java developers, the layers I’m focussing on here are purely presentational.

Breaking up the presentation layer

Markup

The markup is the one required layer that all pages need as it’s this that the user agent interpets. A browser’s interpetation of this is a rendered page like the one you’re looking at now; a screen reader ‘reads’ aloud the content in the markup; and a search engine applies its search algorithm to the markup to produce a search ranking.

Style

If we’re good little developers and obey the rules of progressive enhancement there should be no styling in our markup layer. This should all be separated out to an external CSS file, or files. This set of files and any associated images form our style layer. This is largely ignored by search spiders* and by screen readers but is what enables us to achieve our desired page design.

* Google checks for any ‘black hat’ CSS techniques that are used to gain ground in search rankings, such as making keywords invisible from view by styling them in same colour as the background they sit on.

Behaviour

Behaviour is the final layer and enhances our pages further by adding the behavioural gloss. This commonly includes JavaScript behaviour such as Ajax, animation, form validation and the like, but also includes any Flash content and even RIA content produced using tools such as Adobe Flex and Microsoft Silverlight.

From both the point of view of progressive enhancement and accessibility, we should ensure our pages are usable for any person (or user agent) that doesn’t have the ability to render this behaviour layer. This means that the markup and style layers should include the content that allows everybody to use the page. The behaviour layer then overrides this by presenting the JavaScript, Flash or other plugin content to enhance the user experience.

There is a (valid?) argument that there are Flash and RIA interfaces that deliver an experience that’s not possible to produce in any other form with current browser technology, and that it’s therefore the only realistic option is to present the user with a "You need to enable JavaScript" or "Download Flash Player 10" message and insist they install what your content requires if they want to use your page.

Working with the markup layer

So working from the bottom up, I find the easiest way to work is to write the structure of the page first. For this example I’ll use the page you’re reading as an example:

From a design perspective the logo is large and takes up a lot of screen real estate and on some sites you find that the site logo is marked up as an H1 element of the page. However the page you’re reading now is specifically about site logos and the H1 tag, so from a semantic point of view, that should be the H1 element rather than the russback.com logo.

It’s tempting to think that we could have both the site logo and the page heading as H1 elements but from an SEO perspective, this isn’t a good thing. Google and other search engines read the content of the page but they also parse the markup in order to assess the imporance of each content block. So keywords and phrases found in paragraphs at the bottom of the page will be given less ‘weight’ or importance than those found in a heading tag towards the top of the page. Therefore the H1 tag is the description of this page and there should only be one if you want to optmise your site for search as far as possible.

This really shouldn’t be a problem for us as developers because CSS gives us the ability to style markup elements in pretty much any way we choose; there is nothing to say that an H2 element must look visually different to an H3 for example. So if we concentrate on the structural markup of the page before we even look at writing any CSS, we should find we get our semantics right from the word go, with SEO to boot.

So where does that leave the site logo?

In markup terms, a logo is either going to be an inline image, or text that is replaced with a background image using CSS. My view is that as an identity, it deserves to be an inline image so that if the site’s CSS is disabled, the branding of the site remains in place.

However if you’re dead set on using image replacement, the logo clearly can’t be used to replace an H1 text element, and as the heading structure of a document should flow from top down – ie H1 first, H2 second, and so on – if we’re to be using an H1 tag below the logo, we can’t use a heading tag of any sort for the logo.

So what else do we have in our semantic toolkit to mark up this element? Not a lot really: just a link or at most, a link within a div if we really need it.

But what about the home page? My logo is the title of my page here!

This is a fair point. When a visitor arrives at your front door, your logo is arguably your page’s title. You can still achieve this by adding some conditional code using PHP, JSP or whatever language your site’s application layer is built in, and then use CSS to ensure the design remains consistent throughout the site. A PHP example for Wordpress would look something like this:

<?php
  if (is_home()) {
    $logotag = "h1";
    }  else {
    $logotag = "div";
    }
  echo ("<" . $logotag . "><a href="/" title="Back to the home page"><img src="/wp-content/uploads/logo.gif" alt="Russ Back, professional web development" /></a></" . $logotag . ">");
?>

Some example sites

This isn’t a view that’s shared by everybody, and here are some high examples of different approaches taken from a variety of sites. As with many areas of web development, there’s many different ways to build a site and the decisions we make during the development process should always be driven by the business needs and the stakeholders’ requirements. However I hope the simple approach outlined here will serve you well in the majority of projects.

The BBC site uses an H1 element for its News logo on the News home page. When you drill down to a story page, the logo is a link with image replacement and the H1 is the headline of the story.

The Google site uses an H1 element for its logo on the home page and search results page. When you drill down to a content page, the logo is an inline image and the H1 is the headline of the page.

The Accessify site uses an inline image for its logo and the H1 is the headline of the page.

The A List Apart site uses more than one H1 element on each page: one for the logo and the other for the headline of the page.

The Big Mouth Media site uses an inline image for its logo and the H1 is the headline of the page.

The Apple site typically uses image replacement on a link for its logo and the H1 is the headline of the page.