- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 17:40:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1][css-animations-2][scroll-animations-1] Fix name visibility for descendants`, and agreed to the following: * `RESOLVED: name lookup for timeline-name, anchor-name, etc. walks up the ancestor chain (up to stopping point) first, then looks for last-defined within scope` <details><summary>The full IRC log of that discussion</summary> <fantasai> flackr: I'm aware of 3 different specs where we've introduced the ability to define a name that allows you to refer to something declared in CSS on one element from another element<br> <fantasai> flackr: Anchor Positioning, Scroll-driven Animations, Scroll-triggered Animations<br> <fantasai> flackr: Previously we agreed that it would be great for how scoping was the same, so authors don't need to think about different scoping rules depending on the property<br> <fantasai> flackr: We largely said "let's take scoping of anchor positioning"<br> <fantasai> flackr: But biggest compat risk, and something that would be nice to have in anchor positioning, is being able to refer to ancestor without worrying about further ancestors defining the name<br> <TabAtkins> q+<br> <fantasai> flackr: So proposal is to make name lookup find the nearest ancestor that declares the name or nearest scope for that name, whichever encountered first in ancestor tree<br> <bramus> q+<br> <fantasai> flackr: This would make aligning with scroll-driven animations very easy<br> <fantasai> flackr: and also for anchor-positioning, if you're positioning a descendant, don't need to explicitly scope the name<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: I'm confused about how this would apply to anchor positioning, because thing you're anchoring to doesn't need to be an ancestor -- and usually isn't<br> <fantasai> flackr: Wrote a demo page showing when it would apply<br> <fantasai> flackr: Most of the time, yes, you would find the nearest thing defining the anchor name<br> <astearns> demo: https://codepen.io/flackr/pen/azZJvyL<br> <fantasai> flackr: but if you had an ancestor with that name, you would anchor to it instead<br> <fantasai> fantasai: So that would take priority?<br> <fantasai> flackr: Yes<br> <fantasai> flackr: Majority of time it won't change anchor positioning, mostly backwards compatible -- because usually you're not a descendant<br> <fantasai> TabAtkins: I think I understand<br> <fantasai> TabAtkins: If it's intended for anchor positioning to be a relatively rare case that makes more sense<br> <fantasai> TabAtkins: so we'd change name lookup so that it walks up to containing block<br> <astearns> q+<br> <fantasai> TabAtkins: Then we look for anything under the "scoping root"<br> <fantasai> TabAtkins: Ok, this probably is a more intuitive thing for this sort of case, I think I agree ...<br> <astearns> ack bramus<br> <fantasai> bramus: Big +1 to this proposal. Not only will it align lookups, but it would unblock the adjustment of itmeline-scope that we resolved<br> <fantasai> bramus: If we just did timeline-scope aligning to anchor-scope, it would break existing scroll-driven animations<br> <fantasai> bramus: Would solve that problem.<br> <ChrisLilley> s/anything/the latest match<br> <emilio> fantasai: timeline doesn't have a natural stepping point while anchor pos has<br> <fantasai> flackr: Nearest thing declaring that scope<br> <fantasai> flackr: Proposed that you could expand out to the whole doc by walking up to the root<br> <fantasai> flackr: Just like anchor positioning<br> <fantasai> fantasai: anchor positioning stops at the nearest containing block, not the root<br> <fantasai> TabAtkins: for fixedpos it's the same thing<br> <astearns> ack astearns<br> <fantasai> flackr: The change we resolved on was that you would by default go up to the root for timeline maching<br> <fantasai> s/mach/matching<br> <fantasai> astearns: If we add these new steps for anchorpos, is there a compat risk?<br> <fantasai> TabAtkins: Unlikely. Most anchor use cases are not anchoring to an ancestor<br> <fantasai> TabAtkins: so rare case to begin with<br> <fantasai> TabAtkins: and most anchor use cases have a unique name match<br> <fantasai> TabAtkins: this would only affect cases where you have multiple uses of the same name, and one is an ancestor and the other is not<br> <fantasai> TabAtkins: That's negligible<br> <lea> AP has 0.4% usage *as a whole*, and this is a fraction of that<br> <fantasai> TabAtkins: we can always revisit<br> <fantasai> flackr: Also in rare cases, this is more likely to match the author's intuition<br> <fantasai> TabAtkins: one case where it would occur today where you have a bunch of repeated components where you're not using scoping<br> <fantasai> TabAtkins: likely you have somethng broken there already<br> <fantasai> bramus: Ran into this with scroll-triggered cases and had to scope everything, which ... felt like it should work out of the box<br> <fantasai> astearns: +1 to consistency<br> <bramus> scribe+<br> <bramus> fantasai: timeline scopes walk up the ancestor chain?<br> <bramus> bramus: they do, we changed that<br> <bramus> s/do/did<br> <fantasai> flackr: Originally, when you declared a timeline, it was effectively like a scope at its element, and you could not refer to that timeline outside of it unless timeline-scope on an ancestor pulling it up<br> <fantasai> flackr: but we agreed previously that having very different scoping rules for named things depending on the spec would be confusing<br> <fantasai> flackr: So wanted to go with a model more consistent across uses, align more with anchor scope<br> <fantasai> flackr: So the goal of this issue is to, in a compatible way, align the two<br> <bramus> fantasai: then we would walk up the ancestor chain as it was already doing<br> <bramus> … and then expand out like anchor name does<br> <bramus> flackr: exact<br> <bramus> astearns: proposed resolution?<br> <fantasai> PROPOSED: name lookup for timeline-name, anchor-name, etc. walks up the ancestor chain (up to stopping point) first, then expands outward to other elements<br> <fantasai> PROPOSED: name lookup for timeline-name, anchor-name, etc. walks up the ancestor chain (up to stopping point) first, then looks for last-defined within scope<br> <fantasai> flackr: per previous resolution, this is how timelines now behave<br> <fantasai> astearns: objections?<br> <fantasai> RESOLVED: name lookup for timeline-name, anchor-name, etc. walks up the ancestor chain (up to stopping point) first, then looks for last-defined within scope<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13364#issuecomment-3812817974 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 17:40:55 UTC