Westciv Logo

These materials are copyright Western Civilisation Pty Ltd.


They are brought to you courtesy of Style Master CSS Editor and Westciv's standards based web development courses.

Please see our website for detailed copyright information or contact us [email protected].


Getting to grips with style sheets

Read more westciv articles


Author: John Allsopp

History: First published here February 2000, revised March 2000.

From questions asked on newsgroups, emails I receive, and general conversations I have, it seems that many developers still doubt the worth of working with style sheets. Above all, this seems to come from frustration, a frustration born in part from misunderstandings, in part from the shortcomings of existing browsers. In this article, I won't try to argue why you should adopt style sheets. I want to address the misconceptions and misunderstandings that give rise to frustrations with CSS, and to provide ways of avoiding the difficulties with incomplete browser support for CSS. By the end you'll have some simple strategies to head off pitfalls in advance, and clear up problems if they arise.

Misunderstandings, Misconceptions and Wild Goose Chases

Style sheets will always frustrate and disappoint you if you think of them as DeskTop Publishing for the Web. Get that idea out of your head right now. Web pages aren't made of paper. If you'd like to explore this idea a little more, please take a look at this article I wrote a little while back, which many developers have told me they found useful in getting to the bottom of using style sheets effectively.

In practice, what do I mean that web pages aren't made of paper? Why is it an issue? Developers often say things like "I want to control the look of my page", or "I want to force people to view the page" with a certain window size, or with fonts at a particular fixed size. People say things like this all the time. That's because they are thinking of their web page as a fixed, frozen design, not as fluid and adaptable.

But why should you think like that? Well, it's unavoidable really, its the nature of the medium. You can't stretch and resize a piece of paper, but you can resize a window. So stop thinking of it as a liability, and think of it as a feature. Readers can choose the screen resolution, window size, font size and so on that suits them. This might be because their eyesight isn't as good as yours, because they have a high resolution monitor, because they are plain ornery. As a designer, it really isn't your business. Your business is to develop pages appropriate for the medium.

Lets look at this in more practical terms. Developers are forever asking on the style sheets newsgroup "how come my site is unreadable on the Macintosh?" or "how come my text looks larger on the PC? How do I make it exactly the same size?".

There are a number of tricky issues tied up in this seemingly simple (and apparently reasonable) question. First up, why is it important that the pages look identical on both platforms, all the way down to the physical size of the font on the screen? If you think about it, its almost the same as worrying that the font looks too small when someone reads it on a 1024x768 monitor on a 15" screen? And if someone sets their default font size to "largest" or a particular size, why shouldn't your page honor their wish?

Secondly, the concept of the web here is essentially "www = 2 platforms, 2 browsers". The web is a bit more than that though. Its a myriad of operating systems, and numerous browsers. Beyond that its WebTV, handhelds, PDA, mobile phones, braille readers, text to speech converters. Now today the majority of visitors to a site will be in front of a "computer", using one of two browsers. But I bet that in 2 or 3 years time that won't be the case. As a web designer, are you doing your clients (or yourself) any favors by catering to just 2 browsers? Why not start future proofing your pages now? I hope you can see that the aim of making your pages look the same everywhere is really a wild goose chase. Sure, it might be just about doable with plenty of hacks and non standard work-arounds on two platforms and two browsers, but forget it when it comes to anything else. Besides, it doesn't even make sense.

OK, what do I do now? - strategies for adaptable pages

So what can you do in practice? The answer is simple, but the devil as always is in the details. Don't use resolution dependent (or "absolute") units. This is true of font-size but also for margins, padding, widths and so on. So you want to avoid using points (pt) pixels (px) and quite obviously inches (in) millimeters (mm) and centimeters (cm). Instead, you can use one of two really useful units - ems and percentages.


Let's start with the easy one, percentages, then we'll take a look at something which might be unfamiliar, but which you'll come to love - the em unit.

You can use percentages just about anywhere that you might otherwise use points or pixels with CSS. The advantage is, rather than having pages fixed in size and layout, the layout can adapt to the users setting (font and window size, for instance).

How does this work? Suppose you want the main text of a page indented a certain distance. You could do this like this

p {margin-left: 30px}

Then, regardless of the width of the window, your text will have a 30 pixel margin. On a small low resolution screen this might be ridiculously large, reducing the amount of text that fits on the screen significantly and rendering your pages frustrating to read. On large, high resolution screens, the 30 pixel margin may be far from apparent. But we can use percentages to rectify this. With

p {margin-left: 5%}

the margin of your text adapts to the window size, rendering the margin useful in any situation.


Instead of percentages, another relative measure can be very useful - the em. I'll explain the em in a moment, but for more in depth discussion see Tod Fahrner's wonderful pages on all manner of style sheet related issues, and Jan Roland Eriksson's 'Basic "old timers" typesetting practices'.

Generally a percentage unit for a property in CSS refers to the width or height of the parent element. In the case of paragraphs, usually margin-left: 5% will mean the left edge of the text in paragraphs will be 5% of the width of the window from the left hand side of the window. However, you might want your margins and other layout features to be proportional to the size of the text of an element. This is where the em comes in. In short, an EM is the height of a font. In practice this means you can specify page layout as a function of the font size of an element. If you specify

p {margin-left: 1.5em}

you are saying that the left magin of paragraphs should be 1.5 times the height of the font of that paragraph. So, when a user adjusts their font size to make a page more legible, the margin increases proportionally, and if they adjust it to make it smaller, the margin adapts again.

Font sizes for legibility

ems and percentages can also be used for font-sizes so that pages will adapt appropriately to a user's font size settings. Let's take a look at a bad example

body {font-size: 12pt}

h1 {font-size: 16pt}

h2 {font-size: 14pt}

h3 {font-size: 12pt}

Now, suppose our reader has set their default font size to 18pt (or its equivalent). The headings on your page are going to look smaller than the body text. This is not a desired outcome. We could simply do the following, to resolve the problem altogether

body {font-size: 1em}

h1 {font-size: 1.2em}

h2 {font-size: 1.1em}

h3 {font-size: 1em}

or alternatively

body {font-size: 100%}

h1 {font-size: 120%}

h2 {font-size: 110%}

h3 {font-size: 100%}

In the first of these two, you are suggesting that the text of the body be the same size as the user's default size. Headings of level one should be 1.2 times the size of the text of the element which contains them (usually this will be the body), headings of level 2 will be 1.1 times the size of the text of the element which contains them and so on.

The second example is essentially the same, however, we've expressed this in terms of percentages.

Hopefully you'll agree that developing pages appropriate for all browsers and browsing situations is not all that involved. You might need to change your expectations a little, and adapt a couple of new strategies, but getting to grips with this aspect of style sheets isn't rocket science.

Browser Issues

Having stopped a few wild css goose chases, I'd like to address the other big issue which seems to daunt and frustrate those trying to get to grips with CSS. Those wretched browsers. Trust me, I feel your pain, as do all those who have adopted style sheets as part of their development regime. But there are resources at hand which will help you overcome these frustrations.

Firstly, I'd like to say a few words generally about the level of support for CSS is current browsers, and indeed all browsers, and about the future of the web and CSS.

One. Unless you rely on CSS positioning for the layout of your pages, then provided you use appropriate and validated structural markup, and valid style sheets, your pages will be accessible in any web browser on any platform. Sure, they might look a little on the dull side, but the content will be available to all who want it.

Two. All of the browsers which support CSS (with the dishonorable exception of Internet Explorer 3) support enough CSS that you can apply more style to your web pages using valid markup than you have accessible in HTML. This means you can anything you can do with HTML with CSS, and more. This particularly applies to the appearance of text (color, font size, fonts, and so on) as well as layout such as margins, padding and so on. Careful use of positioning also enables you to abandon complex table based layout tricks. All of this is true of Netscape Navigator 4 and up, Internet Explorer 4 and up, and Opera 3.5 and up (with the exception of positioning which it doesn't handle).

Three. Sometimes, when something works in one browser and not in another, it's the browser which doesn't work that is correct. That's because Internet Explorer is very lenient towards incorrect CSS syntax, while Netscape Navigator is very finicky about CSS syntax. And Navigator is correct, because rules with incorrect syntax must be ignored. And if you think that's pedantic, and Internet Explorer is morally right, then think about the future. What if CSS14 introduces a font-morph property, and your Internet Explorer tries to make sense of that by reading it as font or font-size or...?

Four. There is no alternative. In the future, there will be no presentational markup in HTML. XHTML has no presentational markup, no more <font> elements and so on. Governments around the world are mandating that, just as disability access is required for buildings, so too is it required for web sites. For instance, text to speech browsers can't read the content on pages layed out using complex tables for layout effects. CSS greatly aids accessibility. It will become extremely important for the future of the web.

Hopefully I've addressed some of your pressing concerns regarding browsers and CSS. The biggest worries developers seem to have is things "not working". Yes, many thing don't work. They are simply ignored. It might be a bit of a pain that you can't "control" the width of text fields in forms with Navigator 4. But it isn't the end of the world. So it's important to develop a strategy for dealing with browser compatibility issues. Here are my suggestions.

Browser compatibility strategies

When developing a CSS style page, it pays to test early and often in Internet Explorer and Netscape Navigator. Yes, I know this seems to contradict what I have been saying about making pages accessible to all, but I'm not saying to make your pages less accessible, only to ensure that the vast majority of your visitors today will have access. If you develop to the standards, then tomorrow's visitors will have access, so long as their browsers support the standards properly.

So test early and test often. There are several potential problems, which I cover below, along with their possible causes, and various solutions.

Problem 1: something "works" in one browser and not the other

There are several potential causes.

cause 1

Your HTML is not valid, or your CSS syntax is incorrect. This will particularly be the case when Internet Explorer "works" while Netscape Navigator does not.

solution 1
  1. Validate your HTML. Read this for instructions on how
  2. Check the syntax of your style sheet. Read this for instructions on how
  3. Use a CSS editor which ensures your CSS is correct from the outset. I develop Style Master, which will help you no end. Its available for both Mac and Windows.
cause 2

This CSS property or selector is not supported by a particular browser.

solution 2

Use a browser compatibility guide to determine whether the browser supports the property or feature you want to use. Remember, many properties won't be supported at all. If you need one of these to display your page correctly, then your design is probably flawed. You should not need a feature to display the content. If you want a feature, then its a little annoying when it isn't available, but its not the end of the world, is it?

Many properties and features (certain kinds of selectors for example) are buggy. Used in particular ways, they will work.

To find out about what is supported, what is buggy, and what isn't supported at all, see

To learn about workarounds for buggy features, see the CSS Pointers Group.

Also, my application Style Master has built in compatibility warnings for all the major browsers on Mac and Windows.

It shouldn't take more than a few seconds to determine whether something is supported or not.

If it is not supported, then there is nothing more to do. Sometimes there are really painful workarounds, but I would recommend against them. Spend your time on the valuable aspect of your site, its content, and don't waste it on something that is probably quite spurious. A simple example is the hover state. CSS2 introduced the selector A:hover. This is one of those "cool" aspects of style sheets people love. When a mouse is over a link, you can use it to change the appearance of the link. For now, it works in Internet Explorer, but not in Navigator. Developers are always asking for some Javascript workaround to provide the equivalent functionality when a page is viewed using Netscape. There are complicated Javascript solutions, but really, does it matter that much?

If a feature is supported in a buggy fashion, then there may be a workaround for the problem. Check out the CSS Pointers Group if the guides listed above don't have a solution for you.

Problem 2: A browser crashes

Browsers can and do crash when they come across certain pieces of CSS code. Its not particularly common, but it is a possibility. An example is Netscape 4 for the Macintosh, which does not like the long-hand border properties like border-width. The biggest hurdle is locating the cause of the crash.

Step one is to determine whether CSS is the problem.

Remove the style sheet and then reload the page. If it doesn't crash with the style sheet removed, then its a good bet that its the style sheet.

Now, we need to ensure that the style sheet has correct syntax. To do this, see this article.

Once we know that the style sheet is syntactically correct, we want to determine which rule is causing the crash. We'll need to have the style sheet as part of the page, so relink to it, or embed it again. Now, to locate the problem repeat the following steps until you locate the offending rule

  1. divide the style sheet in half
  2. load the page
  3. if the crash persists, the problem is in the half which was loaded, otherwise it is in the other half
  4. repeat from step one with the half of the style sheet which caused the crash

Once you have located the offending rule, you'll need to consult the Guides listed above to determine whether it is buggy, and whether there is a work around.

Problem 3: Something works poorly in one of the browsers

This is similar to the problem of a feature not working in a particular browser. Again we need to determine whether the feature has buggy support in the particular browser, and if so, whether there is a workaround. The Guides are again your valuable friend. Use them.

A common example of this is the background-color property in Netscape. Netscape does not fill the entire box of an element with the background color, it only colors behind the content of the element. But, there is a workaround, involving borders, which you can learn about using the compatibility guides I've mentioned.

Get To Grips

Basic misconceptions of what style sheets are about, as well as these browser shortcomings are the most common causes of frustration when working with style sheets, and the reasons why many developers give up on getting to grips with style sheets. I hope this article will give you strategies for dealing with these issues, and helps you master style sheets.

More Reading

I've written quite a bit on style sheets over the last couple of years. If you'd like to read more, check out the following:

Everything you ever wanted to know about style. Covers all of CSS1 and CSS2, in detail, but in a user friendly way.

A hands-on style sheets tutorial. 10 lessons which cover all of the basics of style sheets in a practical way.

Browser Compatibility Guide. They are all here, including Opera 3.5 and pre release versions of Netscape 6. More on the way.

Read more of my thoughts on browser compatibility here.

Web pages aren't made of paper. My original thoughts on developing adaptable and accessible web pages.

A number of CSS tutorials, on things like positioning, along with other quick CSS tutorials by my partner, Maxine Sherrin.

Other Resources

We have a tonne of links to valuable CSS resources here.

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.

Read more westciv articles