CSS-P in Current Browsers 2
Last September, I put a batch of browsers through some gruelling tests to see how well they coped with Cascading Style Sheets layouts. More specifically, I wanted to see how far I could push them before they fell over. When you use CSS for layout, if the browsers don't behave as expected, you can end up with a mess. It's just like pulling a can of beans from the bottom row of a supermarket display.
This month, I've applied those same tests to the popular browsers of today. Some browsers have changed very little in the last year, some have changed significantly and some new ones have appeared.
I've taken the browsers from the 'Latest Browsers' list at the top of this page. Although there are nine products, they can be broken down into three categories. Those that are based upon the 'Gecko' rendering engine - Mozilla, Netscape, Camino and Firebird. Two are based upon a Mac OSX framework called WebCore - Safari and OmniWeb. The rest use proprietary rendering engines - Microsoft Internet Explorer, Opera and iCab. The Mac and Windows versions of Internet Explorer only share the name. Unlike the other cross platform browsers, they are two entirely different products and have to be treated separately. The Mac version of Opera is a version behind Windows, and it shows.
I have left one browser out that was featured last time. Netscape 4.x is no longer a current browser and its use is rapidly diminishing. Even though it is still more significant than most of the minority browsers included, and can't be written off yet, doing CSS-P tests with it is a waste of time. It doesn't want to play!
Reliable browser stats are very difficult to find but Google publishes a graph of browsers used to access their site. This represents a reasonable cross section of the surfing public and gives a good overall picture without getting into dubious absolute percentages.
The Tests: Site used for testing
I put together a set of twenty pages at FunWithFonts.com using a selection of layout techniques that I knew could be challenging. Most browsers can handle CSS-P if absolute positioning is used, based on the 'top' and 'left' edges of the page. When you start to use relatively positioned elements or relate absolute positions to the right and bottom edges of the page, you are more likely to run into trouble.
Another technique I've used extensively, is to overlay graphics in different ways. Putting transparent GIFs on top of JPEGs, for instance, lets you have crisp lettering reversed out of a photograph without worrying about compression artefacts. Using a GIF 'mask' on top of a highly compressed JPEG allows all kinds of subtle shading effects that would be impractical otherwise because of file size considerations.
Some pages use what I call 'house of cards' relative positioning where each box is positioned relative to another box in sequence. In theory, this should be perfectly okay. In practice, it's really asking for trouble. Internet Explorer has a different idea of what 'relative' means from all the other browsers. It also misinterprets the concept of 'padding' - as laid down in the official W3C specifications for the box model.
For my examples, I've found workarounds that satisfy Explorer and the so-called 'correct' browsers. With the vast majority of surfers using Explorer 6, it needs to be accommodated regardless of its lack of adherence to standards!
Each page has an 'info' link that brings up an explanation of the techniques used. Using tricks like these for a mass audience Web site last year, would have been very dangerous indeed. Let's see what happens now.
Last time, I ran each page through the WC3 HTML and CSS validators to make sure they were squeaky clean. I did the same again because the validators have been updated. All the CSS validated without any problem. The HTML validator complained about the embedded Flash movies, as it always does, but everything else was okay.
As I expected, the overall results are significantly better this time than they were a year ago. Three browsers scored 100%, which meant that they had no problems with the pages at all. Most of the rest had a few minor quirks, but little to worry about. iCab remains at the bottom of the pile as far as CSS-P is concerned. With little attempt to support CSS-P, I'm going to ignore it.
Most interestingly, IE6 (Windows) has pulled up from third place to equal first with Mozilla/Netscape and Camino. It has been updated more frequently than IE 5 (Mac), which dropped a couple of points because, in one instance, it stretched a background image <hotstuff> vertically - no other browser did this.
Opera 7 has improved considerably over version 6. The only slight problem I saw was to do with the right hand scrollbar not being drawn on one page <banknote>. For the rest of the pages, it performed admirably.
Another finding that surprised me a little, is that browsers that shared the same rendering engine did not always perform identically. There were minor differences between the Gecko browsers, with the least mature (Firebird) dropping two points for wrongly placing one element. There were also small rendering differences between Safari and OmniWeb, but nothing to loose any sleep over.
Browser CCS-P rendering scores for 20 layouts
5 - for a perfectly rendered page
4 - near perfect rendering but minor cosmetic glitches
3 - rendered but with elements in the wrong place
2 - broken, but readable
1 - too badly broken to be of any use
Ignoring iCab, the small differences I encountered in the other browsers are almost insignificant. With a different set of twenty layouts, I would expect the results to shuffle order fractionally. What is very encouraging, it the fact that CSS-P rendering in current browsers is so similar and predictable.
I've left performance issues out of these tests; I was more interested in their ability to render layouts predictably. Nevertheless, it was very apparent that the newer, smaller browsers were nippier. The behemoth Mozilla, was noticeably slower than the others.
CSS-P and XHTML
One last test, that I did out of sheer curiosity, was to convert each test page from a minimal HTML 4.01 Transitional DocType, to a XHTML 1.0 Transitional DocType.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">Changed to...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
Internet Explorer 6 is particularly fussy about the DocType declaration and can give inexpected results if you are not careful. There are significant differences in HTML 4.01 Transitional with and without the DTD section.
I stuck an 'x' in front of each filename and uploaded the XHTML files to the server so that I could flick between the HTML and XHTML versions to see if there were any differences. There were, in IE 6 and Opera, but they were minor things such as the line spacing on the first line of text. For the rest of the browsers, differences between HTML and XHTML were virtually non-existent. Had I not validated the HTML files first, the differences would have been more significant. It's when you stray into the misty regions of invalid markup that you can expect nasty surprises.
The other point I have to make is that I hand-coded these pages taking IE 6's foibles into consideration. I avoided the use of 'padding' and was careful about situations where inheritance was ambiguous. It is better not to make assumptions about browsers' default styles. Nail them down explicitly at every chance.