CHAPTER 1 Modern CSS Architecture and Front-End Development
looSe ClaSSeS
We’ve covered two real types of class here. First, we looked at really ab-
stract, highly reusable classes with really abstract names that don’t align
themselves to anything in particular. Second, on the flip side, we looked at
classes that do specific jobs and thus receive explicit, verbose, namespaced
names. Combining the two is a very bad idea. Giving a specific component
a very loose class is extremely unwise.
A loose class name is one that isn’t named explicitly enough for its in-
tended purpose. Imagine you work on a huge site with loads of developers
and you see a class of .card. What does this do? Such a class name is very
loose, and loose class names are very bad for two main reasons.
First, you can’t necessarily glean its purpose from the class alone (is it a
user’s profile card, an e-card, a field in a form that accepts credit card num-
bers?). Second, it’s so vague that it could very easily be redefined acciden-
tally by another developer. Loose classes are like global variables: hard to
keep track of, easy to (accidentally) override, and readily able to sneak into
your work where you least expect them.
A loose class name is to CSS what global scope is to JavaScript. A vari-
able in global scope could accidentally be reassigned by or accidentally
introduced into unrelated parts of the program. This is why developers shy
away from global scope where possible.
By paying attention to our class names, and avoiding using loose selec-
tors for specific jobs, we can better control our selectors’ scope.ReCaP
So, let’s review. Very high-level abstractions should have very abstract
names. They should not align themselves to any particular content, and the
meaning they convey should allude to visual patterns rather than describ-
ing the affected content.
Specific components should have very explicit naming conventions,
and making use of things like BEM can really help out with this. Such