Friday 25 April 2008

Wrestling with CSS Frameworks

Say you're working on a project where you need to standardise your entire layout to a grid system, and you want your entire organisation to conform to this in a single way in code? Not easy. Everyone does their layout differently, but it looks the same! Why do this, why not code the same way to make things look the same. The best way, the right way.

Granted this doesn't work for decor, typography etc, but for layout it does. This is where some CSS Frameworks come it. The main ones being YUI Grids and Blueprint CSS.

On the face of it, they looks great - especially Yahoo's Grids Builder interface. Build a page in 8 clicks, copy paste the code. Done. How easy was that!

BUT. The world is never so rosy. What about semantics? Even back in 2006, Elliot Swan talked about how un-semantic the markup is when produced using these frameworks. The principle objection is that you have to have these ugly class names like "span-6 append-3 last" all over your beautiful document structure which relate not to the type of content, but purely to the layout. Not Cool.

Or is it? Here comes pragmatism v.s. purity again. In an ideal world, what we need in CSS is class-based inheritance. So you can define a class like "menu", give it some decor code, and then tell it to inherit another class like 'span-6' which makes it fit your grid. How cool would that be. You could program your CSS just like an app. You'd never have to repeat yourself in CSS declarations, your markup could be clean, single-class-per-element, and semantic.

However, the world isn't like that. The only way to get an element to work like this it to give multiple classnames to an element -- OR -- manually build your site's css to match the grid based on your semantic classnames - meaning that just like we do now, we have to re-define the grid every time.

I'm not decided on this yet, but I'm leaning towards the pragmatism of ugly grid-based classnames ALONGSIDE nice semantic classnames too. Something like this... class="5cols menu" where '5cols' is your grid CSS, and 'menu' is obviously your semantic one.

Why do I think that? Well, layout is already implied by the position of the content in the DOM - or it should be in 90% of cases. This means that layout CSS, specifically grid and only grid layout CSS is already implied in the DOM, so why do you have to be semantic with it? Other CSS stuff like microlayouts (borders, padding), decor and typography CSS for example DO belong under semantic classname definitions.

Its a delecate balance between purity, and a pragmatic 'lets get things done' attitude. For the latter, CSS Grid frameworks make a lot of sense. However, when used carefully, they can live alongside pure semantic markup.

At least this is the best we can do until css inheritance comes along -- which'll be never.

Want another opinion? Have a read of Nate Koechley.

No comments: