We added selector-max-specificity to Stylelint before the introduction of specificity-changing pseudo-classes like :is(), :where(), :not() and :has(). Having thought about it some more, I'm not sure the rule is useful these days.

Due to these pseudo-classes, it makes a poor proxy for controlling selector complexity and for disallowing ID selectors. For example, both these selectors have a specificity of 0,0,0:

:where(#id),
:where(a.complex[attr], #id) {}

And makes a poorer proxy for disallowing other types of selectors as it groups them:

• B = the number of class selectors, attributes selectors, and pseudo-classes
• C = the number of type selectors and pseudo-elements

It'd be good to hear if people have another use for this rule.

If you do keep it, the implementation should probably consider these specificity-changing pseudo-classes and nesting, which is Baseline 2023.

In Stylelint, we use @csstools/selector-specificity for calculating the specificity, which supports the specificity-changing pseudo-classes and elements. We also desugar nested selectors before passing them to the calculator. However, we don't yet desugar to :is() (as our current implementation predates the latest CSS nesting spec):

a, b { 
  & c {} 
}

/* should be desugared to */
:is(a, b) c {}

/* be we currently desugar to */
a c, b c {}

This can lead to different specificities, and our calculations may not match the browser.

Interesting. I think I'll need to dig into this a bit more.

Take a look at bramus/specificity. It appears to to cover all the key aspects of selector specificity calculation according to the latest CSS specifications. Since it’s built on top of CSSTree, it might be a good candidate for adoption instead of implementing a custom specificity calculation from scratch (see calculate.js).

@lahmatiy thanks! We're actually discussing over on #19 whether or not specificity even makes sense as a measure of selector complexity anymore. Would love to hear your thoughts.

Hi @nzakas!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the pull request title to match this format, as we use it to generate changelogs and automate releases.

• The commit message tag wasn't recognized. Did you mean "docs", "fix", or "feat"?
• There should be a space following the initial tag and colon, for example 'feat: Message'.

To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page.

Read more about contributing to ESLint here