Maintainable CSS
Natalie Down has put up slides for what looked like an interesting presentation on writing maintainable CSS. This is one of those topics that rarely gets much attention, so it's nice to see some suggested good practices, particularly for stylesheet structure and layout. She also has some good tips on CSS implementations in general.
The biggest problem I've found when maintaining CSS is that when you come back to a site some time after the initial implementation (or if you're maintaining some code written by someone else), it's usually easiest to add new styles to the end of the existing stylesheet instead of reminding yourself how it all fits together, and then putting the new styles in the correct place. This gradually leads to bloat, as you end up putting in overrides for rules you've defined elsewhere, and then the next time it becomes overrides for your overrides, and so on. Grouping your rules as Natalie suggests is the only real solution to this, as it forces you to insert your code at the appropriate place, which in turn encourages to you edit what is already there instead of adding to it.
Some other random notes on the slides:
It's interesting seeing other developers' approaches to design implementation. After some basic planning I tend to start chopping straight from an actual-size mockup provided by the designer, the aim being to end up with as close a representation of this graphic as possible.
Perhaps I'm interpreting it incorrectly, but "the grid" is not a phrase I'm particular fond of in this context - elements of a design rarely translate perfectly to a grid-type layout, and even slight changes in the spacing between elements (in order to conform to your grid) will usually result in some pretty negative feedback from the designer.
I tend to think of layouts more as collections of boxes. E.g. if this site had been designer by a proper designer (obviously it hasn't) and they'd sent you this layout as a graphic, by looking at it you'd put mental boxes around distinct elements such as the right sidebar, navigation and main content area. These then translate directly to semantically named divs in your layout. For more complex layouts, it can help to use the draggable line guides most graphic programs provide in order to work out exactly what lines up with what.
Regarding CSS frameworks, it's nice to see someone speak out against these. We've been experimenting with Blueprint a bit at work and I haven't been too impressed so far.
On the plus side I can see the attraction of something that resets browser defaults to a common baseline (particularly to people who've been stuck by browser inconsistency issues before), and I think grid-style layouts are a little easier for people to get their head round than floats and clears. But to me the negatives far outweigh these advantages:
- You're adding a layer of overhead to your site - every user has to download all that additional CSS code, plus (generally) slightly larger HTML files
- These frameworks steer you away from good markup, as your classes end up being presentational ("span-36 last") rather than semantic ("navigation").
- You're setting yourself up for maintainability problems (as Natalie mentions), as you're starting off with a whole load of CSS code that was written by someone else, making the site more difficult to debug when you hit problems.
CSS frameworks haven't gained too much adoption as yet, so hopefully as the older, buggiest versions of IE continue to slowly lose market share, the demand for them will gradually disappear.
Tags:
Add Comment