By Harry Roberts CHAPTER 1
As well as decreasing portability and robustness, increasing selector length
increases specificity — this is the worst of all worlds.
The Single Responsibility Principle
We’re back to the SRP again! Now that we have these tiny, class-based
short selectors, we can combine them far more easily with each other. This
is yet another benefit of keeping our selectors short. Their small, one-job-
and-one-job-only nature makes them really easy to combine, add to and
subtract from each other.
Takeaway: Keep your selectors as short as possible, keep their specificity
low at all costs, keep them as combinable as possible, keep them on the SRP
and make sure they have sound selector intent.
Naming Conventions
With all these dozens of abstracted, SRP classes, we need a decent, con-
sistent and workable way of naming them. You’d be surprised just how
troublesome poorly named classes can be, but I wouldn’t advise finding out
the hard way. As Phil Karlton once said:
There are only two hard things in Computer Science: cache invalidation
and naming things.
For the longest time, we’ve been told that our class names should be
semantic. As we covered previously, this is all a bit of fool’s gold: only hu-
mans make any sense of classes, so write them for people.
Giving a list a class of .blog-posts is redundant. We can tell from the
content that this is a list of blog posts so there is no need to state that in
your class, which is merely a style hook. Instead of restricting yourself
to only using this class to style a list of blog posts, why not name it more
neutrally? You could then apply it to any list at all: a list of products, a list of
latest news items, a list of usernames, anything.