Re: [csswg-drafts] [css-anchor-position] Let more pseudo-elements have implicit anchor elements (#11792)

The CSS Working Group just discussed `[css-anchor-position] Let more pseudo-elements have implicit anchor elements`, and agreed to the following:

* `RESOLVED: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: Anchor Positioning defines notion of an "implicit" anchor element, a relationship that other web platform features can define<br>
&lt;fantasai> TabAtkins: e.g. for &lt;select> picker, the implicit anchor is the &lt;select><br>
&lt;fantasai> TabAtkins: We've also talked about making ::scroll-marker-group implicitly attached to the scroll container<br>
&lt;fantasai> TabAtkins: More general question is, do we want to apply this generally for pseudo-elements<br>
&lt;fantasai> TabAtkins: so for any tree-abiding pseudo, should it have an implicit anchor element of its originating element<br>
&lt;fantasai> TabAtkins: I think it's a reasonable idea<br>
&lt;ntim> q+<br>
&lt;astearns> ack ntim<br>
&lt;fantasai> TabAtkins: That way a ::before pseudo can be automatically anchored to its element<br>
&lt;fantasai> ntim: I could see this being useful for forms<br>
&lt;fantasai> ntim: If you use ::after or ::before or whatever<br>
&lt;fantasai> ntim: Can anchor tooltips easily without extra work<br>
&lt;fantasai> TabAtkins: for forms, there might enough structure sometimes to allow someoverridden<br>
&lt;fantasai> TabAtkins: e.g. might want something to attach to thumb of a slider<br>
&lt;fantasai> TabAtkins: I suggest we define that by default, imply the originating element<br>
&lt;kizu> +1<br>
&lt;fantasai> TabAtkins: but other specs can override<br>
&lt;fantasai> ntim: Is this web-compatible?<br>
&lt;fantasai> TabAtkins: Right now if you don't specify a position-anchor, all of your anchor references just wouldn't work<br>
&lt;fantasai> TabAtkins: so seems pretty unlikely that ppl are depending on broken behavior for this right now<br>
&lt;fantasai> TabAtkins: we'll see, but I think this is safe<br>
&lt;fantasai> &lt;fantasai> +1<br>
&lt;fantasai> astearns: If it was out in the wild longer, might have more worries, but<br>
&lt;fantasai> fantasai: Not even been a year since shipping anchorpos<br>
&lt;fantasai> PROPOSED: All tree-abiding pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined<br>
&lt;fantasai> fantasai: should it be all pseudo-elements?<br>
&lt;fantasai> TabAtkins: ok sure<br>
&lt;fantasai> TabAtkins: not observable<br>
&lt;fantasai> fantasai: but makes less of a maintenance problem if later it is<br>
&lt;fantasai> PROPOSED: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined<br>
&lt;fantasai> astearns: Other questions/comments on proposed resolution?<br>
&lt;fantasai> astearns: objections?<br>
&lt;fantasai> RESOLVED: All pseudo-elements use their originating element as their implicit anchor element, unless otherwise defined<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11792#issuecomment-2776494052 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 17:34:33 UTC