{justCSS}

Just plain CSS

est. 2015

Separation of concerns in CSS

I recently started a process of refactoring all the front-end code at my full time gig. I have also been reading tons of articles relating to style guides and pattern libraries … and, subsequently, just about every article on the topic of OOCSS, SMACSS and Atomic Design and just realised again how poorly the code base I inherited was designed/architected.

It doesn’t matter what you read and/or how much you know; it pretty much makes sense to do things in a modular fashion and apply the DRY principle to just about anything … from writing code, designing to doing everyday chores – it pays to have a system/mechanism in place that takes care of the mundane, common elements so you don’t have to manually repeat them ad nauseum.

In CSS, this could mean avoiding over-qualifying selectors in favor of finding a repeatable pattern and applying one set of styles to an element, typically as a class … this is the foundation of OOCSS. Case in point:

h1{
  font-family: "wfuturamedium";
  font-size: 1.875em;
  font-weight: normal;
  text-transform: uppercase;
  margin: 0 0 1em 0;
}
h2,
.recipe h1{
  font-family: "wfuturasemibold";
  font-size: 1.125em;
  font-weight: normal;
  text-transform: uppercase;
  margin: 0 0 1.125em;
}
h2{
  font-family: 'wfuturasemibold';
  font-size: 1.125em;
  line-height: 1em;
  text-transform: uppercase;
  margin: 1.125em 0;
}
article.recipe h2{
  font-size: 0.875em;
  font-weight: normal;
  line-height: 1em;
  margin: 0 0 1em;
}
article.recipeAdditional .buyIngredients h2{
  font-size: 1.125em;
}

… as should be obvious to even a novice, there is abundant re-use of the same declarations, in some cases with exactly the same property|value pair – surely this is exactly the corrrect use case for an object class to be constructed from the common values in the various selectors.

Why not cook up some class soup?

Many developers seem to have an issue with seperating semantic concerns from styling or, at the very least, understanding the principle … and, make no mistake, I sometimes still take the coward’s way in favour of solving something quickly – it doesn’t make it right, but it would seem like some are just plainly lacking understanding (something that occurs to me every time I have to interview a fellow developer for a role at said current gig, but that may be for another post/another day).

… after all – what are headings good for? Semantics, right … and a little bit of healthy SEO; still – nothing wrong with styling your headings, but would it hurt to add a few classes? They don’t distract from the function/meaning of the heading and allows us to style elements, irrespective of their use.

Take the second selector as an example – someone needed an <h1> that was styled like an <h2>, but only when used inside .recipe. The exact same font size is used repeatedly in multiple selectors. If <h2> already has a line height of 1em defined, why repeat this rule in the article.recipe h2 selector? Why tranform to uppercase every chance you get? Why declare the font family in each selector? … DAFUQ!!!?? Why not use a class? It’s there for the taking … and while you’re at it, why not add a whole bundle of classes to group the other common styles?

/* HTML */
<div class="recipe">
  <h1 class="heading">Recipe heading</h1>
</div>

/* SCSS */
.heading{
  font-family:'wfuturasemibold';
  font-size: 1.125em;
  text-transform: uppercase;
  &--large{
    font-size: 1.875em;
  }
  &--small{
    font-size: 0.875em;
  }
  &--medium-text{
    font-family: "wfuturasemibold";
  }
}

… I’m not extracting/abstracting the rest (and not saying that this is the exact setup and/or that you should be using an h1 there), but you see my point – sure … class soup *YUK!* … or maybe just clean, maintainable, scalable CSS? … add to this the minor complication of managing a small team of developers with varying levels of experience/competence and you’ll soon see how using class soup in your HTML trumps class soup in your CSS – better patterns, better naming standards (not to mention: easy to cook up in SCSS – less typing … WIN!!!), easier to read and understand with a nice, flat specificity with none of this sort of malarkey:

Leave a Reply

Your email address will not be published. Required fields are marked *