Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-cascade] Clarify the specificity of a declaration. #11305

Open
Alohci opened this issue Dec 1, 2024 · 6 comments · May be fixed by #11445
Open

[css-cascade] Clarify the specificity of a declaration. #11305

Alohci opened this issue Dec 1, 2024 · 6 comments · May be fixed by #11445

Comments

@Alohci
Copy link
Contributor

Alohci commented Dec 1, 2024

Every Cascade spec level from 3 to 6 contains the same text for the specificity of a declaration - "Each declaration has the same specificity as the style rule it appears in."

But as far as I can tell, nothing says what the specificity of a rule is. After all what is the specificity of this rule?

p, #x, .y { color: red }

I think the text should say something like "Each declaration has the same specificity as the highest specificity matching selector belonging to the rule it appears in."

@SelenIT
Copy link
Collaborator

SelenIT commented Dec 2, 2024

The [selectors] spec section linked from that paragraph contains the detailed algorithm of specificity calculation, including the following paragraph:

If the selector is a selector list, this number is calculated for each selector in the list. For a given matching process against the list, the specificity in effect is that of the most specific selector in the list that matches.

It doesn't strictly declare the equivalence between "the specificity in effect" and "the specificity of the rule" (though strongly implies it), but seems quite unobvious which specificity value will be in effect for any given selector, and therefore for the rule associated with it. IMO making the text too verbose while providing the link to the detailed algorithm would be not very useful, however a minor editorial change to remove the rest of ambiguity from it could be helpful.

@bramus
Copy link
Contributor

bramus commented Dec 3, 2024

The [selectors] spec section linked from that paragraph contains the detailed algorithm of specificity calculation

This links to https://www.w3.org/TR/selectors/#specificity which explains how to calculate specificity.

@bramus bramus closed this as completed Dec 3, 2024
@bramus bramus added the Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. label Dec 3, 2024
@bramus
Copy link
Contributor

bramus commented Dec 3, 2024

Oh wait, reopening as I didn’t see your suggestion at the end there.

@bramus bramus reopened this Dec 3, 2024
@bramus bramus removed the Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. label Dec 3, 2024
@bramus
Copy link
Contributor

bramus commented Dec 3, 2024

I think the text should say something like "Each declaration has the same specificity as the highest specificity matching selector belonging to the rule it appears in."

Technically even better is to say that declarations have no specificity, because it’s the selector that determines that.

@SelenIT
Copy link
Collaborator

SelenIT commented Dec 3, 2024

Maybe the text like this would be better than existing one?

The Selectors module [SELECT] describes how to compute the specificity of a selector. The declaration from the style rule with the highest specificity of the selector wins.

@Alohci
Copy link
Contributor Author

Alohci commented Dec 3, 2024

The Selectors module [SELECT] describes how to compute the specificity of a selector. The declaration from the style rule with the highest specificity of the selector wins.

That works for me. Getting rid of the notion of declarations and rules having specificity seems the neatest approach.

bramus added a commit to bramus/csswg-drafts that referenced this issue Jan 6, 2025
@bramus bramus linked a pull request Jan 6, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants