- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Apr 2025 14:30:18 +0000
- To: public-css-archive@w3.org
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``
<details><summary>The full IRC log of that discussion</summary>
<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<br>
<emeyer> …There are HTML attributes that let you adjust the level of headings in a subtree, so this is relevant again<br>
<emeyer> …Anything we do here should be contigent on the HTML thing actually happens<br>
<emeyer> …Proposal is to allow `:heading(an + b)` that applies to adjusted heading levels rather than tag names<br>
<kizu> q+<br>
<astearns> ack kizu<br>
<emeyer> kizu: I support this<br>
<TabAtkins> (comma-separated list of an+b expressions)<br>
<emeyer> …Do we want to have a shortcut to allow `:heading(n)`<br>
<emeyer> TabAtkins: Yes<br>
<emeyer> astearns: Proposed resolution is allow comma-separated list of an+b expressions to apply to adjusted heading levels<br>
<emeyer> …Seeing no objections,<br>
<emeyer> RESOLVED: Add `:heading()` that accepts a comma-separated list of an+b expressions<br>
<emeyer> TabAtkins: All the UA stylesheets apply to headings by tag names, which has tag-level specificty<br>
<emeyer> …A `:heading()` would by default of class specificity<br>
<emeyer> …Is that a problem?<br>
<kbabbitt> q+<br>
<astearns> ack kbabbitt<br>
<emeyer> …Should we say `:heading()` has tag specificity rather than tag specificity?<br>
<kizu> q+<br>
<emeyer> kbabbitt: To the extent this would juggle rule application order, that would be confined to the UA stylesheet, right?<br>
<emeyer> TabAtkins: Yes<br>
<emeyer> kbabbitt: So the implementor could rejuggle styles<br>
<emeyer> TabAtkins: Yes, but author styles might get overridden byu the new UA styles if this has class specificity<br>
<emeyer> kbabbitt: Ah, so that’s the concern, is that clash<br>
<emeyer> TabAtkins: Yes, it’s representative<br>
<astearns> change my h1, h2, h3, h4, h5, h6{} rule to :heading{}<br>
<emeyer> …of the general class of concerns<br>
<kurt> *:heading()?<br>
<emeyer> astearns: I think there’s good reason to define this as having tag specificity<br>
<TabAtkins> (the workaround is `:is(div:not(*), :where(:heading))`)<br>
<emeyer> kbabbitt: Do we have other pseudos that do this?<br>
<emilio> q+<br>
<emeyer> TabAtkins: No; we don’t have any pseudos that stand in for tag nakmes except maybe :any-link<br>
<astearns> ack kizu<br>
<emeyer> kizu: It’s basically an alias to the adjusted tag names, so tag specificity makes sense here<br>
<astearns> ack emilio<br>
<emeyer> q+<br>
<kbabbitt> s/is that clash/is authors adopting the new pseudo and getting surprising results/<br>
<emeyer> emilio: Have we checked if changing the UA style sheet will result in conflict?<br>
<emeyer> …I agree that migrating to H-tags to this makes tag specificity appealing<br>
<emeyer> …But having a pseudo with tag specificity is odd<br>
<kizu> `:is(h1,h2,h3)` — also a pseudo-class with tag specificity, kinda<br>
<emeyer> …What about attribute selectors?<br>
<emeyer> TabAtkins: They’re exactly class level<br>
<emeyer> emilio: …I’d rather keep to class specificity for consistency, unless we find out it breaks lots of things<br>
<bramus> +1 on staying consistent<br>
<emeyer> …I think that’s somewhat unlikely<br>
<emeyer> astearns: I’m not that concerned about the user stylesheets<br>
<emeyer> …There are likely to be UA rules that can’t use the new thing for whatever reason<br>
<emeyer> …I’m worried about defining this thing and then making it so you can’t use it without knowing the special incantation<br>
<emeyer> TabAtkins: I’m pretty evenly divided on this<br>
<astearns> ack emeyer<br>
<TabAtkins> scribe+<br>
<kizu> one of workarounds: `:is(:not(h1, :not(h1)), :where(:heading(1, 2, 3)))`<br>
<lea> What about role=heading aria-level=N?<br>
<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?<br>
<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.<br>
<lea> That’s not like :where, :where has 0 soecificity. It’s more like :is or :not<br>
<emeyer> TabAtkins: Ths issue is all things you can do here, you could do with `:is()`<br>
<astearns> ack dbaron<br>
<TabAtkins> (it's always tag-equivalent when you desugar it)<br>
<emeyer> dbaron: I worry about the cost of making rules more complex for everybody<br>
<emeyer> …For implementors, for authors<br>
<emilio> 1+<br>
<emeyer> …This feels like a case of adding more magic, and probably isn’t worth more magic<br>
<emilio> +1*<br>
<emeyer> …The additional overhead of learning and understanding isn’t worth it<br>
<emeyer> …I don’t feel strongly about this, but that’s where I lean<br>
<ntim> +1 to dbaron<br>
<emeyer> astearns: The sense of the room is that making an exception is not motivated enough<br>
<emeyer> …So we should open this to a wider audience to see how people will use this<br>
<emeyer> TabAtkins: Like IDs exist only for IDs, tags exist to apply to tags, so it’s probably unlikely to cause issues in practice<br>
<emeyer> …I think having :heading() being class specificity should be safe<br>
<kizu> `.foo { … } h1 { … } <h1 class="foo">` — replacement here will not be safe<br>
<emeyer> astearns: Since that’s what falls out of the definition, do we need a resolution?<br>
<emeyer> TabAtkins: Let’s record the sense of the room<br>
<emeyer> astearns: Objections?<br>
<emeyer> (none)<br>
<emeyer> RESOLVED: `:heading()` has the expected class-level specificity<br>
<emeyer> astearns: Lea asked about ARIA heading roles<br>
<emeyer> TabAtkins: That’s up to HTML, not our problem<br>
<emeyer> astearns: Fair enough<br>
<dbaron> I think in general aria attributes don't affect non-a11y things, though.<br>
<TabAtkins> ("what are headings" and "what level are they" is a host-language problem)<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10296#issuecomment-2775988542 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 April 2025 14:30:19 UTC