CSS and Specificity

Post from November 27, 2014 (↻ October 2, 2017), filed under Web Development.

This and many other posts are also available as a pretty, well-behaved e-book: 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 reasonable 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 very promising with the graph itself. We should follow his work there.)

More importantly, I wonder what we’ve missed in the community when it comes to setting some CSS fundamentals straight. Here are a few loose talking points, for I’m 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.

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

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

• Also consequentially, classes are useful when used for recurring, not sufficiently accessible elements, or elements that benefit from combined naming (i.e., carrying more than one class names).

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

• It’s still absolutely 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 some of us still wonder about it, selector performance effectively doesn’t matter. (And for projects where it does matter, these are usually suffering from highly critical but entirely different issues whose alleviation solves the performance ones.)

Yet at the end of the day, there’s no set formula. There are several roads that lead to Rome, even for us who prefer minimal, tailored code. And there are always ways to offset 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 personally remember, and gladly so, was Anne.

About the Author

Jens Oliver Meiert is an author and developer (O’Reilly, W3C, ex-Google). He plays with philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences. (Beware: More often than he wants it he’s wrong.)

There’s more Jens in the archives and at Goodreads. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Read More

Have a look at the most popular posts, possibly including:

• Questioning Electronic Data as Evidence
• The Problems of Working with Web Agencies

Looking for a way to comment? Comments have been disabled, unfortunately.