[selectors] Adding a `:heading()` selector for headingoffset?

[keithamus]

whatwg/html#5033 proposed to add a new attribute (now called headingoffset) which can offset a containers exposing heading level by a given amount, for example <div headingoffset=1><h1></h1></div> renders a heading with a level 2 (1+1 = 2) in the accessibility tree.

This begs the question if it's possible to somehow correctly style elements according to their computed offset. Given headingoffset is accumulative (it does a flat tree walk) it can be quite difficult to appropriately select for such combinations.

So, here I am, proposing a pseudo selector to allow for selecting the computed heading level. I propose :heading(n) as a selector for heading elements exposes as level n. An <h1> (with no headingoffset parents) would then be selectable as either :heading(1) or h1, but for example <div headingoffset=1><div headingoffset=2><h1></h1></div></div> would be selectable as :heading(4) (1+2+1 = 4).

I want to stress that I am of the opinion that aria-level or role=heading should not impact :heading(); they are readily selectable today and I don't think aria should have that dramatic an impact on other selectors.

I think it would be really helpful for us to consider adjusting the UA stylesheets such that the existing for styles like h1{} are extended to h1, :heading(1){}. I know this looks scarily like the old document outline but as headingoffset is both explicit and opt in, I'm confident this doesn't introduce the same issus as document outlines.

Thoughts?

[Crissov]

#351 is related: :level(). Incidentally, I recently started to think about combining hierarchical and nesting level again, but do not have a more concrete proposal yet.

#3596 would bring :role(heading) to the table, but has no concept of hierarchic level.

[LeaVerou]

Huge +1 to this. Low-hanging fruit, and likely easy to implement (for UAs already implementing headingoffset).

[css-meeting-bot]

The CSS Working Group just discussed [selectors] Adding a `:heading()` selector for headingoffset?, and agreed to the following:

• RESOLVED: Add `:heading()` that accepts a comma-separated list of an+b expressions
• RESOLVED: `:heading()` has the expected class-level specificity

The full IRC log of that discussion

<emeyer> TabAtkins: There was a suggestion for adding a :heading to apply to all headings, and also to select to select things based onthe outline algorithm that eventually got dropped
<emeyer> …There are HTML attributes that let you adjust the level of headings in a subtree, so this is relevant again
<emeyer> …Anything we do here should be contigent on the HTML thing actually happens
<emeyer> …Proposal is to allow `:heading(an + b)` that applies to adjusted heading levels rather than tag names
<kizu> q+
<astearns> ack kizu
<emeyer> kizu: I support this
<TabAtkins> (comma-separated list of an+b expressions)
<emeyer> …Do we want to have a shortcut to allow `:heading(n)`
<emeyer> TabAtkins: Yes
<emeyer> astearns: Proposed resolution is allow comma-separated list of an+b expressions to apply to adjusted heading levels
<emeyer> …Seeing no objections,
<emeyer> RESOLVED: Add `:heading()` that accepts a comma-separated list of an+b expressions
<emeyer> TabAtkins: All the UA stylesheets apply to headings by tag names, which has tag-level specificty
<emeyer> …A `:heading()` would by default of class specificity
<emeyer> …Is that a problem?
<kbabbitt> q+
<astearns> ack kbabbitt
<emeyer> …Should we say `:heading()` has tag specificity rather than tag specificity?
<kizu> q+
<emeyer> kbabbitt: To the extent this would juggle rule application order, that would be confined to the UA stylesheet, right?
<emeyer> TabAtkins: Yes
<emeyer> kbabbitt: So the implementor could rejuggle styles
<emeyer> TabAtkins: Yes, but author styles might get overridden byu the new UA styles if this has class specificity
<emeyer> kbabbitt: Ah, so that’s the concern, is that clash
<emeyer> TabAtkins: Yes, it’s representative
<astearns> change my h1, h2, h3, h4, h5, h6{} rule to :heading{}
<emeyer> …of the general class of concerns
<kurt> *:heading()?
<emeyer> astearns: I think there’s good reason to define this as having tag specificity
<TabAtkins> (the workaround is `:is(div:not(*), :where(:heading))`)
<emeyer> kbabbitt: Do we have other pseudos that do this?
<emilio> q+
<emeyer> TabAtkins: No; we don’t have any pseudos that stand in for tag nakmes except maybe :any-link
<astearns> ack kizu
<emeyer> kizu: It’s basically an alias to the adjusted tag names, so tag specificity makes sense here
<astearns> ack emilio
<emeyer> q+
<kbabbitt> s/is that clash/is authors adopting the new pseudo and getting surprising results/
<emeyer> emilio: Have we checked if changing the UA style sheet will result in conflict?
<emeyer> …I agree that migrating to H-tags to this makes tag specificity appealing
<emeyer> …But having a pseudo with tag specificity is odd
<kizu> `:is(h1,h2,h3)` — also a pseudo-class with tag specificity, kinda
<emeyer> …What about attribute selectors?
<emeyer> TabAtkins: They’re exactly class level
<emeyer> emilio: …I’d rather keep to class specificity for consistency, unless we find out it breaks lots of things
<bramus> +1 on staying consistent
<emeyer> …I think that’s somewhat unlikely
<emeyer> astearns: I’m not that concerned about the user stylesheets
<emeyer> …There are likely to be UA rules that can’t use the new thing for whatever reason
<emeyer> …I’m worried about defining this thing and then making it so you can’t use it without knowing the special incantation
<emeyer> TabAtkins: I’m pretty evenly divided on this
<astearns> ack emeyer
<TabAtkins> scribe+
<kizu> one of workarounds: `:is(:not(h1, :not(h1)), :where(:heading(1, 2, 3)))`
<lea> What about role=heading aria-level=N?
<TabAtkins> emeyer: is there a way we can make it so that... you know how :where() doesn't have specificity implications, can we do something related so it has specificity of the things inside it?
<TabAtkins> emeyer: so :heading(1) that's equivlaent to `h1`, if I have :heading(n+4), can we have the thing in the parens convey the specificity.
<lea> That’s not like :where, :where has 0 soecificity. It’s more like :is or :not
<emeyer> TabAtkins: Ths issue is all things you can do here, you could do with `:is()`
<astearns> ack dbaron
<TabAtkins> (it's always tag-equivalent when you desugar it)
<emeyer> dbaron: I worry about the cost of making rules more complex for everybody
<emeyer> …For implementors, for authors
<emilio> 1+
<emeyer> …This feels like a case of adding more magic, and probably isn’t worth more magic
<emilio> +1*
<emeyer> …The additional overhead of learning and understanding isn’t worth it
<emeyer> …I don’t feel strongly about this, but that’s where I lean
<ntim> +1 to dbaron
<emeyer> astearns: The sense of the room is that making an exception is not motivated enough
<emeyer> …So we should open this to a wider audience to see how people will use this
<emeyer> TabAtkins: Like IDs exist only for IDs, tags exist to apply to tags, so it’s probably unlikely to cause issues in practice
<emeyer> …I think having :heading() being class specificity should be safe
<kizu> `.foo { … } h1 { … } <h1 class="foo">` — replacement here will not be safe
<emeyer> astearns: Since that’s what falls out of the definition, do we need a resolution?
<emeyer> TabAtkins: Let’s record the sense of the room
<emeyer> astearns: Objections?
<emeyer> (none)
<emeyer> RESOLVED: `:heading()` has the expected class-level specificity
<emeyer> astearns: Lea asked about ARIA heading roles
<emeyer> TabAtkins: That’s up to HTML, not our problem
<emeyer> astearns: Fair enough
<dbaron> I think in general aria attributes don't affect non-a11y things, though.
<TabAtkins> ("what are headings" and "what level are they" is a host-language problem)

[chriskirknielsen]

Seems this had been discussed outside of this specific issue in the past, but just for clarity: in this proposal, would an empty argument for :heading() open up the possibility of replacing a standard h1, h2, h3, h4, h5, h6 selector list?

The raised specificity is a nice feature IMO, and I'd advise authors use :is(h1, :where(:heading())) if they want to get back to an element-level specificity of 0,0,1 (or a similar workaround). For resets and such, the list of 6 elements seems fine: it's clearer, easier to read, and is shorter than other workarounds anyways.