articles
Getting Serious about Compatibility
Abstract
Author: John Allsopp
History: First published here May 1999, revised March 2000
How to create style sheets that don't just "work", but really work. Explains the different ways in which a browser can fail to support CSS and looks at different approaches and techniques you can use to deal with these failures.
One of the number of reasons developers often give for not adopting style sheets is that they "don't work" in today's browsers. While you could be forgiven for thinking this, you can in fact make style sheets work for you, and still have pages accessible in any browsers (even Mosaic 1.0 and Internet Explorer 37.5) without a great deal of effort.
In this article we are going to learn how to make the most of style sheets, while not falling prey to the problems that invalid HTML, invalid style sheets, and of course partial and buggy browser style sheet support can cause. We'll also try to avoid some cross platform problems that can crop up.
We also want to ensure that our pages are as forward compatible as possible, by developing standards based pages, and ensuring that our pages comply with these standards. By following the suggestions in this article, you'll be going a long way to "future proofing" your sites through by using valid standards based HTML and CSS.
It Doesn't Work: A Word of Warning
Often developers are concerned that their web pages look exactly the same in different browsers. When this isn't the case, you can hear developers cry "style sheets don't work". Keep in mind that style sheets are not the equivalent of PDF (portable document format, the format for Acrobat files). CSS isn't a way of telling a browser exactly how a page should appear.
Rather, style sheets "suggest" to a browser how to draw the page. Style sheets were designed to be flexible, and to allow users also to have their say in how a page should be presented. So if you are looking for a page layout language, style sheets are the wrong place to look. For now, there is PDF or nothing. Various proposals have been made for similar standard technologies, but there really isn't anything else on the horizon.
The Difficulties: Partial Support, Buggy Support, No Support
Style sheets have long been a source of frustration for web developers, because as yet no browser has provided full (or even error free partial) support for them. Couple this with the complete lack of support for CSS in older browsers, and it looks like its a waste of time even thinking about developing with style sheets. I've written elsewhere about the benefits of style sheets, but here we are going to see that taking advantage of these benefits doesn't have to be a nightmare.
Let's address the problems presented by each of the levels of support for CSS outlined above, then develop some general strategies for avoiding the pitfalls.
No Support
You mightn't guess it, but browsers that don't support style sheets are the easiest to develop style sheets based web sites for. You don't have to take into account anything. Browsers which don't support style sheets (see the chart at the end of this article for a list of major browsers and their level of support) simply ignore them.
But won't my pages look a bit boring? They probably will, if all of your style information is where it should be, in your style sheet. If you want to make your pages look a little more enticing for pre-style sheets browsers, you can add background color, text and link colors to the <BODY> of your pages. I'd strenuously recommend avoid using any more "presentational markup", that is <FONT>, <B> elements and so on in your HTML. As HTML evolves beyond version 4.0, these presentational elements are becoming obsolete (deprecated), with style sheets the World Wide Web Consortium's recommended way to add presentation to your pages.
This approach might have been a problem a couple of years ago, but if you check your web logs for the kind of browsers that visit your site, you'll probably find only a small percentage of browsers will display the rather dull HTML only pages. So the trade off isn't all that bad. We've got to cut those apron strings to presentational HTML some time, and now is as good a time as any.
Partial and Buggy Support
The next best browsers to develop for would be those which had partial support for style sheets, but whose partial support was flawless. Sadly, there are no such browsers. Nor are there any fully compliant browsers, although Netscape Navigator 6 promises a lot, based on early releases, and Internet Explorer 5, by reports, is looking good in its beta stages. The less well know Opera (available currently for Windows, but with versions coming for many platforms) probably supports CSS1 best of all.
The browsers we really need to contend with are those whose support for CSS is partial (that's OK) and buggy (that's the hard bit). Developing style sheets based web pages for browsers whose support is buggy and incomplete is a bit of work, and there are a number of factors to consider.
Get your HTML Correct
Firstly, browsers which support style sheets are very choosey about HTML. Minor problems with your HTML which might "work" by themselves, can cause all sorts of dilemmas when style sheets are applied. This is why we need to move beyond "it looks fine in IE and Netscape on my computer" testing of our pages. To ensure your HTML is correct, it needs to be validated.
Some HTML editing tools like HomeSite have validators built in. There are also a couple of very good ones online, at HTML Help and the World Wide Web Consortium. You can also find downloadable validators that run on your own computer. See the resources at the end of the article for details.
Validators ensure that your HTML conforms to one of the World Wide Web Consortium recommendations for HTML. Its a good habit to get into as it ensures that your pages work on browsers other than those you have "tested" it on, especially those which will come in future, and which may not maintain bugs and general leniency to imperfect HTML which current browsers tend to have, and which far too many web pages rely on to work.
For hands on instructions on how to validate your pages, see our Validation tutorial.
Once we've ensured our HTML is correct we need to design our style sheet. There are two important considerations here.
Missing Features
No browser supports every aspect of CSS. Where a feature is missing, you can happily use it, as it will have no effect in the particular browser. In essence, users of browsers which support the feature have an enhanced experience in relation to users of those which don't support the particular property. A simple example of this is the A:hover pseudo class. This allows you to suggest how links should appear when a cursor is over them. (This is part of the CSS2 recommendation, but not the CSS1 recommendation, and is supported by Internet Explore 4 and up only). IE users have the enhanced experience of dynamically changing links, while users of other browsers are none the wiser. And when other browsers adopt the feature, their users will also see the effect.
It important to note that you shouldn't rely on these features. If something is necessary for your pages to be accessible, then it isn't accessible. An example of this is the positioning aspects of CSS2. Navigator and Explorer 4 both support aspects of positioning, but Opera does not. Pages which use positioning aren't going to be accessible to many visitors to your site. At the very least, provide an alternative page for such browsers.
Use one of the compatibility guides listed at the end of this article to determine which features are not supported by a particular browser. Unless a feature is vital to your presentation you can generally use it happily, even if it is not supported by some browsers.
Real problems with style sheets come about not through lack of support, but when a feature has buggy support in a browser. Here you need to carefully determine the effect of the bug in deciding whether to use the feature or not.
Broken Features
Our biggest headaches with CSS are caused by buggy support for CSS. Because every browser has buggy support for at least a number of features of style sheets, we need to identify which these are, then determine whether those bugs affect the pages we want to design. Then, we can decide whether to avoid these features and what possible work-arounds there are.
Where do we go for this? Luckily, others have felt your pain, and provided resources to help overcome these difficulties. And the end of the article you'll find pointers to a number of sites that provide good compatibility reports, and information about how to avoid and work around limitations and bugs.
As you develop your style sheet, if problems arise in the browsers you are "testing" with to ensure your page is widely accessible, the first point of call should be one of these lists, to determine whether the feature you are using is supported, and if so, whether there are bugs in that support. One style sheet editor (in fact the one I developed) even has warnings built into the application. It's listed at the end of this article too.
Multiple Style Sheets
One strategy that many developers are keen to adopt is to design different style sheets for different browsers, and serve the appropriate one when a page is requested by the browser. I tend to think this approach is more trouble than it is worth for most sites (if you have a large amount of traffic, and really need to ensure maximum legibility for the widest range of browsers this might be a necessary path for you.)
There are three ways of implementing this strategy. All three are less than perfect.
First, you can do server side sniffing for the type of browser, then serve up the style sheet appropriate to the type of browser detected. Few developers have the luxury of this solution, and how it's done depends on the server. Keep in mind that it can be a little tricky detecting exactly which browser is requesting a page, and you need to determine how to respond to an unknown browser. Do you treat it as CSS aware or CSS ignorant?
Next, for most developers a javascript, client side sniffer might be appropriate. When a page is loaded, the script can determine the type and version of the browser, and write the appropriate link into the HEAD of the HTML document. This approach suffers from similar problems as the server side solution above, although unlike server side solutions, most web developers are in the position to do something about it.
Lastly there are kludgy solutions based on bugs in current browsers. This really is a tricky thing to rely on, and probably not greatly recommended. One particular suggestion comes from David Honner. For the full suggestion, see the newsgroup posting in dejanews.
Note that this suggestion isn't entirely uncontentious, and you can find discussion as to its exact merits and problems at dejanews.
Validate your Style Sheets
Just as it is important to ensure that your HTML is valid, its also important to ensure that your style sheet is correct. It is common on the style sheets news group to see news items bemoaning a bug in one browser, when the cause is in fact incorrect style sheet syntax that another browser is lenient towards. Beware that Internet Explorer can be very lenient toward invalid style sheets. If you usually "test" your web pages with Explorer, you might get some surprises when you view the page in another browser which supports CSS.
The most common example is leaving units off values. For example the following rule is invalid CSS. Browsers should ignore it.
h1 {margin-left: 12}
This specifies that the left margin for <H1> elements should be 12. 12 what? It isn't specified, and so, this is invalid, and should be simply ignored. Netscape Navigator does so, but Internet Explorer happily treats this as 12 pixels. Often developers consider that Navigator is buggy (because the style sheet "doesn't work") when in fact it is behaving correctly in ignoring the rule. IE "works" but is buggy.
Short of knowing the specification backwards (I don't, and I would suggest very few people on earth do) how can we ensure that out style sheets are valid? Validate them! There are two good validators that will help you ensure that your style sheet is valid, and will even warn you about possible problems. You can find their locations in the list of resources at the end of this article.
Alternatively, you can use a style seet editor which will ensure the style sheets you create are syntactically correct. See the resources for information on this.
Operating System Issues
One last consideration when developing style sheets that work: font sizes. Few developers have the luxury of being able to view their pages regularly on both Macintoshes and the Windows platform (let alone other platforms). Most of us are unaware of the differences in font sizes between these platforms. A point is a point right? In fact, it is not, at least not from the perspective of the user. A 12 point font on Windows appears "larger" in relation to the rest of the page than it does on the Macintosh.
OK, so I just use pixels: a pixel is a pixel surely? Sadly, the same rule applies. Units like pixels and points are absolute values, and absolute values are fraught with danger when designing pages for multiple platforms. Using a relative value, such as em or % is much preferable.
Specifying a font size such as H1 {font-size: 1.5em} suggests to the browser that Headings of level one should be 1.5 times the size of the font of the parent element. The same effect can be achieved using percentage values, e.g. H1 {font-size: 150%}.
The downside to this is that you don't directly specify the size of the font for an element, rather, it is computed in relation to the value of the parent element. The upside is you don't have the dilemma of either illegibly small text for Macintosh based readers, or ridiculously large text for Windows readers. And keep in mind devices like WebTV, palm based devices, mobile phones and other web browsing platforms that will be arriving in increasing numbers. Using these relative values means that your pages will be legible even on these platforms. How a palm sized screen interprets 12 points or 15 pixels is anyone's guess.
Style Sheets Do Work
Style sheets do work, and you can take advantage of them today to make your web pages more sophisticated in appearance, while also taking advantage of all the other benefits of the technology. At first, you might find the process of ensuring that your HTML and CSS are valid, and of avoiding known bugs and limitations tedious, but the tools and resources are there to help you. Once you've got a bit of experience under your belt, you'll find creating compatible, working style sheets painless, in light of the advantages that style sheets give you.
Browser Support Table
The table outlines the basic level of support in major browsers. If a browser is not mentioned, assume that it has no support for style sheets. For greater details, see one of the compatibility guides listed below.
| Browser | Support |
|---|---|
| Netscape Navigator 1,2,3 | No support. |
| Internet Explorer 2 | No support. |
| Internet Explorer 3 | Very limited, buggy support. |
| Opera (prior to version 3.5) | No support. |
| Opera 3.5 and higher | Relatively comprehensive and good support. Considered by many to be as good as any in its support. |
| Netscape Navigator 4, 4.5 Windows and Macintosh | Partial, buggy support. Text, color, background and positioning basics can be used safely, but witd care. |
| Internet Explorer 4 Windows and Macintosh | Partial, buggy support. Text, color, background, border and positioning basics can be used safely, but witd care. Somewhat better tdan Navigator 4 but far from perfect. |
| Internet Explorer 4.5 Macintosh | Considerably better support for basic and advanced features tdan version 4 and Navigator. |
| Internet Explorer 5 Macintosh | Still in private beta, news of CSS1 and some aspects of CSS2 support is very encouraging |
| Internet Explorer 5 Windows | Considerably better support for basic and advanced features of CSS1 tdan version 4 and Navigator. |
| Mozilla M13 (Navigator 6) | the current (March 2000) alpha version has near perfect support for CSS1 and excellent support for many aspects of CSS2. Full release due middle 2000. |
Resources for this Article
Browser Compatibility Guides
The House of Style, a web site dedicated to providing extensive information for learning and developing with style sheets has a compatibility report that covers Internet Explorer 4 and 4.5 for Macintosh, 4 and 5 for Windows, Netscape 4 and 4.5 for Windows and Macintosh, Opera 3.6 and Mozilla.
The original compatibility guide, from Web Review, features an annotated "mastergrid" of compatibility in Internet Explorer 3 and 4 for Mac and Windows, Netscape Navigator for Mac and Windows and Opera for Windows.
The CSS pointers group, who maintain the most extensive list of CSS related web based resources have a section devoted to compatibility reports.
HTML Validators
HTML Help has an online HTML validator which you can paste your HTML into, or with which you can validate your current sites by giving it their URLs.
The World Wide Web Consortium has an online HTML validator. Your site must already be on the web to be validated by it.
For a list of downloadable validators that you can run on your own computer, see TUCOWS, which has sections for Macintosh and Windows validators.
CSS Validators
You can validate your style sheets using an online validator from the World Wide Web Consortium.
HTML Help also provides an online CSS validator. In addition to validating your CSS, it will also warns of possible usability problems with your style sheets.
Authoring Software
Style Master, developed by the author, has built in compatibility information for Navigator and Explorer for Macintosh and Windows. It helps you avoid compatibility problems before they start, as well as ensure your style sheets are correct and adhere to the standards.
John Allsopp is a director at westciv and the lead developer of Style Master CSS editor. He writes widely on web standards and software development issues and maintains the blog dog or higher.