Writing CSS1 style sheets
A short guide

The aim of this guide is to show, with examples, the principles you should follow when writing style sheets, so as to not risk your documents hard or impossible to read for some users.

List of contents

This guide is not intended to give a complete overview of all the features in style sheets, the W3C has the authoritative specification, and at the WDG is a guide to Cascading Style Sheets you can find much useful information. Nor will it deal with how existing browsers render, or fail to render, documents with style sheets.

The article Effective Use of Style Sheets is written by an expert on usability, so reading it before implementing style sheets is strongly recommended.

I'm not an expert, but I've tried to write down the things I'd liked to have available, in addition to the existing resources, when I started using style sheets (it might have been and may be now, but when I started writing this I hadn't found it). If it had been, I'd have been spared a lot of problems and embarrasement with badly written style sheets.

List of contents

Why I like style sheets

To sum it up in one sentence: Style sheets separate content from presentation. Or to put another way: "If you lie to web clients, they will get their revenge".

For example, headers should always be marked up as headers and not as "large text", if you use DL for anything but definition lists, some browsers and users will be, at least, confused. With style sheets, you can separately from the content suggest how it should be rendered, which is why I hope and think it will encourage authors to correctly mark up their documents.

I'm not alone in thinking style sheets is the right way to effect presentation, see for example Best viewed with...CSS1 and Style Sheet Demo Page for an example of what can be done with them.

Is nothing wrong with style sheets?

Yes, unfortunately there are problems with the style sheet specification. For example, I don't like that author specified important properties takes precedence over those deemed important by the user. The the normal order of precedence is authors' rules first is natural, as the author is the one who knows which elements are present in a document, and therefore can specify them all.

Nor do I much appreciate that it's possible with "hacks" to create documents that are dependent on style sheet support in order to be readable at all. Hopefully this will never become popular.

Additionally, it's too easy to by mistake create documents which will render unexpectedly, sometimes hiding information, depending on browser settings, especially personal style sheets.

For example, for you a document may render in the way you expect, because elements inherit properties, but a user may have a personal style sheet which goes into greater detail than yours, so you may set a property for H3 and expect H3 STRONG to look similar, but a user may have set properties for both H3 and H3 STRONG, which clashes with your suggestions. Yes, one might assume the user has done so on purpose and understand what's happening, but not that she is likely to see documents without any author style sheets or those with properties for both H3 and H3 STRONG in a more pleasing way.

Some people think style sheets are inherently harmful and while not agreeing wholly, I do agree that by using some features the readability of documents may decrease, so you should be aware of the potential problems before implementing style sheets, so read that document!

Some things to do, and not to do

Most advice here is equally valid both for authors' style sheets and personal style sheets.

(You will need style sheet support so see how the examples are rendered. What looks like links in the examples, isn't.)

Don't build in style sheet dependence

One thing you must always keep in mind, is that you must never write a document which relies on its style. It must always be useable without your styles, or with any other valid style sheet.

Another way to say this is that the styles must never say what something is, only how it looks!

So, for example headers should always be marked up as headers, not something else.

For example, this style sheet declaration
H5 { color: Maroon; background: White; font-size: 140%; font-family: Arial, Verdana; }
together with this markup
<H5>This is a header</H5> This is some normal text.
will produce something like this

This is a header
This is some normal text.

A similar style sheet declaration, like this
.header1 { color: Maroon; background: White; font-size: 140%; font-family: Arial, Verdana;}
could be used together with markup like this
<DIV CLASS=header1>This may look like a header, but it isn't</DIV> This is also some normal text.
to produce a result like this

This may look like a header, but it isn't
This is also some normal text.
but only if used in conjunction with this specific style sheet declaration!

If the user uses no, or another style sheet, the two examples might look something like:

This is a header
This is some normal text.
This may look like a header, but it isn't
This is also some normal text.

What can go wrong with colours

One area where conflicts between browser settings, personal and author style sheets is very likely to result in (partly) unreadable documents is colours.

What you must do if you specify colours is:

Should you wish, you can set also set these colours with the <BODY> statement, but I don't encourage this.

Avoid setting colours in non-style sheet ways in the body of documents, with <FONT> and similar elements.

Consider this, rather dull, appearance (which incidently is close to the default settings on some browsers):

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph. Here follows two links, one visited and one unvisited link.

The author/user (no, it really doesn't matter which for this discussion, as the conflict can happen in either case) now wants to liven it up a bit, by making headers deep blue, and puts this into a style sheet:
H4 { color: Navy; }
with this being the expected result:

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph. Here follows two links, one visited and one unvisited link.

But suppose there's an author/user who prefers dark backgrounds, and has written a style sheet thus:
BODY, A:link, A:visited, A:active, { background: Navy; }
BODY { color: White; }
A:link { color: Yellow; }
A:visited { color: #FF7; }
A:active { color: Aqua; }
As you see, there's no H4 instruction, so if used together with the style sheet which has one, then that instruction will be used, and the document will be rendered thus:

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph. Here follows two links, one visited and one unvisited link.

Much the same thing will happen if you write style sheet instructions which relies on the browser's default settings to produce the desired effect.

This problem is not dependent on order of precendence, and thus cannot be countered by increasing the elements' importance, nor can it be countered by relying on inheritance, since if one party specifies properties for example for SMALL A:link EM, then it doesn't matter what the other party has specified for either SMALL, A:link or EM nor for SMALL A:link or SMALL EM and so on for that matter.

Had the first person taken care to specify a background also, like this: H4 { color: Navy; }
H4 {background: Silver; }

then the rendering would have become like this:

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph. Here follows two links, one visited and one unvisited link.

which perhaps isn't very good looking, but it is perfectly readable, which is the most important thing of all.

As an author, you know exactly which elements are present in a document, and if you give them all properties, this will not happen, as a user, you cannot know which elements documents will contain and it's practically impossible to specify them all, so you must be prepared for some behaviour like this.

What can go wrong with fonts

Any use of fonts entails a risk, because you cannot know if the user can read a certain font. One reason for that is that the same font name may mean different things on different systems, and thus give very unexpected renderings.

To decrease the risk, I think it's better to use short font lists, perhaps only a single font. This makes also makes sense if you want the font to match the font on any graphical elements and reduces the number of possible combinations in case you suggest different fonts for different elements.

I do not recommend the use of serif, sans-serif or monospace in style sheets because neither the author nor the user influences how it will be rendered, only the browser author, who certainly will know less about user preferences and the content of the document. If the suggested font is not available, the user set default font is most probably a better choice.

When suggesting one font for the element BODY, you had better suggest a font for the elements which should be rendered in a fixed spacing font, like TT and PRE, so they aren't rendered in a proportional font.

Choosing a DOCTYPE

If you don't plan on using CLASS, and only modify the look of elements themselves, then you can use HTML 3.2 and put the doctype declaration
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
into your document.

In case you wish to use CLASS, and put style on parts of the document based on that, you can either use a doctype for HTML 4.0:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Draft//EN">
or HTML 3.2 + Style, which is not going to become an official recommendation, but apart from HTML 4.0 is not under development, and will thus remain as it is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Experimental 970421//EN">

In either of these cases, you link to your external style sheets like this:
<LINK REL=STYLESHEET HREF="my_style_sheet.css">

and have them validated, either at The Kinder, Gentler Validator or Webtechs.

Stylistic and ergonomic considerations

I recommend that you never use more than two fonts, plus a fixed pitch font, per document. It's probably also a mostly good idea to limit the number of different colours and see to that they don't clash with each other.

The way you can write style sheets makes it easy to keep track of how many fonts and colours you've used, because you do not have to specify all properties for an element at the same place. My recommendation is that you instead group the elements by properties. This also makes it far easier to maintain a style sheet, as if you should wish to change a font or colour, you can do that in a single place. Very handy in case you want to change plain white to off-white beige, navy to a deeper blue or discover that a font name you've given refers to wildly different fonts on different systems.

To furthermore group the declarations by type, and separate the font declarations from the colour declarations, makes it easier to give them different levels of importance. Only the user can know which fonts are available on the system and which font sizes makes for comfortable reading, so for the user it makes sense to at least mark font size as important; Colour blind users need to mark their colour selections as important.

The downside to grouping by properties is of course that if you have a large and complex style sheet, it's not easy to see at a glance all properties for an element, which means you must take care whenever adding an element, especially to give it both a colour and background.

Some sample style sheets

Now, let's start with a simple style sheet, one which will only set the basic colours:
BODY, A:link, A:visited, A:active, { background: White; }
BODY { color: Black; }
A:link { color: Teal; }
A:visited { color: Blue; }
A:active { color: Red; }

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph. Here follows two links, one visited and one unvisited link.

In case you also wish to suggest some fonts, you can do like this:
BODY, A:link, A:visited, A:active, { background: White; font-family: Garamond, serif; }
H4 { font-family: Arial, sans-serif; }
PRE, TT { font-family: Courier, monospace; }
BODY { color: Black; }
A:link { color: Teal; }
A:visited { color: Blue; }
A:active { color: Red; }

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph. Here follows two links, one visited and one unvisited link.

This text is rendered in a fixed pitch font.

Note that I do not recommend the use of serif, sans-serif or monospace in style sheets font lists, because neither the author nor the user influences how it will be rendered, here I use it only to maximise the chance that you really will see a difference between the fonts above.

Perhaps you want centered headings and first line indentation of paragraphs, and wider margins in some paragraphs:
BODY, A:link, A:visited, A:active, { background: White; }
H4 { text-align: center; }
P { text-indent: 15%; }
P.margins { margin-left: 20%; margin-right: 20%; }
BODY { color: Black; }
A:link { color: Teal; }
A:visited { color: Blue; }
A:active { color: Red; }
results in approximately this appearance:

This is a header

This is normal text, the quick brown fox jumps over the lazy dog. The first line is supposed to be indented. The quick brown fox jumps over the lazy dog.

This paragraph has extra wide margins. That's been specified with <P CLASS=margins> in conjunction with the style sheet code above. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

The first line in this paragraphed is also indented. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

Perhaps you want to make some text really stand out:
BODY, A:link, A:visited, A:active, { background: White; }
BODY { color: Black; }
STRONG { color: Navy; background: Yellow; } A:link { color: Teal; }
A:visited { color: Blue; }
A:active { color: Red; }
results in approximately this appearance:

This is a header

This is normal text, the quick brown fox jumps over the lazy dog.

This is a new paragraph, with some words with strong emphasis. Here follows two links, one visited and one unvisited link.

I think this shows the general principles, for details, see the references at the top of the document.


Other web authoring subjects.

Last modified 1997 July 30 Urban Fredriksson

griffon@kuai.se

The URL of this document is http://www.alfaskop.net/%7Egriffon/web/writing_stylesheets.html