CSS Organisation and Best Practices
At Lift we have been discussing our methods of organising and writing CSS for new project and future maintenance. It got me wondering how other people choose to manage their stylesheets.
After joining Lift I started to move us over to a system where you have 3 files (excluding reset and ie):
- layout.css - positioning, display, margins, paddings, etc.
- type.css - font-family/size/weight, line-height, text-decoration, lists, etc.
- color.css - background, color, borders, etc.
This increased our productivity as we could easily make specific changes that fell under each of the three categories. During a fresh build we could progressively style our documents by approaching the layout first, typography second and colour third (or any other order we wished!). I also recommended running each selectors attributes on one line, like so:
I believe this reads just fine with syntax highlighting and makes it much faster to skim through the files to find a specific selector. Another thing I do is remove the last semi-colon, as it is not needed.
Recently, we had a new member join the team, Kevin Carmody. As a developer working with me, we have been looking to improve our development practices, starting with front-end development. Kevin has happily adopted the practices we are currently using but is unsure of this 3 file split. After much discussion round the studio, it is agreed that it does have some drawbacks but other concepts we talked about also have their flaws.
- Single file - Everything is written in one massive file, but this means it is difficult to, for example, just look at colour related attributes.
- Single file, 3 lines - One file, but type, layout and color attributes are placed on separate lines. Testing this it revealed it looked like a wall of text that was hard to decipher and removed the single line rule that we have all grown fond of!
Another topic up for discussion was the organisation within the files themselves.
- Grouped by order in the document - Generic items are placed at the top, and then grouped by the order they occur in documents. Comments would not be used, however, as they do not seem to be needed when each "block" is separated by a blank line. This was the preferred method.
- Grouped by type - Form elements grouped, heading elements grouped, links grouped, and so on. The problem with this is where do elements that have multiple purposes in the content go? (for example, div).
In any method, we would like to use appropriate indentation of child elements for easier reading. Also, depending on the organisation and file separation, we find that there are levels of duplication, (for example) where elements have similar styles but are written in separate places, but this is not such an issue as some duplication is appropriate when moderated carefully.
My proposal at the end of this was to retain the 3 file set up but improve our grouping/ordering within the files to further improve readability. We're still thinking about it and are open to new ideas.
What about you? Please share your own practices in the comments or, if you want to go into great length about your methods, post them up on your blog and let me know!