Why not use semantic class names for the Compass/Blueprint Grid? [closed]

Question

I've recently started on a large multi-year client project, and the first phase of front-end development is creating a pattern library to use across the project. I'm using Compass and Blueprint for my grid. The @include blueprint-grid mixin looks perfect for this project: it'll automatically generate semantic classnames (i.e., .span5) that the rest of the team can reuse across all pages.

However, the Compass documentation states:

Best practices discourage using this mixin, but it is provided to support legacy websites and to test the sass port against blueprint's example pages.

Why is that? Why is there a push to use non-semantic classes in modern grid systems? It seems less DRY to create a new CSS class for various page elements that will all share the same grid widths. For example:

.dashboard__chart {
    @include column(6);
}

.dashboard__news {
    @include column(6);
}

when I could simply just have a .span6 class to apply in my markup.

This may be situational: the non-semantic classes make sense if your entire project has a similar layout throughout (e.g., a news website or blog). However, this dashboard/reporting tool project has somewhat differing layouts throughout every page.

So back to the original question: why is it best practice not to use semantic classes, and what's the best way to avoid them?

Answer 1

it'll automatically generate semantic classnames (i.e., .span5)

I don't think that "span5" is a semantic name in that it doesn't describe the content at all but describes the layout in a fairly specific way.

_{Of course, the term "semantic" is thrown around a lot, but in its purest sense it should have little or nothing to do with presentation.}

Reasons not to use names which describe presentation:

1. If the layout changes, the name is wrong
2. The layout may be adapted to for a different device for which it is wrong and/or meaningless.
3. The markup has less meaning to anyone reading it (i.e. your team)
4. Layouts can become brittle; changing one class that has been used in many different places and with many different meanings may break in some places in which it is used.

The biggest downside to generic classes like "span6" is that they are abused (I've seen this with Bootstrap, which has similar grid classes defined). "I need this element to span 2 columns...great! I'll just slap a 'span2' class on it and be done!"

This doesn't mean that you shouldn't look for reuse; but that reuse can come from class names that are related to the content (admittedly, this can take some effort) and through the use of mixins.

I've recently started on a large multi-year client project, and the first phase of front-end development is creating a pattern library to use across the project.

Most projects end up with exceptions/compromises for the sake of practicality, but you have the opportunity to start with a best-practices approach.