Skip to content

CSS Systems

Natalie Downe of Clearleft has written a very useful presentation entitled CSS Systems, or, “Writing Maintainable CSS”. These are principles and patterns for writing HTML and CSS that makes it easier to hand over to other people to maintain, and generally more robust. It’s very relevant for agencies like us, and I was pleased to find that the system we developed internally (documented on the company wiki) correspond with hers about 99%. This blog post consists of comments, additions, qualifications, agreements and occasional disagreements with her presentation.


Firstly, I owe her big time for the recommendation (p.20) of CSS Edit, a Mac-only application that came as the answer to my prayers. I don’t need any of its WYSIWYG capabilities or helpers, but finally having a CSS editor that can fold groups (demarcated by comments), and auto-complete properties paid for itself within a day.

Huge thanks too for reminding me of the IE-doubled-margin-float fix (p.69) — which I bookmarked over a year ago but promptly forgot. Remember: it never hurts to declare floats display:inline!

I liked her grouping scheme for structuring CSS files on p.18. Ours is a little different:

  1. Comment block: Title
  2. Comment block: List colour palette hex values, measurements, any dependent files e.g. reset.css
  3. General styles (e.g. links, headings, paragraphs, etc.)
  4. Base layout including grid
  5. Header styles
  6. Template-specific styles (layout1, layout2, etc.)
  7. Page-specific styles (with sub-sections for each page, e.g. homepage, product page, etc.)
  8. Module-specific styles (e.g. buttons, lists, tables, boxes, forms)
  9. Footer styles
  10. Skiplinks and invisible elements

I’m a little uncertain of her use of an overrides section at the end: it seems like it could easily get abused.
I also recommend a consistent CSS rule structure:

ELEMENT.class#id,
ELEMENT.class#id {
Layout declarations (position, float, clear, display, visibility,
etc.);
Box Model declarations (top, right, bottom, left, width,
height, margin, padding, border);
Background declarations;
Text declarations (font, color, line-height, text-transform,
text-decoration, text-align, etc.);
}

(In Firebug, if you Show Computed Style, you’ll see the same groupings with the relevant declarations under each)
I vociferously agree on:

  • Avoiding CSS frameworks (p.42)
  • Not splitting the CSS into multiple files like layout, colour, typography, etc. (p.45)
  • Not always using CSS shorthand (pp.51-53)
  • Having 3 CSS files: the base file, the all-IE version, and the IE <7 version, and never using hacks (p.22). The IE stylesheets should be very short (for a 3000 line base file, typically less than 200 lines)

I would also make the following recommendations:

  • Whenever a rule in the main CSS file is modified by rules in -ie.css or -ie56.css, note this in a comment. This is to ensure that when values are changed later, we remember to change them in both places.
  • Capitalisation and hyphenation
    • Always CAPITALISE elements, e.g. A, DIV, etc. This greatly improves what you can do with Search & Replace
    • Class and ID names are always lower-case and hyphenated (rather than CamelCase)
  • As with filenames, use reverse-naming convention (from least to most specific), e.g. .button-primary, .button-secondary, .nav-tier1, .article-intro, .article-body, etc. This greatly increases the readability of the CSS outline in an app like CSS Edit

Some qualifications:

  • Her advice to avoid excessive namespacing (pp.47-49) — using over-specific selectors if you don’t need to — is very sensible (I still occasionally fall foul of this.) I’d go further and also caution against using element selectors (such as her example on p.49 ul.products p.name) if you don’t need to: often you find the element changes later, or the class gets applied to a different element. For example, a .subheading might on some pages be an H2 and on others an H3; or an .icon-list might sometimes be in a UL and other times in an OL.
  • And in a related vein: careful of contextual element selectors (e.g. #news-items H3). They can seem elegant and efficient, but they can have unexpected side-effects as templates are added or changed. It often makes more sense to use class selectors instead (e.g. #news-items .news-title)
  • Abstracting one’s icons (p.65) by using a class and background images is sometimes a good idea, but the exceptions are more prevalent than she suggests:
    • As she points out, accessibility requires that images that carry meaning need to have alternate text. Unless your icons are entirely decorative, this is more often than you think
    • If you want your icons to appear on printouts (and this is also very often the case), then, again, you can’t use background images.
  • While I agree that floating is the only way for layouts, Natalie seems to dismiss absolute positioning a little easily (p.50). It is fantastically useful for all sorts of things and very reliable cross-browser once you’re familiar with it. Just don’t use it for the layout skeleton.
  • She skimmed over the heading level chestnut a bit quickly (pp.35-36). This is often under-valued and using the “Document Outline” tool on the Developer Toolbar should be as second-nature as validating. And that still leaves the age-old debate as to whether the site logo is an H1 or not, or whether there can be more than one H1 on the page. (My views: No, and Only on the homepage.)
  • I understand and trust the YUI reset.css enough to include it with all my CSS (p.18). I also like using the YUI fonts.css system
  • I agree with her comment to avoid the use of the word “template” (p.74) as it is so polluted and misunderstood. I’ve not been able to get away from it in practice, though. Sooner or later, it always gets used! I’m not sure whether “markup scheme” will carry the day.