Top 10 CSS Authoring Tips
by Eric A. Meyer
05/01/2000
1) Validate your code--both CSS and HTML. Even
the most seasoned Web authors can make mistakes with their styles,
and one of the fastest ways to mangle styles is to have badly
malformed HTML. You should make sure both are clean and free of
errors. There are two main sources for validation: the
W3C and the
Web Design Group.
The latter offers validators with vaguely friendly error messages, so it's
a good place to start. Look under "Tools" for the
HTML Validator and
CSScheck. By making sure your code passes the validator, you can
avoid the need to memorize many of the tips in this list.
2) You can't have total control over the page. CSS
allows authors (and readers) to make suggestions about how a page
should be presented. It is not a pixel-precise way to
ensure that every person sees the page in exactly the same way. Nor
could it be: How can you make a palmtop computer display a page the
same as it appears on a flatscreen monitor forty inches wide? Given the
incredibly wide range of browsing environments, it simply isn't
possible to ensure total consistency in page appearance. CSS permits
you to make suggestions--strong ones, perhaps, but still
suggestions.
3) Avoid changing the default (BODY) font size. It
stands to reason that a user will set their browser to display text
in a size which is most comfortable for them. If you change the
default size, you are by definition making your page less comfortable
for everyone to read. You can certainly make some text bigger or
smaller than "ordinary" text (headings and footnotes are examples)
but the majority of text should not be sized by the author. If you
feel you absolutely must change the default size for some
reason, then use ems or percentages to do it.
4) Make sure you use units, and that they aren't
separated. A common mistake is to write something like
this:
H1 {font-size: 2 em;}
IMG.exam {width: 200;}
The first line is wrong because the unit and the number are separated
by a space. There should never be a space between the
number and its unit. The second line is a little more subtle. The
assumption is that the image should be 200 pixels wide, but how do
you know? It could be 200 centimeters, or furlongs, or parsecs, or
angstroms. The problem is compounded by the fact that some browsers
interpret numbers without units as being pixels, while others rightly
ignore these numbers. So you'll want to do something more like this:
H1 {font-size: 2em;}
IMG.exam {width: 200px;}
5) Specific styles always override inherited styles. It's
possible to set a color for the entire document like this:
BODY {color: red;}
However, this will not carry over to things like hyperlinks. Why
not? Because of the browser's style rule of
A:link {color: blue;}
(assuming the browser is set to color links blue).
Since there is a rule which explicitly assigns a color to hyperlinks,
it overrides the inherited color red. One of the most
common authorial errors is to forget this fact, and wonder why their
styles aren't being inherited. It's also something that validators
won't catch, because nothing is wrong--it's just not quite what the
author really wants.
6) Shorthand properties can obliterate previous
styles. It's not uncommon to try to do something like this:
H1 {background-image: url(bg42.gif);}
H1, H2, H3 {background: yellow;}
You might expect that H1 elements would have a yellow background over
which an image is tiled (assume the image has transparent bits so that
the yellow would be visible). This is not the case. The declaration
background: yellow will cause the unspecified values
(for background image, background position, background repeat, and
background attachment) to revert to their defaults. Since the
default value for a background image is none,
there will be no image in the background of H1 elements. On the other hand,
you can reverse the rules:
H1, H2, H3 {background: yellow;}
H1 {background-image: url(bg42.gif);}
This will work as expected, with the image being tiled over the
yellow background. That's because the default image value of
noneassigned in the first rule will be overridden by
the value in the second rule.
7) Borders without style don't exist. Since the
default border-style is none, if you don't explicitly
declare a border-style for a border then it will have no existence at
all, and therefore zero width. After all, something can have width
only if it exists. If you want extra space to appear around an
element such as an image, use margins, not a border width.
8) Be careful with color. It is often recommended
that any color assignment should be accompanied by a background color
assignment. Consider that a user may have a personal stylesheet
which sets pages to be displayed as yellow text on a black
background. Now assume that you declare the following styles for
your page:
BODY {color: black;}
It is now possible that some (or all) or your page will feature black
text on a black background. This makes it somewhat difficult to
read. You'd be better off doing one of two things: either make sure
you include a background color to go with that foreground color, or
try not to mess with the colors at all. Remember that users set
their browsers to the display which is most comfortable for them.
That includes color combinations as well as font sizes.
9) Navigator 4 requires Javascript to display CSS.
In the early days of Web-specific stylesheet proposals, Netscape
advanced an idea called Javascript Stylesheets (JSSS), which was
similar to CSS but had deep ties into Javascript. This was
implemented in Navigator 4 to some extent. Unfortunately, one side
effect is that disabling Javascript also disables stylesheets.
Mozilla and the Netscape 6 preview releases do not suffer
from this problem, nor do browsers provided by other companies.
10) Validate your code. It can't be said often
enough, really. Running your HTML and CSS through validators will
quickly teach you a lot about good authoring practices. There is no
faster way to learn than to experiment a lot, and pay heed to the
validator warnings you get.
Eric A. Meyer
is a member of the CSS&FP Working Group and the author
of Cascading Style Sheets: The Definitive Guide.
Return to .NET DevCenter