Document !important caveat in no-descending-specificity

[pke]

Describe the issue. Is it a bug or a feature request (new rule, new option, etc.)?

A bug where the rule claims wrong ordering.

Which rule, if any, is this issue related to?

no-descending-specificity

What CSS is needed to reproduce this issue?

a,
a:hover,
a:active {
  color: #6c9cd3;
}

footer a {
  color: white !important; /* override all links */
}

What stylelint configuration is needed to reproduce this issue?

"stylelint": "^8.3.1",
"stylelint-config-standard": "^18.0.0",

Which version of stylelint are you using?

8.3.1

How are you running stylelint: CLI, PostCSS plugin, Node API?

npm with stylelint "src/**/*.css"

Does your issue relate to non-standard syntax (e.g. SCSS, nesting, etc.)?

no

What did you expect to happen?

No warnings to be flagged

What actually happened (e.g. what warnings or errors you are getting)?

The following warnings were flagged:

 72:1  ×  Expected selector "footer a" to come before selector "a:hover"          no-descending-specificity
 72:1  ×  Expected selector "footer a" to come before selector "a:active"         no-descending-specificity
 78:1  ×  Expected selector "a:focus" to come before selector "footer a:hover"    no-descending-specificity
 78:1  ×  Expected selector "a:focus" to come before selector "footer a:active"   no-descending-specificity

[hudochenkov]

Thanks for the report and for using the template.

Rule checks selectors only. It doesn't check declarations in a rule, and whether rule with lower selector specificity has declaration which is outweights declaration in a rule with higher selector specificity.

a:hover has specificity 0,0,1,1. footer has specificity 0,0,0,2. Rule works as expected.

On the other side it's still show violations if there is a clearly a set of more specific selectors:

a,
a:hover,
a:active {
  color: #6c9cd3;
}

footer a,
footer a:hover,
footer a:active {
  color: white;
}

 7:1  ✖  Expected selector "footer a" to come before selector "a:hover"    no-descending-specificity
 7:1  ✖  Expected selector "footer a" to come before selector "a:active"   no-descending-specificity

While rule is still works as expected and reports correctly, it feels incorrect.

You can disable violation for this use case:

a,
a:hover,
a:active {
    color: #6c9cd3;
}

/* stylelint-disable-next-line no-descending-specificity */
footer a {
    color: white;
}

[jeddy3]

Rule checks selectors only. It doesn't check declarations in a rule, and whether rule with lower selector specificity has declaration which is outweights declaration in a rule with higher selector specificity.

@hudochenkov Thanks for digging into this. I suggest we document this caveat.

[aloxe]

There is a similar glitch with no-descending-specificity when using the same version of stylelint and stylelint-config-standard

table.class0.class1 tr { color: plum; }

table.class2 tr { color: lime; }

ol.class0.class1 li { color: orange; }

ul.class2 li { color: olive; }

Here I don't feel like any rule is more specific than another so I don't expect and message, nevertheless I get :

Expected selector "table.class2 tr" to come before selector "table.class0.class1 tr"  no-descending-specificity
Expected selector "ul.class2 li" to come before selector "ol.class0.class1 li"        no-descending-specificity

If this is a normal behaviour this should be documented too.

[jeddy3]

Here I don't feel like any rule is more specific than another

In the two violations above, the rules are more specific e.g. both table.class0.class1 tr and ol.class0.class1 li have a specificity of 0,2,2, while table.class2 tr and ul.class2 li only have a specificity of 0,1,2. So, I believe the rule is behaving as documented in this instance:

If a selector with higher specificity comes before the selector it overrides, we have to think harder to understand it, because it violates the source order expectation

Here's how it works: This rule looks at the last compound selector in every full selector, and then compares it with other selectors in the stylesheet that end in the same way.

Having said that, I wonder whether the worth of this rule is diminished in this instance as the parent is different in both instances. In that regard, this instance feels related to #2489, which is to do with parents and pseudo-classes. Perhaps once that issue is resolved (@aloxe, feel free to pick it up), then we'll have to clearer picture of how to address your particular instance.

[github-actions]

This issue is older than one month. Please ask before opening a pull request, as it may no longer be relevant.