[css-selectors] Improve the usefulness of specificity of Tags & IDs

[jensimmons]

In an effort to modernize the CSS Cascade, and make it more suitable for projects with multiple Authors writing code over many years, @mirisuzanne is thinking about Origins (and how we might extend their power), and about the Specificity of Selectors.

For context:
The Selectors Level 4 defines three levels of sectors / three levels of specificity:

A selector’s specificity is calculated for a given element as follows:
count the number of ID selectors in the selector (= A)
count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= B)
count the number of type selectors and pseudo-elements in the selector (= C)
ignore the universal selector

Miriam wrote on Twitter:

Specificity only has three layers, & only the middle (classes/attributes) layer is flexible enough for most use cases. IDs can only be used once per page, & tags need to be reused semantically. They're useful but very limited.

When everything is in a single layer, minute changes can have major impact. Everything relies on careful counting of selectors, and careful management of source order. Specificity should be more robust.

We need ways to create custom tag-layer – & reusable id-layer – selectors.

Let's talk about this. What would it look like to extend selectors so that:
• IDs can be used more than once per page
• The 'tag layer' has more customizability
• And / or other ways to empower Authors to use all three layers of specificity, instead of flattening their work into one layer.

[emilio]

• IDs can be used more than once per page

This is already the case, isn't it?

[mirisuzanne]

According to the HTML living standard, IDs must be unique on a page:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character.

I think there are very good reasons for that – IDs are used to select a single element on the page in various form/ARIA related uses – so I'm not sure that making IDs more flexible is an option here. and it does make sense to me that a unigue-ID direct selection would live at the highest level of specificity. The same is true for tag names living at the lowest level. The two use-cases that would be particularly helpful in development are:

1. The ability to create more flexible/targeted "defaults" that are easy to override. That could happen in a number of ways, including the proposed !default flag ([css-cascade] !default declarations proposal #2272), custom origins ([css-cascade] Custom Cascade Layers (formerly "custom origins") #4470), a new layer of specificity, or flexible (class-like) additions to the tag layer.
2. The ability to consider some repeatable "components" more specific than other repeatable "patterns" – like an "article-summary" card is more specific than the "card" pattern it uses, even though both repeat on a page.

While point 2 can be handled with multiple classes, it feels like we're missing out on the power that specificity layering would provide to ensure that specific components always override more general patterns, which always override broad defaults.

I don't think we need a lot of layers – 3-5 seems about right – but our current 3 don't provide the flexibility required for the common use-cases.

[SebastianZ]

According to the HTML living standard, IDs must be unique on a page:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character.

Right, but what Emilio referred to was that the Selectors spec. also handles the case of invalid HTML documents defining multiple IDs:

An ID selector represents an element instance that has an identifier that matches the identifier in the ID selector. (It is possible in non-conforming documents for multiple elements to match a single ID selector.)

Sebastian

[mirisuzanne]

Sure. I guess I'd question if that's really something to encourage? Unique IDs seem important for various semantics/accessibility issues, and I'd want to be careful about pushing a solution that might cause more accessibility issues.

[SebastianZ]

Of course it's rather something that should be discouraged. As you say, IDs should be unique. I just mentioned that in regard of Jen's point of IDs being used more than once on a page and Emilio's response to it.

Sebastian

[mirisuzanne]

@jensimmons Is this something we still want to look into more? I think we've basically covered the use-cases here with a combination of @layer (as a higher-level structural fix), and :where()/:is() allowing more detailed specificity manipulation. Should we close the issue?

[jensimmons]

If you think it's covered, then it sounds good to me.