Thanks Tamm! I was feeling pretty pleased with myself about that one until someone pointed out that you could instead just do:

:root :where(#widget) {
  /* ... */
}

…which is much cleaner IMO. Noting that :root has the same specificity as a class, 0,1,0

✔️ total hack

@Dan Christofi
Interesting. It’s good that phpstorm /jetbrains do this. Though I’m guessing you still can’t do an all-of-codebase search for “card__title”?

I just tried your suggestion in my editor (VS Code) and it does not work. Having said that, it doesn’t work even without the Sass nesting. I imagine there’s some add-on/setting I need to enable.

Even so, the lack of a reliable codebase text search is a deal-breaker for me, personally.

If you use phpstorm (or other jetbrains ides I assume) then the &__title format will work. It lets you command/ctrl click on the class name and the program is able to link you to the correct css.

Not sure about other programs but there may be plugins available to help with this.

Good suggestion, Jonathan.
I only very recently (last week) learned that the :root selector has a specificity of 0,1,0. That’s certainly a more elegant way to do it that my hacky ideas :)

If you need a root selector for :where(), like in the last example:

/* ✅ specificity score: 0,1,0 */
:is(.dummy-class, body) :where(#widget) {
/* etc. */
}

I think you could use just :root

:root :where(#widget) {
/* etc. */
}

Whoops! I had updated that cursed code block after a different error was pointed out, but didn’t update the explanation below. All fixed!

I thought that this was an excellent article. I know it wasn’t your primary goal for this article, but I thought the description of the benefits of BEM was clearer than most of the other articles I’ve read on the subject.

Personally, I prefer SUIT CSS naming – we use the naming conventions, not the other SUIT tools. I prefer SUIT because the naming choices fits better with our other code (Typescript and C#). We’re not purists about it, we use combination (child or sibling) selectors to make the names easier to read and maintain in HTML – which does affect specificity.

With :where and :is and Cascade Layers, which all have good support in evergreen browsers, we now have the tools for naming conventions to prioritize clean HTML and CSS design, without worrying so much about specificity. I think there could be a next gen of BEM or SUIT (or any other naming convention) that improves clarity by removing the specificity requirement that constrained the previous design.

BEM offers several advantages, other than just helping with specificity.

For instance, another thing I like about BEM is that it makes it clear which elements you’re directly styling. E.g. imagine a “card” component’s “title”. You could do:

.card :where(h3) { ... }

But what happens when you decide they should actually be h2s or h4s? You’d need to ensure the html was updated too. And it wouldn’t be easy to know which, if any, CSS to remove if you removed something like this from the HTML.

(I realise that you don’t need to be using BEM to think to add a class to your h3 element – but the point is, with BEM it’s an expectation that you add it to anything you want to style).

The second part of your question was about simpler class names. I get that no one likes to type out .really__loooooong–classnames all the time. But that gets me to the next other thing I like about BEM – uniqueness. Adding the full context to each class means I can more easily search for and find their usages. For instance, I can search for card__title and know I’m not getting any “title”s from other components. This is why I avoid this style of Sass nesting:

.card {
  /* etc */

  &__title { ... }
}

Good that it doesn’t increase specificity, but bad that you can’t reliably find code usages.

All that being said, you don’t need to use BEM specifically to achieve these same principles. Ultimately this will boil down to your (and your team’s) preferred way of working. If you want to have an “element”-equivalent class that looks like .card-title, go nuts. The main point of this article was about managing specificity. BEM is (still) widely used, so I focused on that :)

Oh yikes, I goofed up, that’s why! We’ll get that updated in the post. Good catch, thank you :)

Oh [id="widget"] is a really great point, I’d totally forgotten about that!