By Harry Roberts CHAPTER 1To quote Google developer, Jens O. Meiert: “Use names that are as short
as possible but as long as necessary”^16.
A class like .content is preferable to a class like .cntnt or .the-area-
of-the-page-that-will-hold-the-main-content.
Classes that deal with general design patterns and abstractions should
be vague, abstract and neutral. The media object, again, is a perfect exam-
ple of this. I came up with the idea of the island object: a design pattern
whose only job is to create a padded box. The reason I chose “island” is
because it can be applied to all manner of elements. An island is something
separated from its surroundings on all sides; the island object boxes off
some content.
For very high-level abstractions and design patterns, use abstract
names that lend themselves well to reuse, and don’t align themselves too
tightly to a specific type of content. This vague and abstract relationship
allows for greater portability and reuse of your classes.
For specific components (like carousels, or headers or accordions) you
need to use specific, unambiguous names which tell developers a lot about
the component from the classes in the markup alone. Let’s use a quick
example:
Here we can see how all of our classes are well named, very explicit and
clear. Looking at these classes tells us a lot about the component already:
that it is designed to have a heading and an image, for example. But wait,
there’s more...
16 Jens O. Meiert, “Best Practice for ID and Class Names”, http://smashed.by/ids-classes, Aug. 12, 2008