Style Sheets without tears - 2
Last month, I showed how you could add general styles to a page by providing specifications for the body, headings, lists, tables and links within the <head> section of the page. I also pointed out that, where all this is fine in theory, it doesn't always work in the way expected because there are so many browsers out there that have different ideas of how to interpret style sheets.
When browsers don't behave as expected, you have several options.
1. You can say, "Well, there aren't many of those browsers about these days so it's just too bad if it doesn't work."
2. You can use the parts of Cascading Style Sheets that do work in problem browsers and ignore the bits that don't.
3. You can write a 'browser sniffer' routine that identifies browsers and browser versions and redirects the reader to another page or substitutes another style sheet that will work.
The first option is the easy one because you don't have to do anything. Sure, the problem browsers are disappearing but not as fast as we might like. So, this "quick 'n' dirty" option will provide the least challenge for the designer, the cheapest solution for the publisher but the poorest experience for the surfer. I don't think I need to say any more about this one.
The second route needs a little more effort than Option 3, not as much as Option 1 but produces a reasonably good user experience. Yes, it means that you have to forego some of the niceties of the latest CSS2 specifications but Web design is all about compromise and always has been. You just have to decide which compromises are the least harmful. This is the system I'm going to discuss this month.
The third option is the best one, but requires a considerable amount of knowledge about browser peculiarities and how to address them. It also means that you have to spend more time, and charge more. If none of this is a problem for you, go for it! More about this next month.