Web standards in a commercial environment

Posted 23 April 2009 by Russ in CSS, Other stuff, XHTML.

In all I do I have web standards in mind, from developing semantic valid strict or transitional XHTML, to developing JavaScript that degrades gracefully. When I’m developing the presentation layer for a site that uses a CMS of any kind, I hate it when I have to work invalid or badly written code and often end up rewriting it myself to improve it.

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.