Grid Style Sheets Must Die
I have been aware of Grid Style Sheets for quite a while, but I long ago dismissed them as a fad like CSS Resets. Recently though it came to my attention that OSCommerce 2.3 switched to the 960 Grid Style to replace its table based layout system. I spend most of my development time working with OSCommerce and thought it would be good to understand this change so I could decide whether or not to integrate it into our fork.
My general impression playing with the latest nightly of OSCommerce 2.3 from Github though is that I don’t like it – maybe I’m old school, but in my view Grid Style Sheets go against what we spent the previous decade fighting for, separation of our concerns… separating presentation and content.
You’re Doing it Wrong
Let’s talk about separation of presentation and content.
Ideally, content and layout information should be entirely separate. Class names should be used to describe the data they contain, and nothing to do with the style the class will contain. You should be able to completely rearrange / restructure a page simply by switching out a stylesheet. The HTML should strive to be as purely a data delivery mechanism as possible, similar to that of an XML request, and the CSS is there to make it something a human can digest.
Using a Grid stylesheet – your class names purely apply to your specific layout. Class names like “grid_1” or “container_12” are not indicative of content in the slightest, but rather where they are placed on the grid that is your page. Grid_1 will always be leftmost. Always. Might as well use <left> Correction: Grid_1 will always be one twelfth of your page wide (on a twelve Column Grid) , Grid_2 two twelfths, et cetera. Nothing to do with describing the content contained.
Grid Style Sheets are Extremely Limiting
With a well-structured CSS layout, deciding to move your navigation from the left to the right is as simple as flicking a switch. Usually after changing one to a few lines of CSS, and its switched. It cascades across your entire site and everything floats and adjusts. Same goes for altering the width, or even the entire flow of your document. You can quite easily decide your left navigation is now a top navigation with no alteration to the content.
Contrast this with a grid style sheet – to reposition anything you will have to edit the HTML – change the class you call. Restructuring a site is a major task. They are essentially tables done in CSS with all the drawbacks of tables with few of the benefits (*cough* valign *cough*).
Why Does this Matter?
Flexibility, sustainability, scalability – these are not just buzz words – these are important attributes of a well-developed site – these are things a grid layout does not deliver.
Let’s look at this from a prebuilt application perspective. In OSCommerce 2.3 the left navigation is classed grid_4 which places it 4 gridlines out of 16, and the content area is push_4 which aptly pushes it over 4. That defines not only where my navigation appears, but also its size. Its inflexible without changing HTML, and quite honestly wouldn’t work for the majority of carts I develop.
Final Thoughts
Grids, from a design perspective are not just useful, they’re downright ideal. Clear alignment of elements creating strong visual lines is something strived for. Consistent padding and margins are all very important – and all of these are honorable virtues of a grid style sheet.
I definitely understand the draw and the time saved in the initial build of a site, but a meticulously well engineered style sheet supporting semantic CSS will in the long run pay back the initial investment many times over.
Post Script
While writing this, I’ve decided I really like the concept and aim of the grid style sheet – and would love it if it did not interfere with the semantic nature of CSS. If I could simply do something like the following, I would be using it 10 minutes ago.
W3C – I’m looking your direction to see this happen. Until then, I’m sticking with my old fashioned meticulously crafted CSS.