Terris Kremer / Posted 8.7.2012
When I create stylesheets for a webpage, I usually have three goals in mind:
- Separate layout and aesthetics from the content.
- Keep CSS lean by identifying reusable styles.
- Create HTML/CSS patterns that anyone – developer, designer, content creator, or client – can understand and use without much guidance.
In practice, these three goals can sometimes conflict. My CSS could be lightweight, but my patterns might be too complicated or rely too much on context. Or perhaps I’ve created stylesets whose functions are perfectly clear, but I had to use the same attributes over and over – making it a bit more complicated than I’d like.
Over time I’ve developed (read: borrowed) a method that helps keep my goals all playing for the same team. I call it the elements palette: a one-page reference of all the modules, grid patterns, blocks, trinkets, sprockets and gizmos that will be used in a website’s design.
The documentation for Twitter Bootstrap is a perfect example of an elements palette.
Before I start writing markup and styles for individual pages, I start my elements palette by first trying to forget about the layout as a whole, and instead start breaking down each element, or group of elements, into separate parts.
It’s helpful to organize each module by function, common elements or styles. The sidebar, for instance, might be made up of several very different modules – yet each module might also have something in common with other modules, like the size or color of the title.
Once I’ve identified the unique elements and the patterns in the design, I can start building out each piece separately. As part of the process, I can also take notes on how each “part” is put together with CSS and HTML. Voila! It’s also a little thing called documentation.
By separating out each module, I can be sure that they will work regardless of context. For example, if I want to place the same sidebar module in the footer, it should adapt to its new context without problems. Using an elements palette means that I’m building the module separate from any other element and without context, chances are greater that it will work well no matter where I place it.
Having all my modules on one page also helps me visually identify patterns. If for example, I find that three of my modules have red title text set at 18 pixels, I can slim down my code and make those modules more flexible by taking out the title styles that are specific to each module and build a new combined style set that only renders 18-pixel, red text.
When I’m finished, I’ll have a CSS/HTML pattern guide that anyone can use to duplicate elements on a page. Since I’ve created each element separately and without context, I’ll be able to drop my modules anywhere in the page that the design calls for without worrying about them breaking. Best of all, it keeps my stylesheet lightweight by identifying patterns and creating new style sets to handle them all.
Want to read more about creating element palettes? Here are a few great links that will help you think like an element palette master:
- Sweet Systems - http://cognition.happycog.com/article/sweet-systems
- Nicole Sullivan on OOCSS http://www.stubbornella.org/content/category/general/geek/css/oocss-css-geek-general/
- Twitter Bootstrap - http://twitter.github.com/bootstrap/
Front-end developer at Q Digital Studio
Terris Kremer is a front-end developer at Q Digital Studio. While he may joke that both front- and back-end developers are dweebs, Terris really does make development look cool. For Terris, work is a game that he can (and does) play all day long.