CSS Grids: the importance of semantics - css

Question

I've recently played around with CSS grids, including great frameworks like Susy (http://susy.oddbird.net/), Foundation (http://foundation.zurb.com/) & the semantic grid system (http://semantic.gs/).
They all share this option of "including" a grid mixin instead of specifying a html class e.g.
.some-div{
#include grid-column(4);
}
While this seems like a good semantic approach, i was wondering about the cost in terms of css weight, css logic and if it's really worth it just to be semantic?
What are the pros and cons of using a mixin grid vs html classes?

Answer 1

Why HTML/CSS semantics are important
There are some much articles on the web about this! Just google it and you'll find a lot of invaluable information.
Here's a good one: How Important Is Semantic HTML?
Semantic html is important because it’s:
Clean — It’s easier to read and edit, which saves time and money during maintenance, and you don't have to force all your users to download a bloated library of styles many of which are not even used on the website
More accessible — It can be better understood by a greater variety of devices. Those devices can then add their own style and presentation based on what’s best for the device. It's also more appropriate for JS frameworks.
Search engine friendly — This is still debatable as search engines rank content and not code, but search engines are making greater use of things like microformats to understand content.
The most important argument for me is that semantic approach is just... the right thing to do. Follow this methodology carefully and you'll have so less causes for regrets.
Why i don't agree with #Mohamad's answer
Google is a bad example
Google's approach to semantics is extremist and violates their own style guide so many times that it's ridiculous. Just have a look at the HTML code of Google search results or HTML and you'll feel sick. It is necessary to understand that Google is an ultra high load website and they trade everything in favor of milliseconds of loading.
CSS is bulky to work with, use SASS
The main Mohamad's argument is that semantic approach is difficult on large projects. In fact, that's only true for old school CSS.
Indeed, it is counter productive to use semantic style with pure CSS. The larger the project, the more effort it requires to go for semantic approach.
But there's SASS. Whoever has tried SASS, never returns to vanilla CSS. SASS offers an incredible lot of powerful improvements, some of which make coding semantically effortless.
SASS code is compiled into normal CSS code. The most important thing to understand about SASS is that you only have to care about the structure and readability of your SASS code. The resulting CSS code may be hard to read and contain duplicates, but it is not a problem because CSS is gzipped by server.
#extend
The most important SASS feature in concern of HTML/CSS semantics is the #extend directive. It allows you injecting a reusable block of styles into semantic selectors, while producing efficient CSS.
First, declare a block of styles to be reused, for example:
%glyph {
display: inline;
width: 16px;
height: 16px;
background-repeat: no-repeat; }
You can later include it into different selectors semantically:
.star {
#extend %glyph;
background-image: url('../images/star.png'); }
.extenral-link {
#extend %glyph;
background-image: url('../images/external-link.png'); }
The resulting CSS will be very efficient:
.star, .extenral-link {
display: inline;
width: 16px;
height: 16px;
background-repeat: no-repeat; }
.star {
background-image: url("../images/star.png"); }
.extenral-link {
background-image: url("../images/external-link.png"); }
#include
Unfortunately, you can't use the beautiful #extend feature within media queries. So if you do responsive design, you'll have to produce CSS code with duplicate fragments. As i said earlier, duplication in CSS is not a problem thanks to gzip, it's the cleanness of SASS that matters.
Mixins (#include) allow you to inject blocks of reusable styles into selectors. They are not grouped effectively, but they accept arguments and can produce varying styles for different semantic selectors:
#import 'singularitygs';
$breakpoint: 300px;
$grids: 2 3;
$grids: add-grid(6 at $breakpoint);
%column {
background-color: pink;
min-height: 5em;
margin-bottom: 1em;}
#welcome {
#extend %column;
#include grid-span(1, 1);
#include breakpoint($breakpoint) {
#include grid-span(2,1); }}
#product-features {
#extend %column;
#include grid-span(1, 2);
#include breakpoint($breakpoint) {
#include grid-span(2,3); }}
#description {
#extend %column;
clear: both;
#include breakpoint($breakpoint) {
#include grid-span(2,5); }}
Produces:
#welcome, #product-features, #description {
background-color: pink;
min-height: 5em;
margin-bottom: 1em;
}
#welcome {
width: 38.09524%;
float: left;
margin-right: -100%;
margin-left: 0%;
clear: none;
}
#media (min-width: 300px) {
#welcome {
width: 31.03448%;
float: left;
margin-right: -100%;
margin-left: 0%;
clear: none;
}
}
#product-features {
width: 57.14286%;
float: right;
margin-left: 0;
margin-right: 0;
clear: none;
}
#media (min-width: 300px) {
#product-features {
width: 31.03448%;
float: left;
margin-right: -100%;
margin-left: 34.48276%;
clear: none;
}
}
#description {
clear: both;
}
#media (min-width: 300px) {
#description {
width: 31.03448%;
float: right;
margin-left: 0;
margin-right: 0;
clear: none;
}
}
Demo: http://sassbin.com/gist/5883243/
Compass extensions
As you noticed above, i use a grid-span mixin that is not declared in code. That's because it comes from the awesome Singularity extension.
The ecosystem of numerous Compass extensions provides you a great set of tools for all needs: semantic grid systems, responsive design, colors, math, all kinds of styles... You don't have to reinvent a thousand of wheels for every project you build!
What to read about SASS
This is a great starting point for SASS newcomers: https://github.com/Snugug/training-glossary/wiki , created by Sam Richard aka Snugug.

Answer 2

I often feel that some advocates of semantic grids have never written complex applications. The answer, as ever, is the proverbial "depends."
It depends on your style, your team, and your application. In some projects that required modular design, being semantic required extra code and effort for very little return. In others, simpler ones, it was fine. Take a look at the CSS that Google uses. Not everyone is Google-size, but that illustrates my "depends" point.
The advent of HTML 5 has solved some of these problems with tags such as section, header, and article. I tend to use those semantically. But my CSS class names tend to describe abstract divisions of my design, not what the thing is specifically.
There are no straight answers, but careful not to waste too much time worrying about this stuff. It means very little if your application is late or does not make it out of the door.
Do what you and your team feel comfortable with.