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.

Each of these examples uses the image below, which is shown here as a refererence:

Transparent background and content

All modern browsers recognise the opacity filter so this is our starting point. IE uses a different style declaration to the rest of our target browsers so our basic CSS class for a transparent element looks like this:

.transparent {
	background: #FFF;
	opacity: .50;
	filter: alpha(opacity=50);
	width: 100% !important;
	}

The background and opacity values could be anything you need but I’m setting these to white and 50% by default as this give us an effect that works well in may situations. The two opacity declarations are for different browsers: filter for IE, opacity for everybody else. The need for a width declaration is an odd one; without it, IE6 doesn’t invoke the filter so make sure you have a width set.

Here’s an example showing the background image and a paragraph of text overlaying it with the default 50% tranparency:

<p class="transparent">This text is inside a paragraph element with the classname .transparent and should have a transparency value of 50%. The opacity should change when you roll over it.</p>

You could say that there’s an issue with this though in that although we’ve achieved a transparent background, we’ve also made the text inside the block transparent too. You could equally say this is exactly what you want; for example you might want the transparency to change on rollover, which could simply be achieved by adding the the following psuedo class that adjusts the opacity on rollover (I’ve added a cursor for good measure):

.transparent:hover {
	opacity: .80;
	filter: alpha(opacity=80);
	cursor: pointer;
	}

(If you’re looking to do this for IE6 you’ll need to make sure the :hover pseudo class is on a link element rather than a paragraph or any other element.)

Setting the opacity of the element makes the whole element – background and content – transparent, so we need another solution if we want a transparent background and opaque text.

Transparent background, opaque content

As shown above, setting the opacity of the element makes the whole element transparent so any child elements will be transparent too. So if we want opaque elements showing on top of transparent elements, we need to keep the two elements in their own node in the DOM.

In the example above, we had a single transparent paragraph element with text. As the text is a node of the paragraph, the transparency is inherited but the same would apply to any nodes in more complex markup. Take a look at the wireframe here:

The content element is a child of the transparent element and is therefore itself transparent. What we need is something like this:

As the content element is not a child of the transparent element, it will be fully opaque. All that’s left to do is style this so that the content sits on top of the background element, which we can achieve reliably by adding a wrapper around both elements as follows:

The semantic XHTML for this should be something like this:

<div class="transparent_wrapper">
<div class="transparent transparent_bgrd"></div>
<p class="opaque_content">The text is inside a paragraph with the classname .opaque_content and should be opaque on top of the transparent background elemnent.</p>
</div>

The empty div inside the wrapper will contain the transparent background and the content element (in this case a paragraph but this could be any element) needs to be positioned on top of the background, which we can achieve with CSS as follows, which I’ll go through step by step…

The transparent background element

The background (colour or image, depending on your needs) needs to sit under the content so we start off by setting its position absolutely. By default browsers assume an absolute element should sit 0 from the top and left so we don’t need to declare these properties, however we do need to ensure that the background appears underneath the content, so we set the z-index to be 1.

Assuming we want to reuse this technique for a multitude of designs and layouts, we need to make sure the background scales as the content size increases. To do this we set a 100% height for modern browsers, and a pixel value for IE6, which struggles with the 100% declaration (I’ve used 9000px here which will more than comfortably cover anything I need). We can do this in one selector by declaring 100% as the height first with the !important declaration. After this we add the pixel value for IE6. Modern browsers will obey the !important declaration but IE6 incorrectly ignores it, so we’ve achieved everything we need without any complicated hacks.

.transparent_bgrd {
	position: absolute;
	z-index: 1;
	width: 100%;
	height: 100% !important;
	height: 9000px;
	}

The opaque content element

The content element is simple. It simply needs to overlay the background element within the wrapper, which we can achieve simply by setting a higher z-index value and a relative top position of 0px. We could use absolute positioning but the benefit of using relative positioning is that the wrapper (and therefore the 100% height transparent background element) will scale according to the height of the content.

.opaque_content {
	position: relative;
	top: 0;
	z-index: 2;
	}

Wrapping it all up

The wrapper acts as a bounding box for the two child elements. The first thing to do with the wrapper is to set it to position:relative to ensure that the child elements will take coordinates according to this wrapper element. For IE6 to render the background reliably when the content scales, we also set the height of the wrapper to 100% and set the overflow value to hidden to ensure whatever remains of the 9000px setting declared in the background element is hidden from view.

We also want to ensure that the wrapper can be used for any content

.opaque_content {
	position: relative;
	top: 0;
	z-index: 2;
	}

Here’s the updated example using this approach:

Download and customise the source code

The background image used in the examples above is only 125px high, so obviously it’s not good enough to use as a background image on large elements; it’s simply used here as an example. You could just as easily use a background colour instead of an image. I find the best approach is to keep the core styles in my master stylesheet and then add specific styling to each element that uses it. You can grab the complete set of examples and core code in the source code for this example.

Browser compatibility