Stuart Jarvis

I was happily recoding the CSS for the redesign of this site when I ran into some additional problems with Internet Explorer’s buggy CSS support that hadn’t been a problem before. Specifically, my new method for allowing users to differentiate between types of link (internal, external and so on) uses a background image in combination with padding to the right of the link to show a different image for each link type (there are also background position bugs in other browsers). IE screws this up by failing to position the background correctly.

OK, I thought, not a huge problem. I’ll just remove all the background and padding info for IE. Afterall, I had used CSS hacks before to isolate IE, such as the Holly Hack (described in an article on dropdown menus or the child selector hack). But then I gave bit of thought to the upcoming release of IE7 and all the uncertainties that might bring.

The problem with hacks

The current hacks work fine for IE versions 6 and below, but they rely on faults in IE to either make it read CSS it shouldn’t (in the Holly Hack) or ignore CSS it should read (in the child selector hack) so that other CSS bugs can be circumvented. They use one bug to solve another. But what if IE7 fixes the CSS bugs that I’ve coded to avoid? It’s not a disaster, but it means I’m excluding IE7 users from getting everything they can from the improved browser. Alternatively, IE7 might fix all the bugs, in which case things are fine. The third possibility is pretty nasty: what if IE fixes the bugs that the child selector and Holly hacks exploit, but not the original CSS bugs thar made me use the hacks? Hmm, I’d be up the proverbial creek without a rowing implement.

A solution?

Luckily, there is a solution, and it’s actually provided by Microsoft (though I came across it on the Quirksmode site). Internet Explorer (in Windows versions from IE5 onwards) implements a strange system known as conditional comments in which it will not ignore comments written thus:


<!--[if IE]>Internet Explorer will not ignore this text<![endif]-->


You can even select for different versions of Internet Explorer (see the Quirksmode site for details). It seems to me that this is a better way of selecting CSS for IE. I do this by enclosing a reference to an IE specific stylesheet in the header of my document:


<!--[if IE]><link rel="stylesheet" media="screen" type="text/css" href="/css/ie.css"/><![endif]-->


An alternative, of course, would be to define the styles inline.

So, let’s return to the possible effects of Internet Explorer 7. If Microsoft fix all the CSS bugs that made me reach for the hacks in the first place then I can just modify the above code to select IE<7:


<!--[if lt IE 7]><link rel="stylesheet" media="screen" type="text/css" href="/css/ie.css"/><![endif]-->


If IE 7 still has the bugs then I leave the code alone. This has the advantage of assuming IE7 will retain the relevant CSS bugs until I’ve had a chance to check otherwise, whereas the child selector and Holly hacks might be broken from the moment IE7 is released. If it fixes some of the bugs then I can just modify the IE stylesheet to reflect this. The worst case scenario is that IE7 will drop support for conditional comments and keep the other bugs, though this doesn’t seem so likely, considering conditional comments an IE thing in the first place and don’t do any real harm.

The people at the Web Standards Project have put together a new test, Acid2, to highlight browser deficiencies in rendering html, css and png. At the time of the test’s creation WaSP believed that all browsers would fail the test. Most browsers still do, but development versions of Apple’s Safari apparently now pass the test.

How it should look

As WaSP suggested, it seems that none of the browsers publicly available when the test was published come anywhere near to passing it. Firstly, let’s take a look at how the test page should be rendered (all the images are at half full size). For the purposes of this test I have considered three current and supposedly standards compliant browsers (Mozilla’s Firefox, KDE’s Konqueror and Opera) and Microsoft’s Internet Explorer. Results for other browsers are also discussed.

Firefox

First up to the slaughter is Mozilla’s Firefox (I used 1.04 for the test). As you can see from the image Firefox doesn’t like the test very much at all. It fails to load the png eyes and generally making a bit of a mess of things. Without the reference image you’d find ti hard to work out what it is supposed to be. But for all its problems, this does appear to be the best rendering of any of the currently released browsers. Presumably the same rendering will apply to all current Gecko based browsers.

Konqueror

Given the links between Apple’s Safari and KDE’s Konqueror (Safari’s rendering engine is based on Konqueror’s KHTML) you might expect Konqueror to do a fairly good job. You’d be wrong. Firstly patches for Safari don’t translate easily into Konqueror because many of the improvements rely on components of the Apple OS for their operation and can’t simply be merged into KHTML. Secondly, the currently released version of Safari (as opposed to the current development version) apparently makes a complete dog’s breakfast of the test. Konqueror’s rendering (I used 3.4 for the test) is pretty horrible – those scrollbars contain a 404 not found server message.

Opera

Like all browsers, Opera can have trouble with compliant code. And Opera 8 makes a bit of hash of Acid2. I mean, what is that red background all about? The white patch is again indicative of a 404 error from the server due to the browser requesting information incorrectly. In Opera 7 (the image is from Opera the white area has scroll bars, like Konqueror.

Internet Explorer

I tested version 6 of Internet Explorer. IE gets a bigger screenshot than all the others because it failed the test in breathtaking fashion, smearing various parts of the picture down the page. To be fair to IE, it is an old browser, far older than the others that were tested and contemporary versions of browsers from the other vendors tested might be much worse than the latest versions. Still, the lack of a recent IE release is the fault of no one but Microsoft. Interestingly the page explaining the Acid2 test makes specific reference to the upcoming Internet Explorer 7, though this is probably more in hope than expectation that IE7 will pass the test.

Other browsers

I have not been able to test Safari (I don’t have a Mac) but from the page discussing making Safari pass the Acid2 test it seems that currently released versions of Safari make a bit of a mess of things and have the same red background all over the place that Opera has. It’s interesting that this would therefore seem to be worse than Konqueror (though I haven’t seen a screenshot, so it may be better in other respects). It seems that the next release of Safari will pass the test, throwing down the gauntlet to the other browser vendors.
Mozilla seems to be addressing the problems highlighted by Acid2, though it doesn’t look as if all the rendering bugs will be fixed anytime soon. The Konqueror developers have access to the fixes implemented by the Safari developers, but many are so specific to the Apple OS as to be of little use. A KDE developer discusses the problems and also criticises the relevance of the Acid2 test. Some of the criticism seems justified, as much of the Acid2 test is sufficiently obscure for a browser’s lack of support to not matter in the real world. It would be great though if all the browsers interpreted the standards in the same way, and I do think tests like Acid2 are good at stimulating this, creating discussion among developers and highlighting obscure bugs.
Anyway, there is some comfort for the browser vendors. The W3C’s own Amaya browser apparently fails the Acid2 test with considerable aplomb: it’s almost as bad as Internet Explorer.