Grid Style Sheets vs. The Semantic Web
- Comments:
- 10
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 Internet 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.
#leftnav {
imports: .grid2;
}
W3C – I'm looking your direction to see this happen. Until then, I'm sticking with my old fashioned meticulously crafted CSS.
Update February 3, 2014:
While my position on grid CSS has not changed, there are now many many Sass, Less, Stylus etc CSS pre-parser grid frameworks which allow your CSS to still be semantic, while utilizing grid layouts. This is wonderful and I wholeheartedly endorse their use.
Comment by: Joel Clermont on
Inheritance like you describe would be cool. You sure it's not in css3?
Comment by: Jason Jones on
Spend some time reading about the system before commenting on it.
Comment by: Jesse G. Donat on
I did spend nearly an entire work day working with it, considering our upgrade path from OSCommerce 2.2 to 2.3. I misspoke and slightly misunderstood, yes, but I did work with it, and had good reason to dislike it.
I have corrected that single line of my post, but the rest of my argument stands, and was in no way disqualified. Moreover, the correction still enforces my argument that the class names are inherently unrelated to content and therefore not semantic. Width is not a good description of content, certainly not as good as say, I don't know... #content or something of the like.
I appreciate the comment, but I'd rather not have my head bit off. Thanks.
Comment by: user admin on
I am an IT person. I wear the hat as a DBA (sql server) and application developer.
When working with the old 2.2 version of oscommerce I thought that the code was not the latest and greatest, but it worked very well and was easy to add contributions to.
So for the past two days I have been dissecting the 2.3 version and it's code. I must say that I am a little disappointing.
The whole grid system is a step backwards and I firmly think that the authors have wasted their time. It this the direction of 3.0? I hope not.
I don't fully understand the grid system, but I do know css and coding standards. The use of the grid system is clearly not a standard, but a fad and it will be the down fall of oscommerce if this direction is continued.
I have recently started looking at new free ware carts to "pull" myself and my online shop away from oscommerce.
Cheers all
Comment by: user admin on
So I spent the last hour or so looking at sCommerce Online Merchant v3.0 Alpha 5 and now I think 2.3X has been a complete waste of everyone's time.
V3.0 is on the right track, but why no further development?
Comment by: Jesse G. Donat on
I myself have been working on OSCommerce 2.2 for just over 4 years. I agree with you on all points except one. If you actually dig into the 3.x codebase, the "classes" are not what anyone who's studied computer science would consider "good", or even "acceptable". Its very much just that they took the existing codebase and pasted it into classes, rather than taking a more "our old codebase is outdated garbage, lets start clean" approach.
As for the lack of releases, it is my understanding that they restricted access to the repository until it was "ready" which in my book means "never again". We will see though. I'd like to give Magento a serious look but the company I work for has a huge investment in OSCommerce.
Comment by: chex_is_yummy on
Interesting, as at our current shop in Utah, we are having a similar debate as to whether to use the 960 grid system (we're suing the 12 col variety) or not. Here are some questions we've debated - what are your thoughts?
1. Is the 'web' really looking at semantics and invalid code and punishing sites for not following semantics or is this becoming a purist thing? You guys mentioned deprecated tags and semantics, but all browsers continue to support/render tags such as <b>,<i>, and <font>. They just came out with ie9 and ff4 March 2011 - and even some of the 'other' browsers continue to render these tags without issues. The same can be said for table-based layouts. So is the W3C making up rules for nothing if browsers are still rendering tags that are deprecated?
Additionally, software that helps web authors create sites tend to support these tags although they'll tell you they are deprecated (a la DreamWeaver as an example).
There are also rich text editors that continue to place these tags in freely. Some customers have the ability to use wordpress or other CMS programs that grant them the ability to add text using the gui of the rich text editor which normally places in code that's not so 'semantically friendly' if you choose a specific drop down.
It is likely that the majority of people placing in content will not know about semantics, and will inevitably place in the wrong structure. I don't believe they'll ever be punished for this by an browser, web app, or software
2. If grid based layouts are truly that bad for semantics and SEO, has there been any studies to show that Google and Yahoo are failing to rank these sites properly because a 'grid_7 on a <div>' isn't specifying it as 'content' as the class name? Are search engine spiders not complex enough to read into individual divs and determine the type of content that is in them and make relation to the site as a whole? And what is the threshold of the semantics as a whole to determine if a site will be found or not? If it will render or not?
3. Bloated CSS - so by keeping the native 960 code as a reference style sheet, your css is blowing up in file size from a typical style sheet of 2k to the 8-9k the grid css has. How important is this in today's turbo powered internet infrastructure that is only getting faster to support files that support music and movies? the days of 56k/128/k are long gone...so having the styles stay in the sheet as a 'tool box' for the designer to reference at anytime 'seems' ok and shouldn't have bearing on the site rendering 'slower' because the .css file size is 9k vs 2k.
4. Finally, as I work in a production shop in Utah, we tested using it on a few sites . By using 960 12 col, designers are easily able to read layouts of other designers almost instantly by looking at a site fully rendered, or even if going into the code, they can get a since of the layout almost immediately thanks to the 'numbering system' involved with the grid. That makes the code easier to read from a structure perspective, regardless of the grid_xx classes being used to structure layout.
Is this a bad thing and what is the balance between having designers being able to read and adjust layouts by changing the class in the HTML vs semantics on the web that seem to be ignored by browsers and web apps (as far as rendering goes - which is what counts in the end)?
As I read into this more and more, it seems that technology is supporting the breaking of semantics. I've seen sites that use 960 grids of all variety that seem to be ranking fine in search engines - and I've seen sites that are breaking all types of other semantics that rank fins as well.
Sure, if someone built an entire site out of nothing but <p> tags with classes to define stucture areas, that 'may' cause trouble for concern. But using divs as they are meant to be used (structure and contain multiple elements) seems fitting and semantically correct, and the 960 appears to support this.
your thoughts?
Comment by: clonyx on
Comment by: AntoxaGray on
Or you prefer to write bloat CSS file with tons of repeating rules, just because grid is «non-semantic»?
I prefer to edit HTML if I want to change how much grids block take, than trying to solve puzzle with descendant selectors in CSS.
Anyway, why would I want to change grid layout of my blocks?