CSS Utility Classes and “Separation of Concerns”

Haha, now this sounds all too familiar:

Over the last several years, the way I write CSS has transitioned from a very “semantic” approach to something much more like what is often called “functional CSS.”

The author lists 5 stages

  • Phase 1: “Semantic” CSS
  • Phase 2: Decoupling styles from structure
  • Phase 3: Content-agnostic CSS components
  • Phase 4: Content-agnostic components + utility classes
  • Phase 5: Utility-first CSS

Currently I’m “stuck” in Phase 4, having tinkered with stuff from Phase 5. Must say I’m not that huge of a fan of Stage5-stuff because it just allows one to fuck things up too badly

For example, the designer of a project most likely knows that a button should never be used in combination with a class ph1 (= padding-horizontal, variant 1), but at minimum with ph3, and should always have br2. A developer however might not know that, and just go wild with everything given to him/her, not even noticing that he’s doing stuff the wrong way.

Giving the developer classes like button--secondary and button--medium (cfr. Phases 3 and 4) tends to lead to less layout monsters/fuckups. The ideas of Phase 5 however do have their use, yet I’d define them params/variables in my own Sass/Stylus code instead, to then use within my “Content-agnostic CSS” classes. Put differently: write your CSS thinking in Phase 5, producing Phase 4 code for yourself/others to use.

CSS Utility Classes and “Separation of Concerns” →

Elsewhere ,

One Response to CSS Utility Classes and “Separation of Concerns”

  1. Luciano says:

    Great technique! I was looking for a solution for this problem. Thanks!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.