Journal tags: maintainability

In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:

There are two types of problems in CSS: cosmetic problems and architectural problems.

The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:

If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.

This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.

selector {
    property: value;
}

The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.

The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?

I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.

Two articles were published today that take diametrically opposed viewpoints on how developers should be using CSS:

• Thierry Koblentz writes about Challenging CSS Best Practices for Smashing Magazine.
• Ben Darlow writes about Cargo Cult CSS on his own site.

I don’t want to attempt to summarise either article as they both give fairly lengthy in-depth explanations of their positions, although I find that they’re both a bit extreme. They’re both ostensibly about CSS, though in reality they’re more about the class values we add to our HTML (and remember, as Ben points out, class is an HTML attribute; there’s no such thing as CSS classes).

Thierry advocates entirely presentational values, like this:

    <div class="Bfc M-10">

Meanwhile Ben argues that this makes the markup less readable and maintainable, and that we should strive to have human-readable markup, more like the example that Thierry dismisses as inefficient:

    <div class="media">

Here’s my take on it: this isn’t an either/or situation. I think that both extremes are problematic. If you make your class values entirely presentational in order to make your CSS more modular, you’re offloading a maintainability expense onto your markup. But if you stick to strictly semantically-meaningful class values, your CSS is probably going to be a lot harder to write in a modular, maintainable way.

Fortunately, the class attribute takes a space-separated list of values. That means you can have your OOCSS/SMACSS/BEM cake and semantically eat it too:

<div class="media Bfc M-10">

The “media” value describes the content, which is traditionally what a semantically-meaningful class name is supposed to do. Meanwhile, the “Bfc” and “M-10” values say nothing about the nature of the content, but everything about how it should be displayed.

Is it wasteful to use a class value that is never used by the CSS? Possibly. But I think it serves a useful purpose for any humans (developer or end user) reading the markup, or potentially machines parsing/scraping the markup.

I’ve used class values that never get touched by CSS. Here on adactio.com, if I want to mark up something as being a scare quote, I’ll write:

<q class="scare">scare quote</q>

But nowhere in my CSS do I use a selector like this:

q.scare { }

Speaking of scare quotes….

Both of the aforementioned articles begin by establishing that their approach is the minority viewpoint and that web developers everywhere are being encouraged to adapt the other way of working.

Ben writes:

Most disconcertingly, these methodologies have seen widespread adoption thanks to prominent bloggers evangelising their usage as ‘best practice’.

Meanwhile Thierry writes:

But when it comes to the presentational layer, “best practice” goes way beyond the separation of resources.

Perhaps both authors have more in common than they realise: they certainly seem to agree that any methodology you don’t agree with should be labelled as a best practice and wrapped in scare quotes.

Frankly, I think this attitude does more harm than good. A robust argument should stand on its own strengths—it shouldn’t rely on knocking down straw men that supposedly represent the opposing viewpoint.

Some of the trigger words that grind my gears are: dogma, zealot, purist, sacred, and pedant. I’ve mentioned this before:

Whenever someone labels those they disagree with as “dogmatic” or “purist”, it’s a lazy meaningless barb (like calling someone a hipster). “I’m passionate; you’re dogmatic. I sweat the details; you’re a purist.” Even when I agree completely with the argument being made—as was the case withAndy’s superb talk at South by Southwest this year—I cringe to hear the “dogma” attack employed: especially when the argument is strong enough to stand up on its own without resorting to Croftian epithets.

That’s what I was getting at when I tried to crack this joke on Twitter:

@drewm When a designer is picky, it’s called sweating the details. When a developer is picky, it’s called being pedantic.

— Jeremy Keith (@adactio) September 10, 2013

…but all I ended up doing was making a cheap shot about designers (and developers for that matter), which wasn’t my intention. The point I was intending to make was that we all throw a lot of stones from our glasses houses.

So if you’re going to write an article about the right way to do something, don’t start by labelling dissenting schools of thought as dogmatic or purist.

Physician, heal thyself.