Semantically speaking: Why CSS frameworks make sense

Cross-posted from the New Internationalist Tech blog

After a good banter back-and-forth with my colleague here on the New Internationalist Web Team about CSS frameworks, I thought it would be helpful to jot down the key themes of the debate and possible solutions. Hopefully this will benefit other teams that are managing large collections of inter-linked sites that evolve over long periods of time.

Many of the leading minds of the “semantic Web” movement, like Jeffrey Zeldman and Andy Clarke (full disclosure: Andy is leading the upcoming New Internationalist online re-design), have recently compared CSS frameworks like Blueprint CSS to Dreamweaver. For those Web producers that develop skillfully handcrafted sites, tools like Dreamweaver are akin to training wheels on a bike, or a “colouring between the lines.”

That is argument number one against CSS frameworks: they are too prescriptive in their approach, and limit creativity.

The second argument is that they are not purely “semantic,” that is that their markup contains both semantic class names, and names that are purely for presentation or layout purposes.

I think that both of these arguments are mostly (cough) malarkey, and only serve to divert the debate from where it should really be: manageability (And this is an area that really needs some creative, and innovative, thinking).

There’s no point re-hashing the semantic debate here; put simply: it is possible to use a CSS framework and strictly semantic markup. The supposedly “messy” presentational class names can be removed once the initial layout work is complete. Presto: no more problem, semantically speaking.

As for creativity: I find it hard to imagine that any experienced Web producer these days wouldn’t have some “sensible defaults,” or templates, to work from in Illustrator, Photoshop, or – more precisely – for developing HTML and CSS. And I don’t see how CSS frameworks offer anything more (or more constraining) than that, when it comes to discussing grids, typography, and forms.

Where I do feel there is a strong argument in favour of frameworks is in the benefits they provide toward long-term manageability of those pesky, constantly growing and changing, cascading style sheets.

Jeff Croft – one of the idea innovators around the concept of a CSS framework – explains the benefits of a CSS framework like so:

When I work at the Journal-World, it was common for me to be expected to create complex grid-based layouts for a story or special section in a matter of an hour or two. These needed to work in many browsers, including IE6 and lower. It was simply unpractical for me to build these from scratch every time — I just didn’t have the time for it. By coming up with a set of classes that could be reused, I was able to achieve this kind of speed.

If you’re not intimately familiar with Blueprint CSS (and possibly other frameworks like YUI, etc.), you’ll probably skim right over some of the work that’s been done to address the needs of people managing large, or multiple, sites that go through frequent design and layout iterations to meet ever-expanding (and unplanned for) needs.

Many of these frameworks provide tools to configure your “core” CSS and deploy it to multiple sites, and to do so with site-specific settings and overrides. This configurability makes it possible to keep the “core” of the CSS – the part that specifies sensible defaults, typography, browser compatibility, basic print and form styles, etc. – to be managed centrally, deployed, and updated as one would other types of Web application code. Some of these frameworks also offer validation and testing tools – the kind of tools that have been available to software developers for what seems like ages now.

Finally, software application development processes applied to Web site structure and design! It’s a Web site manager’s dream come true.

The advantages here often present themselves after most Web designers have handed over their HTML and CSS to various teams for implementation. In the case of the New Internationalist, there will be separate teams that manage the development of the online stores and the main NI sites, like the blog and microsites like Clean Start campaign. Each of these teams will likely have to implement some of their own – site-specific – changes to the HTML and CSS to deal with the various bits and bobs that come up during the implementation of a design, or development of a Web application.

In this scenario, CSS frameworks offer modularity: keeping the core maintainable, while providing a way for specific site developers to introduce their own site-specific overrides. Going a step further, they offer the option of rolling those site-specific customizations back into the core CSS file (for that specific site) at a later date. One less HTTP request and we can all sleep at night.

So, all semantic and creative arguments aside, what frameworks provide that appeals to me is some of the same – somewhat software-development-centric – tools and processes that I’ve come to appreciate over the years.

If you manage a large site, or – as is the case for New Internationalist – a large collection of sites with ever more on the horizon, I think you’ll find an exploration of the CSS frameworks useful too. One that I’ll be keeping an eye on (thanks to Adam for the reminder) is Compass, which promises “maintainable, semantic CSS.”

P.S. I should note that – in the middle of writing this post – Andy Clarke, Adam, and I had a great conversation about these questions and Andy presented some solid recommendations for addressing the maintainability and manageability questions head on. I look forward to seeing what we come up with and blogging about the results.

Comments? Please post them on the New Internationalist Tech blog