minimal design

Digital Web recently published an article untitled Smart CSS Ain’t Always Sexy CSS wich sparked a heated debate on the topic of semantic vs. presentational CSS markup. To sum it up and oversimplify a little, that’s the difference between semantic:

<p class="alert">Some error message</p>

and presentational:

<p class="red">Some error message</p>

While they both achieve the exact same result on an isolated example such as this one, they each imply a completely different approach on how to structure your HTML/CSS relationship. Although the author does not recommend the use of the oversimplified example above, he does advocate that the use of presentational markup is the “smart” choice given certain circumstances.

That article, which I would personally qualify as “ill-informed,” generated many interesting comments. On one side, comprised essentially of the author and some of Digital Web’s staff, the argument is that “sexy” CSS is just an idealistic approach with little practical use in a “real world” production environment. On the other side, quite a few web professionals chime in to both express their discontent with Digital Web for publishing such a poor article and to explain to the author what’s wrong with his reasoning.

A lot of good points are made in the comments, and while the Digital Web staff is trying to make it sound like it’s the sign of a successful article that started an interesting and needed conversation on a topic that deserves an in-depth exploration, people are essentially just ticked off by an article that is mostly rubbish and reveals the author’s shortcomings in terms of CSS comprehension more than anything else. I started to expose some of the problems inherent to this faulty CSS approach but I guess a more detailed explanation might be needed. In order to keep it as short as possible, I’ll stick to the more technical aspect and practical examples.

To take one of the author’s examples: with multiple elements that all feature a similar layout, he would use a .horizontal class on containers with floated elements inside, so the markup would look something like:

<ul id="main_nav" class="horizontal">
    <li><a href="#">A link</a></li>
</ul>
[...]
<ul id="footer_nav" class="horizontal">
    <li><a href="#">A link</a></li>
</ul>

In his reasoning, having:

.horizontal li {
    float: left;
}

is “smarter” than:

#main_nav li, #footer_nav li {
    float: left;
}

because the CSS is shorter and if you decide for instance that the main navigation should be vertical after all, “all you gotta do” is remove the class="horizontal" from the main_nav list in the HTML.

OK, let’s take this a little further down the “real world” lane for a minute… If those 2 navigation elements need to be floated right, with his “smart” system, you have to add a “right” class to both HTML elements:

<ul id="main_nav" class="horizontal right">
    <li><a href="#">A link</a></li>
</ul>
[...]
<ul id="footer_nav" class="horizontal right">
    <li><a href="#">A link</a></li>
</ul>

And a new CSS declaration

.horizontal li {
    float: left;
}

.right {
    float: right;
}

Whereas with the “sexy” implementation, you add one CSS declaration:

#main_nav, #footer_nav {
    float: right;
}

#main_nav li, #footer_nav li {
    float: left;
}

One thing you should start noticing is that both the HTML and the CSS in his “smart” version are becoming a little cryptic for someone who would have to jump in later on whereas the supposedly inferior “sexy” version remains crystal clear and even nicely outlines the hierarchy of the CSS…

Now, if the designer comes back to you and tells you that links in the footer shouldn’t be underlined, following the “smart CSS” theory all the way, you have to add the no_underline class to all the links (option #1), or come to some sort of middle ground compromise and add instead the class to the list itself (option #2):

option #1:

<ul id="main_nav" class="horizontal right">
    <li><a href="#">A link</a></li>
</ul>
[...]
<ul id="footer_nav" class="horizontal right">
    <li><a href="#" class="no_underline">A link</a></li>
</ul>

.horizontal li {
    float: left;
}

.right {
    float: right;
}

.no_underline {
    text-decoration: none;
}

option #2:

<ul id="main_nav" class="horizontal right">
    <li><a href="#">A link</a></li>
</ul>
[...]
<ul id="footer_nav" class="horizontal right no_underline">
    <li><a href="#">A link</a></li>
</ul>

.horizontal li {
    float: left;
}

.right {
    float: right;
}

.no_underline a {
    text-decoration: none;
}

By now, in option #1, you have to add classes to every single link, so much for convenience and simplicity… And if you decide to work around that inherent shortcoming of the “smart” system by implementing option #2, you open the door the CSS hell on any project of consistent size. First off, anyone who jumps in the HTML will not be able to know for sure what a no_underline on a list element is supposed to do, they’ll have to go back and forth between the HTML and CSS files to figure out what’s going on. But the real “fun” begins when, for example, all links that are not underlined by default also need to be a specific color, but the footer nav needs to remain identical… certainly not a too uncommon situation… Now you got:

option #1:

<ul id="main_nav" class="horizontal right">
    <li><a href="#">A link</a></li>
</ul>
[...]
<ul id="footer_nav" class="horizontal right">
    <li><a href="#" class="no_underline default_color">A link</a></li>
</ul>

.horizontal li {
    float: left;
}

.right {
    float: right;
}

.no_underline {
    text-decoration: none;
    color: #ddd;
}

.default_color {
    color: #000;
}

option #2:

<ul id="main_nav" class="horizontal right">
    <li><a href="#">A link</a></li>
</ul>
[...]
<ul id="footer_nav" class="horizontal right no_underline">
    <li><a href="#">A link</a></li>
</ul>

.horizontal li {
    float: left;
}

.right {
    float: right;
}

.no_underline a {
    text-decoration: none;
    color: #ddd;
}

#footer_nav.no_underline a {
    color: #000;
}

Option #1: the HTML is becoming ridiculously long, even for such a basic example, while not utilizing the cascading nature of CSS whatsoever. You officially removed the “C” out of “CSS.” Option #2: by trying to shorten the amount of HTML and take advantage of some of CSS cascading features, you’ve officially entered CSS hell with a bastard system with styles called no_underline which actually influence a completely unrelated color property. If you ever need to underline the footer navigation links, after poking around the HTML, you might try removing the no_underline and find out that the links color changes at the same time…

As far as the “Sexy” version, the HTML does not change and you get:

#main_nav, #footer_nav {
    float: right;
}

#main_nav li, #footer_nav li {
    float: left;
}

#footer_nav a {
    text-decoration: none;
    color: #000;
}

#other_element a {
    text-decoration: none;
    color: #000;
}

The CSS might be longer, depending on how many other elements need to have their color and underline styling changed, but the HTML does not need to be changed at all, it is significantly shorter than the “option #1” version, and you don’t even need to look at the HTML to understand what’s going on in the CSS. It does not have any inconsistent dependencies that result in unexpected behaviors as “option #2” does.

Those are pretty clear advantages over the supposedly pragmatic CSS approach exposed in the Digital Web article and that is why I believe it’s perfectly appropriate to call this CSS approach wrong, period, with no room for personal interpretation or preferences.

Not to mention that this is only one of the many problems with presentational markup…