CSS Utility Classes and "Separation of Concerns"(adamwathan.me)

over 3 years ago from Adam Wathan, Full-Stack Developer

  • Renato de LeãoRenato de Leão, over 3 years ago

    Hi Adam! Excellent wrap up on CSS strategies, congrats for the article

    My path is fairly similar to yours, and I would say most people who have been doing frontend for living can relate to it as well.

    I've been an OOCSS evangelist for a few years now, the Phase 3 group of your article, but some months ago i've started adding some utilities to the party as well: spacing, coloring, typescales and my new favourite is a personal version of FLA from StefanKovac which means I'm now in Phase 4. What got me to this point was the useless or over engineered abstractions or that you've mentioned. What prevent me to go fully functional CSS approach is just one thing: clarity

    Let's take a second look at that specific the actions-list pattern. Let's add just a little extra complexity there. Responsive complexity. Imagine that your buttons are bordered, there's no space between them and that in small screens they are stacked vertically and on bigger screens horizontally. You want to collapse borders (like tables do) by using the negative -1px margin-left plus you need z-index on :hover trick.

    OOCSS vs FCSS:

    CODEPEN ALERT

    That escalated a little bit right? In modern applications, designed for thousand of screen sizes, complexity can be much higher that a "simple" pack of objects" and single breakpoint. So in the end I would still use a OOCSS pattern in there.

    Quoting both Nicolas Gallagher and Harry Roberts at the same time:

    Class names should communicate useful information to developers. How much information can we glean from the smallest possible source? Is our code self-documenting? Can we make safe assumptions from a single context? How much do we have to rely on external or supplementary information in order to learn about a system"

    We don't code only for machines, we code for our teammates as well.

    And that's exactly what you're trying to solve with Tailwind CSS!

    And i'm curious about it: getting the benefits from rapid and dry Utility/FCSS approach, but keeping the OOCSS clarity!

    For a SASS lover like me, a major set back would be that we can't dinamically generate mixins we do with atomic classes. We can use extend or silent placeholders but we know that mixins are better for performance. So it will be more tuff to do the setup manually.

    Keep up and looking forward for that Tailwind CSS! Subscribed!


    Yes, I shamelessly admit that I'm a fanboy of Harry's work

    3 points