[selectors] Adding a :heading() selector for headingoffset?
#10296
Comments
|
Huge +1 to this. Low-hanging fruit, and likely easy to implement (for UAs already implementing |
astearns
moved this from By Topic
to Wednesday Morning
in CSSWG April 2025 meeting agenda
|
The CSS Working Group just discussed
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) |
|
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 The raised specificity is a nice feature IMO, and I'd advise authors use |
|
Could we have a parentheses-less |
My intent would be to also add the paren-less |
|
@keithamus Would That just seems a little weird, and I think that's mentioned in the IRC log as a gotcha to teach: "Pseudo-classes behave like classes and have the same specificity, except Let's say we had a special selector for form input elements like If it has to have an element-level specificity, then it would make more sense to be Anyways, sorry, this is nit-picky and perhaps a little off-topic, just seems an important point to keep in mind. While I know CSS has its historical list of mistakes, moving forward, being consistent (the letters "CSS" are in the word) seems like a good idea. PS: sorry for the abundant use of the word "specificity". 🫠 |
My recollection is that we did want But @keithamus I’m not seeing where your PR says anything about the specificity the new pseudo-element. The resolution above about making it class-level is meant for We did have folks arguing for tag-level specificity instead of class-level specificity overall, but “consistency with other pseudo-elements” won the case yesterday. We can always revisit the question, but please don’t add tag-level specificity to the spec until we have done that. |
I miss-typed, I meant to say class-level not element-level.
Right now it does not, I have yet to update it post-resolution. I will when I get back to my desk on Monday.
Right, no need. It'll be class-level specificity for both. |
|
I missed the issue in the f2f but I think tag-level specificity makes sense and may be worth the inconsistency, though that’s a weak opinion. I don’t understand why we’d also add a pseudo-element. It seems that a pseudo-class suffices just fine. |
|
Is it possible that somewhere there was a bit of confusion between I thought this proposal only adds a pseudo class, which can be written both in functional and non-functional notation? |
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 level2(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
headingoffsetis 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 leveln. An<h1>(with noheadingoffsetparents) would then be selectable as either:heading(1)orh1, 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-levelorrole=headingshould 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 toh1, :heading(1){}. I know this looks scarily like the old document outline but asheadingoffsetis both explicit and opt in, I'm confident this doesn't introduce the same issus as document outlines.Thoughts?
The text was updated successfully, but these errors were encountered: