1/ Make sure all your elements inherit their typography from the Base Font.

You are laying out a page and decide to lay out a dictionary list. Great. Looking good, but when you test it in IE, it is the wrong font.  So you put in a CSS style to tell it the right font, right? No.  You’ll just get a different nasty surprise when you test it with Safari or Opera, or you subsequently change the overall text font.

You should, instead,  make sure that all the elements you’re using inherit their styles from their parent. This allows you to put all the fiddly style-stuff in the BODY tag, or the DIV container.  This means it is all easier to change when someone takes a dislike to the font, or the font settings you’ve chosen.

You can tell when a designer has been stung one too many times. They generally have the following ‘reset’ style. It is great for taking out quirks.

This means you can confidently set the basic font styles in just one place. You’ll probably pack in some more styles for your grand initial reset whilst you’re about it.

2/  To ensure cross-browser compatibility for a page design, reset the default settings to render the same

This is related closely to the previous item, but its aims are to make all the tags render in a consistent way across browsers. It is tempting to assume that every browser uses the same style for each tag. Sadly, there has never been any agreement between the browsers on how it should be done. Therefore, your  first part of your stylesheet ought to do this.

The best reset routine is by Eric Meyer, the CSS guru, though the most CSS frameworks have them too. (CSS frameworks are great to pull ideas and practices from. I like, and have used, the Azbuka CSS Typographical Base Rendering Library and the blueprint CSS Framework ). I’ve combined the ‘Inherit’ and ‘Reset’ definition into one for the sample stylesheet for this article, which you can download at the bottom of the article.

3/ Use the ‘semantic’ tag elements that the HTML standard provides rather than creating SPAN classes, where possible.

Tags should, where possible,  indicate the meaning of the textual information rather than merely to define its presentation (look).  The fewer purely ‘presentation’ tags that are there, the easier it is to alter the look of your site.  

So what are these tags? If text  has an address in it, use the <address> tag, if it is a long quotation, use <Blockquote>, if you have a dictionary-style list, use <dl>,<dd> and <dt>. If it is a heading, just don’t think of avoiding the use of <H1> to <H6>. If it is a list, however you want it to look, use <LI> along with <ol> or <UL>. Don’t think of using text outside <p> tags.  Where text within a paragraph needs to be enhanced, use the inline text tags such as <abbr> (an abbreviation or acronym) <cite> (yes, a citation), <code> (computer code), <dfn> (a definition) , <em>, <kbd>, <pre>, <samp> (sample computer code within text), <q>(a quote in text),  <small>, <strong> (important text) <del> (deleted),  <ins> (inserted)  and <var>.

Why? It is so that your text still works in old browsers or with text readers for blind people, to help provide other aids for people with sight problems, to give useful information to browsers, spell checkers, translation systems and search-engine indexers. They usually take fewer keystrokes too. An example of a useful semantic tag  is the old <abbr> tag that has a TITLE attribute which works on all browsers. If you add something like this to your stylesheet, you’ll get tooltips on your abbreviations or acronyms…

I’ve done this with the CSS acronym in this article just to illustrate what happens. There is a limit to what you can do purely with these semantic tags. When you reach this limit, then you have <SPAN> and <DIV>, the great general-purpose inline and block structural elements. They are only structural if you assign classes to them that will tell anyone maintaining the page what they mean. It is possible to use nothing else, but I wouldn’t advise it!

the <DIV> is a great way of dividing your text into semantic blocks. Because you can define a class that apply only to elements that are nested within another element of a particular class, you can completely redefine the way that a tag works within another element such as a DIV. For example, the code blocks in this article are done very simply just by defining a code class. Then we redefine the way that the <P> tag works inside any element with that class assigned to it. So here is the CSS code that does it, rendered by itself!

This means that, by nesting areas in DIVs, or changing the attributes of other block elements such as DL, OL, or UL, you have precise control over the way that any of the semantic tags are rendered, in any part of your page, and it is all relatively easy to modify when someone requires that you change the appearance of the site. 

4/ Elements can take more than one class.

You can assign a whole space-delimited list of classes to an element. Like good designers, we make SPANs for any inline strings within a paragraph block that need to be enhanced in a particular way.  It sounds daft, but few examples point out that, unlike Microsoft Word,  you can have as many classes defined for a tag, and the browser  does its best with the space-delimited list. DIVs of a number of different types need to be indented. So do other block elements. You only need one .indented class and just add it to the block elements that you need to indent, even if they already have a class assigned to them. Be economical. There’s no need to create lots of classes. Just keep as many as you can remember.

5/ Think in terms of generic classes where possible before using  element-specific  classes.

Many classes that are designed for block elements such as <DIV>s can apply to a range of  other types of block elements. The same applies to inline elements.  If you define a generic class, you’ll often find they can be easily recycled for different circumstances without you having to define another class. To assign a class to a particular tag can tie you down unnecessarily.

6/ Stick to a particular capitalisation for your class names.

Yes, different doctypes have different defaults for the case-sensitivity of the CSS classes. Your  code will work in one page, but not in another. Best do your testing in a doctype that is case-sensitive.

7/ When you’re rapidly designing CSS, use inline style blocks

When you have the perfect stylesheet, then it is time to deploy it to the whole site by putting it in a file and linking to it as an external stylesheet. Before then, when you’re actively working on it, use inline stylesheets. I find it easiest to work on a small sample, using an inline style-sheet, using TopStyle CSS Editor, until I’ve nailed a style down. While you are fighting with a recalcitrant bit of CSS that simply refuses to play ball in all the main browsers, then a small sample, and an inline style with a good CSS editor, and the odds are then on your side.

The problem I’ve found in development work when you are l linking to an external stylesheet is that when you make changes to the stylesheet and you want to see what happens it can get cached on the server side or on the browser. This can slow things down. When you’re finished making changes, then update the CSS file and you’re done!

8/ Use lists for anything that looks like a list. Remember that you don’t need them bullets.

It is easy to forget that you can change the style of a list in a number of different ways.  Lists can run across the page

• One
• Two
• Three
• Four
• Five
• Six

or down the page.—

• One
• Two
• Three
• Four
• Five
• Six

… and they don’t need to be bulleted or numbered either.  You can even get the effect of a menu system purely with lists.  There are great sites with a range of ideas for lists. Try out Listamatic, for example. It is very tempting to start using fancy HTML or tables when all you need is a good list, with the right styles

9/ Attach a style to an ID rather than a tag if you intend a style to work with just a particular element in the DOM.

If you need to make sure that a particular style can only be applied to a single element, then you can define a style using a # prefix. This attaches the style to the element with that particular ID. I feel that this is occasionally rather overdone, but it is a good way of flagging to anyone who is inspecting your stylesheet that this is definitely your intention.

10/ Encourage a feeling of guilt and self-loathing  when you use a table as a structural element to locate the layout in the right place. It is supposed to be for tables.

We are some way yet before we can separate the structure of text from its presentation, but the use of nested tables for laying out the page should be a last resort.   I used to think that this was just the ravings of blokes in sandals. The problems become apparent if you need to make changes to a page that has a large number of nested tables to arrange the content.  Page elements  start leaping around the page like spring bunnies. Tables will do things that are difficult to do with CSS, but CSS allows you to do things you can only dream of when in your ‘Table-phase’  of designing web-pages.

11/ Relative and absolute positioning represent powerful magic.

A lot of grief and fiddling with tables can be saved by using absolute positioning for elements that are placed within a containing block element. Let’s imagine you want to do something like this…