18 January 2008

Structured CSS

One of the most challenging aspects of starting a new project is deciding how to structure the CSS. Often, not all the designs are complete, and sometimes very few are done and things are not signed off etc. Therefore it is always important to have a structure which allows for quick and easy changes and even the retrospective coding of a style guide into the CSS.

I am personally not a fan of CSS resets such as Eric Meyer's but I do like to have flexibility and structure in my work.

Whilst I get some arguments from colleagues about my approach, those who work on projects with me have so far not had cause for complaint and have commented that my approach seems to work. The crux of it is that I like to do the majority of the CSS work up-front and do as little as possible as more and more pages are added into the site.

I still subscribe to the global reset:

* {

margin: 0;

padding: 0;

}


I then like to set all the defaults from scratch on the core elements: headers, tables, anchors, paragraphs, lists etc.

My other practice which causes discussion is my file structure. There are different ways of organising CSS files and some people like to take the one file approach where everything is put into one massive file. I cannot abide this approach - how can you find anything!? The answer is often that good commenting helps, but I don't think developers are very good at commenting well!

My other issue with the single CSS file is that for every page the user has to download every line of CSS and in a rich website, there can be a lot!

I prefer to separate the basic CSS into the following files:

global.css
All global styles including my mini-reset as above, basic styles for the common tags (lists, tables etc). Styling for global site elements.

typography.css
Basic typography styles - paragraphs, headers and text colouring for different elements. Anchor styles as well including hover styles etc.

forms.css
Basic form styling. I always insist upon forms looking very similar across the website so I can style them once.

navigation.css
All global navigation styles typically including primary and secondary navigation (tertiary if it is applicable), footer styles, any in page tabbed navigation etc

ie.css
Included for all IE versions 7 and lower through conditional comments.

ie6.css
Included for all IE versions 6 and lower through conditional comments.

Each of the above files would be included on every page of the website. I would then create further style sheets by section or template or functional usage depending on the website. I would normally not create a style sheet per page or per module, but I do normally create additional special style sheets for the website home page and for search results if it is different enough.

Within my style sheets I try and implement rules such that each section of CSS is commented eg:

/* Inbox styles */

table#Inbox {

....

}

....


I like to have the styles in a sensible order which is normally the same as the markup order. So styling for elements which are children of or appear after the table with ID Inbox would appear later in the CSS file.

And that's it. No magic, nothing too special, just a structure borne out of experience and specifically the experiencing of managing badly written CSS.

CSS is not easy, but a good approach can at least make it simple.

One special note - consistency of approach to CSS on a project is absolutely key until some decent development tools come along.

2 comments:

neilp said...

Some very sensible points there. In addition, i find that in projects which are liable to change in design and or scope, it is essential that you give most HTML templates body classes and or id's to provide extra flexibility.

marcus said...

I'm actually increasingly against global reset rules these days.

Personally I believe that text elements (headings, paragraphs, lists, etc), if not restyled, should always have default margin and padding styles. The default (browser) styles have been designed so text content is rendered well - it's better to tweak those than try and rebuild them from scratch. I find it easier to work with, and more robust.

For lists, for example, it's much easier to remove the bullets/margin/padding in situations where you don't want them (eg. navigation) than put them back in again for body text areas (where styling may well not be necessary, or may be minimal).

That's just how I feel about it, anyway. I've never worked in a situation where a global reset made my life better, but I have worked in a situation where a global reset made my life worse.