| introduction | selectors | properties | advanced | real world CSS tables | compatibility | web design | validating |
 |
 |
 |
 |
One of the number of reasons developers often give for not adopting style sheets is that they "don't work" in current 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 3.5) without a great deal of effort.
In this part we'll learn to avoid 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 of the 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. By following the suggestions in this article, you'll be going a long way to "future proofing" your sites through using valid standards based HTML and CSS.
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 desktop publishing for the web. Rather, as we have seen, style sheets "suggest" to a browser how to draw a 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.
We consider this in detail in a later section on web design.
Style sheets have long been a source of frustration for web developers, because browser have not provided full (or even error free partial) support for them. Couple this with the complete lack of support for CSS in older browsers, and you'd be forgiven for thinking it's a waste of time even thinking about developing with style sheets. We saw earlier a number of 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.
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.
You are probably thinking your pages will 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 could add background color, text and link colors to the <body> of your pages, but I'd probably avoid doing that. I'd strenuously recommend avoiding using any more "presentational markup". This means no more elements like <font>, <b> 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. In fact, only a small percentage will have less than solid support for CSS these days. 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.
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, with perhaps the exception of Opera 3.5/3.6. Nor are there any fully compliant browsers, although Netscape Navigator 6, Opera 5 and (stretching it a bit here) Internet Explorer 5 for the Macintosh come close.
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.
Firstly, browsers which support style sheets are often 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.
Validators ensure that your HTML conforms to one of the World Wide Web Consortium recommendations for HTML. It's 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 the future. Future browsers may not maintain bugs and the general leniency to imperfect HTML, as they do at present. From this day forward you should stop relying on these bugs to make your web pages "work".
A later section of this guide covers validation of both HTML and CSS in detail.
Once we've ensured our HTML is correct we need to design our style sheet. There are two important considerations here.
No browser supports every aspect of CSS. Where a feature is missing in a browser, you can happily use it, as it will have no effect in that browser. In essence, users of browsers which support the feature have an enhanced experience in relation to users of browsers 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 supported by Internet Explore 4 and up, and Netscape 6, but not in Netscape 4). Internet Explorer and Netscape 6 users have the enhanced experience of dynamically changing links, while users of other Netscape 4 are none the wiser.
It important to note that you shouldn't rely on such features. If something is necessary for a page to be readable or usable, then it isn't accessible. An example of this is the positioning aspects of CSS2. Netscape Navigator 4 and up, and Internet Explorer 4 and up both support aspects of positioning, but Opera 3.5/3.6 does not. Pages which rely on positioning aren't going to be as accessible to some visitors to your site. At the very least, in such situations, provide an alternative page for browsers which don't support a feature your page design relies upon.
Throughout this guide, you'll find detailed compatibility information for all CSS supporting browsers that are in significant use. Unless a feature is vital to your presentation you can generally use it happily, even if it is not supported by some browsers. If it is vital, think about whether you actually need it.
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.
Our biggest headaches with CSS are caused by buggy support for CSS. This is increasingly less of a problem, with the real reduction in the use of Netscape 4, and Internet Explorer 4. 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.
Again, this guide provides a detailed resource for identifying features which may cause difficulties for your sites visitors. Read the information below the Browser support table for the properties you are planning to use.
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 the browser compatibility information, to determine whether the feature you are using is supported, and if so, whether there are bugs in that support.
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.) As the number of users of Netscape 4 and older versions of Internet Explorer drops below 10%, this is becoming much less of an issue.
There are four ways of implementing this strategy. All are less than perfect, but have their strengths.
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 simple 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 highly recommended.
One hack commonly used is to rely on the bug we saw earlier in Netscape 4, where @import is not supported. Developers often link to a style sheet with a minimal set of styles that will work with Netscape 4, and then use @import to import another style sheet with statements which cause difficulties with Netscape 4. These later statements will not be seen by Netscape because it does not support @import.
You could, as many developers do, ignore Netscape 4 altogether, or at least having ensured that the pages are legible, not particularly concern yourself with the cosmetic difficulties the browser often presents. In a word, you can "get over Netscape".
Just as it is important to ensure that your HTML is valid, it's 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 (especially for Windows) can be very lenient toward invalid style sheets. If you usually "test" your web pages with Internet Explorer for Windows, you might get some surprises when you view the page in another browser which supports CSS. We discuss this in more detail in a later section in this guide.
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.
The table outlines the basic level of support in major browsers, in April 2001, at our website. While it is far from scientific, it accords reasonably well with other tables of browser popularity. For details of the support for each browser, see our browser support information for each selector, property and other feature of CSS throughout this guide.
|
Browser
|
CSS Support
|
% of users (est.) April 2001 |
|---|---|---|
| Netscape Navigator 1,2,3 | No support. | ~0% |
| Internet Explorer 2 | No support. | ~0% |
| Internet Explorer 3 | Very limited, buggy support. | ~0% |
| Opera (prior to version 3.5) | No support. | <1% |
| Opera 3.5/3.6 | Relatively comprehensive and good support for CSS1. No support for CSS positioning from CSS2. | <1% |
| Opera 4/5 | Excellent support for all of CSS1 and much of CSS2. | <1% |
| Netscape Navigator 4, 4.5 Windows and Macintosh | Partial, buggy support. Text, color, background and positioning basics can be used safely, but with care. Likewise CSS positioning. | ~10% |
| Internet Explorer 4 Windows and Macintosh | Partial, buggy support. Text, color, background, border and positioning basics can be used safely, but with care. Somewhat better than Navigator 4 but far from perfect. | ~2% |
| Internet Explorer 4.5 Macintosh | Considerably better support for basic and advanced features than version 4 and Navigator. | ~0% |
| Internet Explorer 5 Macintosh | Excellent CSS1 support, and worthwhile support of a fair amount of CSS2 | ~1% |
| Internet Explorer 5 Windows | Considerably better support for basic and advanced features of CSS1 than version 4 and Navigator. | ~60% |
| Navigator 6 | Near perfect support for CSS1 and excellent support for many aspects of CSS2. | ~2% |
| introduction | selectors | properties | advanced | real world CSS tables | compatibility | web design | validating |
|
|
|
|