[csswg-drafts] [selectors] Adding a `:heading()` selector for headingoffset? (#10296)

keithamus has just created a new issue for https://github.com/w3c/csswg-drafts:

== [selectors] Adding a `:heading()` selector for headingoffset? ==
https://github.com/whatwg/html/issues/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?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10296 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 8 May 2024 20:39:59 UTC