Over the last couple of years, a whole collection of mature CSS frameworks have emerged, with the ambition of making CSS development faster, the rendering more predictable and the code easier to maintain. I’ve recently wanted to revisit some methodologies I use when it comes to maintaining CSS across a product line, and what better place to research CSS best practices and abstractions than the frameworks used by thousands of other people.
Every single CSS framework out there that I’ve looked at ships with a reset stylesheet. I think even the most framework-averse CSS artisans can find value in reseting the browser defaults and have all the elements start off on equal footing, regardless of browser. There are a couple of options for this, you can go with the industrial reset.css, courtesy of YUI, or with the local, organic variety, via Eric Meyer.
Font-sizing is another area that is hard to do “right”. Ideally, you want your fonts to scale when the user changes their browser’s font-size setting. Doing so means using relative units, which means lots of added complexity (i.e. arithmetic), and even then, consistent results across browsers aren’t guaranteed. There are a couple of schools of thoughts on text sizing, but I like to err on the side of Yahoo. If anything, they’ve put their YUI framework through a testing gauntlet, so you can be confident that their methodology will produce good results. You have to use percentages to set your font-size (easiest to reference their percentage → pixel translation table), but outside of that inconvenience, you get scalable font sizes virtually for free.
Neutering deprecated elements
I noticed Tripoli using this strategy. They take the likes of the <font> and the <center> tag and hinder their ability to affect the page style and layout. It’s a pretty interesting way to discourage their use and making bad habits a bit more toothless.
Setting good defaults for core elements
One of the most jarring things when you first switch to using a reset stylesheet is that writing simple, semantic markup no longer results in an intelligible document by default — all the headings, paragraphs and lists are the same size and so are the margins between the elements. You’ll feel like you’re doing a lot of extra work defining that which should be more implicit. Either way, if you’re far enough into a project, even if you didn’t use a reset stylesheet, you would probably have redefind those elements anyways , as the browser defaults aren’t good. Defining smart defaults on top of the reset stylesheet helps you save time redefining these basic elements, while establishing a more rigorous typographical system than the browser defaults could ever provide.
Concept of a template for basic layout
A lot of the frameworks use the concept of a template. You start off by marking-up your document with a pre-defined structure of common elements. For example, you’d add the header, navigation, content, primary-sidebar, secondary-sidebar and footer to your HTML. Once these pieces are in place, you can liberally change the layout from fluid to fixed, as well as change the order in which the sidebar and content elements display – all by adding one <div> around the common elements that specifies the template you’re using as a class.
There are many common interface patterns, but most don’t merit being included on every single page. Things like pagination and, arguably, form styles are great candidates for including individually on top of the core CSS framework. You would include these components only when you need them. There are a lot of good thoughts in this presentation from Yahoo’s Nicole Sullivan on how to best abstract site components in terms of structural markup and CSS classes. Particularly, pay attention to the concepts of “extending” components by adding classes, as well as “separating the container from the content”.
Bringing it all together
With all of this in mind, this is the list and order of all the CSS components that would be included to make up my ideal CSS workflow.