Several years ago I wrote a blog entry entitled YUI Stylesheets are Awesome! I stand by their original awesomeness in saving me from the perils of IE6 hell, but this tradeoff is ugly. In using a grid system with positional CSS, you lose all the semantic meaning CSS can bring. The short term gain, in practice, just led to other long term maintenance problems. There is a better solution, and I want to show it to you.
There are a lot of these frameworks now - YUI, Blueprint, 960gs, and umpteen others that follow the same basic ideas. These CSS Frameworks are all about positioning... splitting the page up into a number of columns and letting you lay out <div>s on the page. As a newcomer to CSS they get you up and running fast, but miss a much bigger picture. In the end, they are nothing but ways of 'tricking' CSS into acting more like tables than semantic markup.
Semantic Markup? You Keep Saying That...
Lets figure that out by looking at the role of the HTML writer.
Imagine I'm writing a website for a new coffee shop. I'm going to design the page for the menu. Like most menus, items are grouped according to types. Maybe "Hot Drinks", "Cold Drinks", "Desserts and Pastries", "Sandwiches", and so on. That HTML writer, using a CSS framework that is all about positioning, might have a page structure that looks like this (any html tags beyond structure are omitted for clarity):
<div class="columns_12" id=menu"> <div class="columns_6 alpha" id="hot_drinks"> </div> <div class="columns_6 omega" id="cold_drinks"> </div> <div class="columns_10 alpha" id="deserts_n_pastries"> </div> <div class="columns_2 omega" id="dessert_pic_holder"> </div> <div class="columns_2 alpha" id="sandwich_pic_holder"> </div> <div class="columns_10 omega" id="sandwiches"> </div> </div>
So we have IDs that represent the real content, but the classes denote something about the positioning within the page. In this case we have a 12 column container named 'menu', and that contains a series of divs that all add up to 12 columns, with 'alpha' indicating it is the first, and 'omega' indicating it is the last. For the most part, minus some bells and whistles, this is how these stylesheet frameworks work.
So why is this a problem?
Imagine the poor html designer when the coffee shop redesigns their menu. At first, some simple positional changes are easy to make... "Move this picture over there... put the hot drinks on the other side..." and so on. But over time, these changes begin to ripple across more and more pages ("Move the logo from the left side to the right side" becomes an edit on a lot of pages). The client asks for things that can't easily fit within the grid system, and that html designer is now left writing CSS that now has to interact with the framework well. Reading the CSS, it never says how to style a MENU.
Enter Semantic CSS - the "CSS Systems" approach.
Why include all that column stuff in your html? After all, we already have these nice IDs that indicate what each section is... furthermore, I might want to use classes to indicate exactly what something is too (I could see a CSS class that wraps every drink as a <div class="hot_drink">, for example, leaving the ID as something that Javascript could uniquely identify the drink by).
Somebody has already explained this better than I can. This presentation by Natalie Downe is well worth the time to view it.
The Best of Both Worlds
I sure like the idea of a semantic CSS system, but shucks - I sure like relying on all that nice CSS that is tested and takes away all the cross-browser pain for me. Is there a way to have my CSS and uh, eat it too? Yes, there is. Take the hour and watch this intro video to Compass, a great CSS editing and composition tool.
The author of Compass has turned many of these grid frameworks into 'mixins' so you can still use the grid system and tested CSS, but you can eaily turn it into a semantic CSS system specific to your project. Want to move around the page contents? The HTML doesn't have to change! VOILA! All the benefits of CSS back in your hands. This can make a BIG difference when the bulk of your html is generated by something like php or Ruby on Rails. Your generated HTML stays the same - no code changes!
A side benefit of using Compass is the use of SASS, a language for writing stylesheets that lets you do all kinds of cool stuff in a syntax a lot nicer than CSS. Again, the screencast shows that.
Puzzle Pieces that Fit Together Nicely
Are you a Rails developer? I knew you were. Guess what? All this fits together with Rails like perfect little puzzle pieces. Inside of erb, the templating mechanism behind Rails' html pages, we can say things like:
<%= div_for(@hot_drink) %>
and get back html that looks like:
<div id="hot_drink_43" class="hot_drink">
Seems kinda trivial, until you realize that now you can have CSS class definitions that match your domain model, which goes a long way towards that "CSS System" ideal. Further, you get a unique ID that represents the object in the div, which you can now use Javascript and the DOM magic of Prototype or JQuery to do Ajaxy-type effects on your page contacts. When your CSS is driven in large part by the display of your domain model, the CSS itself becomes clean, clear, and it is easier to find 'dead' CSS.
Wow.
Comments