Feature request: Add pseudo-class/pseudo-element specificity data

[lifeiscontent]

Summary

It would be helpful to have specificity information for CSS pseudo-classes and pseudo-elements, indicating their relative priority when multiple pseudo-selectors are used.

Use Case

CSS-in-JS libraries need to output pseudo-class styles in the correct order to ensure proper cascade behavior. For example:

a:link { }     /* should come before :visited */
a:visited { }  /* should come before :hover */
a:hover { }    /* should come before :active */
a:active { }   /* highest priority among LVHA */

The LVHA order (Link, Visited, Hover, Active) is well-known, but there are many other pseudo-classes with implicit ordering requirements.

Current State

The selectors data includes pseudo-classes and pseudo-elements but no specificity or priority information:

{
  "name": ":hover",
  ...
}

Proposed Enhancement

Add priority/specificity data to pseudo-selectors:

{
  "name": ":link",
  "type": "pseudo-class",
  "specificityGroup": "lvha",
  "priorityInGroup": 1,
  ...
}
{
  "name": ":visited",
  "type": "pseudo-class", 
  "specificityGroup": "lvha",
  "priorityInGroup": 2,
  ...
}
{
  "name": ":hover",
  "type": "pseudo-class",
  "specificityGroup": "lvha", 
  "priorityInGroup": 3,
  ...
}
{
  "name": ":active",
  "type": "pseudo-class",
  "specificityGroup": "lvha",
  "priorityInGroup": 4,
  ...
}

Or a simpler numeric priority:

{
  "name": ":hover",
  "pseudoPriority": 10,
  ...
}
{
  "name": ":active",
  "pseudoPriority": 20,
  ...
}
{
  "name": ":focus",
  "pseudoPriority": 15,
  ...
}

Affected Selectors

Key pseudo-classes that need ordering:

• :link, :visited, :hover, :active (LVHA order)
• :focus, :focus-visible, :focus-within
• :disabled, :enabled
• :checked, :indeterminate
• Structural pseudos (:first-child, :last-child, etc.)

[cdoublev]

Your example is not about selector specificity but order of appearance.

Assuming you declared color in each style rule, each declaration would have the same specificity, but the declaration in the last style rule would be applied if the anchor element is :active.

Anyway, there is no specificity specific to pseudos between them. All non-functional pseudos (and element types) have the same specificity,

[tidoust]

I agree that the term "specificity" is wrong here. My understanding is that the request is indeed about understanding when selectors are directly related in a way that makes their order of appearance (when selector specificity is otherwise the same) important in a stylesheet, typically because one selector encompasses another.

Now, I think that the order that tools produce and/or MDN suggests is sometimes more "good practice" than a requirement. Not sure that the data should create an order in these cases:

• In the well-known LVHA order, the :link and :visited states are mutually exclusive, their relative order shouldn't matter.
• Same thing for :disabled and :enabled.
• And same thing for :checked, :unchecked and :indeterminate.

I'm also not sure what, if anything, to say about the order of appearance of :first-child, :last-child, :first-of-type, etc. That seems context dependent?

(Side note: the LVHA order seems to forget :any-link, which should probably come first)

[lifeiscontent]

Thanks for the corrections, @cdoublev and @tidoust. You're right - I used "specificity" incorrectly when I meant "cascade order" or "appearance order."

Let me reframe the actual need: CSS-in-JS libraries that generate atomic CSS (one class per declaration) need to emit pseudo-class selectors in a deterministic order so that the cascade produces expected results.

@tidoust makes excellent points:

• :link/:visited are mutually exclusive, so their relative order doesn't matter
• Same for :enabled/:disabled and :checked/:indeterminate
• :any-link should precede :link and :visited

What would actually be useful is a "can overlap with" or "conflicts with" relationship between pseudo-classes. For LVHA, :hover can coexist with :active, so their order matters. But :link and :visited can't coexist, so order is irrelevant.

I suspect this might be too nuanced/opinionated for webref to encode. Perhaps the simpler approach is for downstream tools (like mine) to maintain their own ordering logic based on the pseudo-class definitions that webref already provides.

Happy to close this if the consensus is that it's out of scope.