Cascading Style Sheets are one of those technologies that the web gets right; but actually getting a style-sheet right isn’t quite so easy.
Tinkering with Style Sheets
It’s all too easy to tinker with a style sheet:
- Install your browser’s Web Developer Extension.
- Load up the page you want to re-style into your browser.
- Hit Ctrl+Shift+E
- Edit away.
Your browser updates directly as you make the changes, nudging a margin here, tweaking a font there. When you like what you see, save a copy of the style sheet and install it.
There are a couple of problems with this WYSIWYG approach to hacking a style sheet.
Not all browsers interpret styling information in the same way. So what you see in Firefox may not be what you get in Safari. One defence against this is to make sure your CSS is valid. Web browsers are designed to do the best they can when subjected to “garbage in” but they’ll stand a better chance when given conformant content.
Every time I hack a style sheet in this way it seems like trying to balance a wobbly table. You saw a little off one of the legs. It still doesn’t balance. So you saw a little off another leg. It still doesn’t balance. Things aren’t going as planned but you’re not going to give up now. A little more sawing …
You end up with a low table. And it still wobbles.
The analogy isn’t perfect — you tend to add things to style sheets rather than saw things off them — but this only compounds the problem.
Why fuss about style?
I appreciate that style has a shorter shelf-life than content: what looks good today seems faded tomorrow and will be positively dated by next year. Perhaps the best thing about CSS, though, is that it cleanly separates presentation from content, meaning that we can change our style sheet next year if we want.
I am not a Web Designer. But …
I can’t claim any great expertise in this area. I’ve never written a style sheet from scratch, only adapted ones which I liked. Pretty much everything I know about CSS comes from examining style sheets which work well. That said, it seems to me that there are some general software design principles which apply equally to style sheets.
Simplicity. Minimise the number of fonts; reduce the colour palette; aim for clean lines. A simple style is likely to look good for longer.
Consistency. CSS allows you to over-ride styles at every level — I think that’s what the “cascade” is. Usually, though, a consistent style should be preferred.
Prototype. A WYSIWYG editor is very tempting for something as visual as a web page but it suffers from the drawbacks I’ve already mentioned. Why not prototype using something as quick and direct as pencil and paper?
Test. It’s possible to automate the validation of your web site. It’s possible to spider your web site and play back a sample of pages in the browsers you want to support. So do it!
Modularity. Keep logically separate parts of the style sheet separate. The designer of Scribbish (which is the theme I’m using for this blog) clearly knew what he was doing when he created separate style-sheets for page layout, content, and syntax-highlighting.
Use Version Control. When you realise you’ve made your table more wobbly, wind it back to a previous revision.
Consult an expert. I am not an expert on web design. Maintaining a personal web site is one thing, but if I had to design a new site from scratch, I’d look for expert help.
If anyone can improve the syntax highlighting stylesheet, please let me know. No, I don't like the Scribbish defaults!