Lesson 3: Naming
Naming things is hard, so hard in fact that you’d be hard-pressed to avoid the following quote (it’s become a bit of a meme):
There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton
When we talk about“names” in CSS, what we’re really taking about are the different attributes we give to HTML elements to identify them. Things like class names, IDs and name attributes.
Use Semantic naming #
Semantic naming is a commonly practiced philosophy in CSS, it’s main tenet is:
Explain what an element is, not what it looks like
Imagine describing an element on a page to someone who isn’t able to see it. Instead of relying on it’s visual characteristics (“it’s the big red button”), you’d have to consider some of the following:
- What is it? Is it a link? Is it a button? Is it an image?
- What is it’s purpose? Is it responsible for linking to a specific page? Does it show particular kind of image?
- What context differentiates it? If the element is surrounded by similar elements, how do you avoid ambiguously naming it?
Let’s consider an example. We have a bunch of text and want to make specific words bold.
Seems sensible enough so far. A few weeks later, we decide that instead of making these words bold, we want to make them pink!
But we’ve forgotten to update the class name to reflect the changes to the CSS, so now there’s a confusing semantic mismatch. We’ve got a class that says that the text is bold, but in reality it’s pink and not bold! Anyone new coming to this HTML is going to have a puzzling job of figuring out what’s going on.
To rectify this situation, we need to update all the class names to something that accurately reflects the current nature of the pink elements. We could rename the class to
.pink-text, but this just leaves us in the same situation as before! If we decide pink isn’t the colour for us, then we’ve got to go and rename all the classes again.
So what’s the solution? Semantic naming!
But before we arrive at the fix, we have to properly understand the problem. The core issue is that we’ve named the class by it’s visual properties which, in an evolving front-end, will often change. To find a solution, first we have to figure out why we are making this text bold or pink. What’s the intention? What’s the point?
In this scenario, what we really want to do is highlight or emphasise these specific words to the reader. We want to visually accentuate that these words are important.
So now we understand the problem, what do we name the class? Well just by stating our intention we’ve armed ourselves with the vocabulary! Highlight, emphasis, accentuation. Any of these would work a treat, and the best thing about them is that they accurately describe the elements without coupling themselves to specific visual design decisions.
So to summarise:
Avoid coupling names to CSS rules
Train your nose to these kinds of code smells,
Semantic names are more maintainable #
As the above example illustrates, semantic naming is more resilient to design changes; classes are more likely to be relevant to the elements they’re applied to and less likely to become out-of-date.
It also has the advantage of documenting your elements. If you’re annotating, via class names, what each bit of HTML is instead of how it looks, then someone unfamiliar with a bit of UI can see how the HTML and CSS join up to the visual elements.
That means better knowledge-sharing and less mental load when working with semantically-named elements, producing a more maintainable codebase overall.
Try to avoid name collisions #
In CSS, name collisions commonly refer to when you accidentally give an element a name that is already used by an unrelated, existing element. When this happens, the styles you give your new element will start to interfere with the existing elements.
These issues are sneaky and hard to spot, as the elements you’re impacting may be in a totally different section of your site. You may not think to check the contact page if you’re editing the home page! This override behaviour is core to CSS’s cascade, but unfortunately assumes authors are omniscient and don’t make mistakes!
Let’s dig into some solutions to tackle name collisions.
Shorter names ➡ more reusable #
Try to adhere to the following naming convention:
Keep an element’s name length inversely proportional to it’s reusability
In other words, use shorter names for widely-used, reusable elements and longer names for uncommon elements that are used maybe once or twice.
- Lesson 1: Specificity
- Lesson 2: Scope
- Lesson 3: Naming ← You're here
- Lesson: Managing Variations Coming Soon
- Lesson: BEM Coming Soon
- Lesson: SCSS Coming Soon
positionDeep Dive Coming Soon
- Lesson: Reusability Coming Soon
- Lesson: Units Coming Soon
- Lesson: Media Queries Coming Soon
displayDeep Dive Coming Soon
- Lesson: Flexbox Coming Soon
- Lesson: Grid Coming Soon
- Lesson: Inheritance Coming Soon
- Lesson: Layout vs Aesthetics Coming Soon
- Lesson: Fixing Bad CSS Coming Soon
- Lesson: Composability Coming Soon
- Lesson: File Organisation Coming Soon
- Lesson: Accessibility Coming Soon