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.

Installation is pretty straight-forward and not much different to any other typical LAMP application, but I found that my out-of-the box LAMP setup on OS X Leopard 10.5.6 was missing a few of the PHP modules required to install the app. For example I had the most recent version of the GD image library installed but the Magento installer insisted I needed something more.

I’m not a Linux guy and poking around under the hood of my OS isn’t something I’m busting to do but I had a crack at installing the missing modules using Fink. This seemed more straight-forward than installing packages via the command line, but I still didn’t like it, so I turned to MAMP.

MAMP I discovered, is great if you’re looking for a friendly interface to your Apache, PHP and MySql setup. I downloaded and installed MAMP Pro as it allows me to run multiples sites locally on my Mac and once it had installed, I only had a couple of bits to change.

Installing MAMP Pro

As I had already configured LAMP on my Mac, MAMP was set to use the ports 8888 and 8889 for Apache and MySql respectively, instead of the default ports 80 and 3306. Not a major issue but I’d rather just slap local.mysite.com into my browser than worry about local.mysite.com:8888. Perhaps I’m just lazy.

Error with the MySql –skip-federated option

The second problem I had was more fundamental: MySql refused to start up, complaining about an issue with an unknown option in the log:

[ERROR] /Applications/MAMP/Library/libexec/mysqld: unknown option '--skip-federated'

The solution to this I found, was simple. This option is set in the /etc/my.conf file and can be safely commented out. To fix this, you need to look for the following lines and add a # character to comment out the option and restart MAMP.

# Disable Federated by default
# skip-federated

Error connecting through socket

The final issue I found was to do with the MySql socket. MAMP has it’s own MySql install that was clashing with the one installed in my OSX installation, even though that one was not running:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'

This was also easy to fix using the Terminal app. Simply login into your Terminal and run the following command:

sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /tmp/mysql.sock

If you experience these issues installing MAMP, following these steps shouldsee you up and running with everything you need to install Magento Commerce.

The term ‘Web 2.0′ has been around for a few years, but I think it’s fair to say that browser vendors have been struggling with the gauntlet of standards compliance thrown down by the web development industry. So Acid3 – launched in October 2008 – is going to be a bar that in fairness, is going to be too high for most current browsers to pass. With IE8 now launched however, it’s not a bad time to stop and see how it fairs against its competitors in the latest Acid3 test.

The Acid3 test reference

The Acid3 test performs a number tests using JavaScript to try and provide some kind of indication of the level of support for a whole host of functions, including support for CSS2.1 and CSS3 specifications, DOM2, data handling and SVG support and you can find a full list of test details here.

I’m not going into detail about the test results here, I’m merely showing how the automated tests for each browser stack up. I’m also not testing on a multitude of platforms – just Mac OSX (Leopard 10.5.6) and Windows XP. As Lars Gunther explains, simply achieving 100 out of 100 is not a pass as such as there are other, less absolute measures of success, so treat this as an early indication of how the big vendors are fairing.

Ready then? OK let’s go. For a browser to pass the Acid3 test, they should render the test exactly as per the reference image below* – pixel perfect – with the browser’s default settings. The rendering progress should also be smooth, which perhaps is a little subjective but the X/100 is the basic benchmark we’ll be looking at for these tests.

* This is scaled down slightly so the test fits the width of this page’s content column but the results are still accurate.

So why do we care?

I’ve worked with younger developers who haven’t had much exposure to legacy browsers and stories of working with Netscape 4.01, 4.7 and IE 4 and 5 pretty much fall on deaf ears for those guys. But for those of us who have worked with these early browsers, standards can only be a good thing.

With the advent of Firefox, Safari and Chrome and the continuing efforts of Opera, Microsoft has had no choice but to sit up and take notice of the calls to improve their browser product and although the tests above appear poor, the level of standards built into IE8 is far better than IE6. Will IE ever be at the bleeding edge of support for technology like CSS3 and HTML5? Probably not, but with the majority of market share, most of us need to develop our sites to work with the lower standards compatibility of IE, so seeing any improvements to these scores can only be a good thing.

And who knows, in a rapidly changing environment (Apple recently announcing that Safari has achieved a full pass that extends beyond the automated test), maybe we’ll start to see more pressure applied on Microsoft from businesses striving to deliver the best sites without having to conditionally code for browsers that aren’t up to the job.