Re: [csswg-drafts] [css-anchor-position-1] Allow anchor references to match names in outer tree scopes (#9408)

The CSS Working Group just discussed `[css-anchor-position-1] Allow anchor references to match names in outer tree scopes`, and agreed to the following:

* `RESOLVED: Accept the edits`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> TabAtkins: this is an issue where I went ahead and synthesized feedback into a spec edit<br>
&lt;kbabbitt> ... andruud realized we didn't have a spec edit<br>
&lt;kbabbitt> ... smal change to how we resolve anchor names and references with shadow trees involved<br>
&lt;kbabbitt> ... prevoiusly could not reach out in either direction<br>
&lt;kbabbitt> ... I've dropped a small tweak in that allows an anchor name to be defined higher up in shadow tree<br>
&lt;kbabbitt> ... and anchor reference in shadows can refer to that<br>
&lt;kbabbitt> ... will do standard thing of looking up tree ignoring shadow boundaries until it finds a name<br>
&lt;adamargyle> +1<br>
&lt;kbabbitt> ... satisfies westbrook's use case<br>
&lt;sorvell> +1<br>
&lt;kbabbitt> ... there is still the other side where you want an anchor name defined deep in a shadow referenceable elsewhere in tree<br>
&lt;kbabbitt> ... requires more explicit opt-in to be safe in my opinion<br>
&lt;sorvell> +1<br>
&lt;kbabbitt> ... would like to work on in the future but for now I think spec is in a good state<br>
&lt;kbabbitt> ... so if there are no objections we can resolve to take these edits<br>
&lt;astearns> ack kizu<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to ask about other naming<br>
&lt;florian> q?<br>
&lt;kbabbitt> fantasai: could you summarize for the group... we have a variety of name matching behaviors, what's changed?<br>
&lt;kbabbitt> TabAtkins: previously in the spec, anchor names were tree scoped names<br>
&lt;kbabbitt> ... carry around identity / style tree they were defined in<br>
&lt;kbabbitt> ... anchor names were strict tree scoped references<br>
&lt;kbabbitt> ... would only match tree scoped names defined in same tree as they were<br>
&lt;kbabbitt> ... now they are loose tree scope names<br>
&lt;kbabbitt> ... will match any names in their own tree or higher up tree<br>
&lt;kbabbitt> ... if trees don't have parent-child relationship they won't match<br>
&lt;kbabbitt> ... can define in parent component, top level component, any tree will see that<br>
&lt;kbabbitt> fantasai: did we change how it works for other props?<br>
&lt;kbabbitt> TabAtkins: we have not right now because we haven't rewritten scoping rules for timelines to match anchors<br>
&lt;kbabbitt> ... but intention is to keep all those concepts resolving exactly as identically as possible<br>
&lt;kbabbitt> astearns: do we have that intent written down?<br>
&lt;kbabbitt> TabAtkins: we resolved on it during breakout in Paris<br>
&lt;kbabbitt> astearns: do we need CSS operations module or something that collects some of these cross module resolutions<br>
&lt;kbabbitt> ... we do have space on wiki for design principles, this seems like something that should go there<br>
&lt;kbabbitt> TabAtkins: seems reasonable<br>
&lt;kbabbitt> astearns: other comments?<br>
&lt;kbabbitt> Proposed: Accept the edits<br>
&lt;kbabbitt> RESOLVED: Accept the edits<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9408#issuecomment-3524810910 using your GitHub account


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

Received on Thursday, 13 November 2025 02:09:00 UTC