CSS and Specificity

Post from November 27, 2014 (↻ June 5, 2021), filed under Web Development (feed).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

Specificity is one of CSS’ greatest features, though an area that is as challenging as it is important to manage on projects of any decent size. Specificity is something a web developer needs to master, and that includes knowing when to use IDs, when (and why) to nest selectors, and also when to use !important.

With that I gently nudge Harry to reconsider some of the premises in his post on the specificity graph and, if possible, to build a stronger case. (Yet I do think Harry’s on to something promising with the graph itself. We should follow his work there.)

In general, however, I wonder what we’ve missed in the community when it comes to getting CSS fundamentals right. Here are a few loose talking points, for I am was slowly retreating once my next two web development books—more soon!—are out:

• The cascade is a pillar of CSS and web developers need to thoroughly understand it.

• It pays to use all features of the cascade, for they all have uses and benefits. That features can be misused is not a good reason to nail all doors and windows.

• Specifically, it can be useful to “nest” selectors if that reflects the markup and keeps it cleaner.

• Specifically, IDs are useful when used for unique and more relevant elements.

• Specifically, classes are useful when used for recurring, not sufficiently “selectable” elements, or elements that benefit from combined naming (i.e., to carry more than one class names).

• It can also be useful not to use any IDs or classes, as that serves markup purity.

• It’s still critical to avoid presentational names (this applies to custom elements, too; there are no excuses for “clearfix” or “hidden”) and to use functional or generic names instead.

• As a still current topic, selector performance effectively doesn’t matter. (For projects where selector performance does matter, the problems with selectors are usually a symptom with a cause found elsewhere.)

Yet at the end of the day, there’s no set formula. There are “several roads leading to Rome,” even for us who prefer minimal, tailored code. And there are always ways to mitigate issues, as with proper documentation.

My cordial greetings to Harry, who I’ve on more than one occasion tried to hire at Google. I’d still love to see him there, and see him thrive (though he’ll do that anywhere). Harry is one of a few young rockstars whose rise you can follow now; the first I’ve felt similar about was Anne.

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!