By Harry Roberts CHAPTER 1classes, because they usually work in conjunction with other classes,
should give developers a helpful and insightful overview of the code
they’re working with.
Finally, you should never combine the two. If a class does a specific job,
it should have an equally explicit name (e.g. .user-profile__name rather
than .name).
Takeaway: Make sure the names you use for selectors are appropriate, and
that they expose as much information as they can. Do not worry about
being long-winded with classes (I recently wrote a class of .accordion__
trigger--closed), and name them so that other developers will find them
practical and sensible to work with.
Verbosity in HTML
Let’s talk about the elephant in the room. All this talk of granularity and
abstractions and objects surely means more classes in our markup, and
more verbose HTML, right? Right. Many people shy away from using
more classes in their HTML because of misconceptions around semantics
and clean markup. As we’ve discussed, this is understandable but a little
misguided. The main reason to avoid using too many classes is maintain-
ability. This is important, but there needs to be a degree of pragmatism and
a balance.
In relation to the maintenance overhead of more classes, we often
think about the cost of having to change classes in many HTML files or
views or templates. Avoiding adding more classes, therefore, means that
we have less to change across HTML files should we ever need to. This, of
course, is very true. More classes does mean more HTML to potentially
maintain.
However, avoiding classes means you’re probably writing less granu-
lar CSS, so your CSS isn’t separated out and it will be harder to maintain.
You’ve simply moved the maintenance overhead from your HTML to your