w3c
[css-anchor-position-1] Working with Scroll Driven Animations
The spec currently says that the anchored element position is determined as if all of the scrollers are scrolled to the top. The scrolling adjustment is then made by a snapshot scroll offset. I think this works fine for the common scrolling case.
However, with addition of scroll driven animations, a scroll offset can now affect a progress of an animation which can affect far more than just a translation. It isn't clear if the spec means that these animations should be at 0% progress because the scroll is at the top. I think it's worthwhile to call out scroll driven animations explicitly and figure out how to handle the interaction.
/cc @flackr @xiaochengh @tabatkins
The spec currently says that the anchored element position is determined as if all of the scrollers are scrolled to the top. The scrolling adjustment is then made by a snapshot scroll offset. I think this works fine for the common scrolling case.
This sounds like the implementation details. Is this actually developer observable in a meaningful way? I think as far as a developer is concerned it determines the necessary offset to align the anchor - similar to sticky position.
The general direction we have been thinking with scroll driven animations is that authors can do bad things, however in the majority of cases we want animations to work as expected. As such, I'd expect it to use the current animation values. However, similar to sticky position and view timelines, we would use the non-transformed box, which allows authors to implement transform effects without them interfering and also means we don't have to worry about things like rotations or perspective. Often this allows authors to implement cool effects by using transforms in interesting ways without it interfering with the positioning.
Similar to sticky position - see #8298, we may want to adjust some of the view timeline animation ranges to account for anchor offsets.
Anchor positioning determines the position, which should affect a scroll driven animation on the anchoring element (see blue anchor in demo). A scroll driven animation could be made to affect the position of the anchor (green anchor in demo). These both behave as expected in chrome. I put together a demo of both of these cases.
I suppose a particular degenerate case would be if the anchoring element defines a timeline based on its position that is used by a scroll driven animation, example case shows this. The anchored element defines a timeline which is used to move the anchor target to which it is anchoring which in turn affects the anchor position. This also seems to work fine in chrome since scroll timelines are only sampled once per frame - though admittedly the sampled position of an anchor position element would be before the current update per.
Since @flackr thinks this is well-defined already, and they're happy with what that definition is, I'm closing the issue.
