[csswg-drafts] [css-anchor-1] Allow smooth transitioning between fallback positions (#8372)

xiaochengh has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-1] Allow smooth transitioning between fallback positions ==
(I'm filing this to discuss the [inline issue](https://drafts4.csswg.org/css-anchor-1/#issue-da47c41b) in the spec)

In the current spec, fallback position styles are [applied at used value time](https://drafts4.csswg.org/css-anchor-1/#fallback-apply), which means we cannot create a smooth transition when switching between two fallback positions. 

To solve this, @tabatkins and I had an offline discussion today. Below is the summary:

---

First of all, the only proper way to solve it is to apply fallback position styles at computed value time. Any other approach (i.e., using view transition) seems to create more problems than it solves.

Then there are two approaches. Both are fine on their own, but give different tradeoffs between behavior cleanliness and implementation complexity (on top of the existing impl in Chromium).

### Also decide which fallback position to use when snapshotting the scroll offsets

We are currently [snapshotting the scroll offsets](https://drafts4.csswg.org/css-anchor-1/#snapshotted-scroll-offset) of the relevant scrollers at the beginning of a frame update, and use it later during layout to decide which fallback position to use.

In this approach, we can do more when taking the snapshot: we can snapshot everything we need from the previous frame's layout, decide which fallback position to use, and then apply that to the computed style. Similar as before, this means we may be applying an incorrect fallback position, in which case we trigger another frame update to fix it.

This also gives a solution to #8171: we introduce a CQ-like query that actually queries the snapshot.

### Make fallback positioning CQ-like, and completely get rid of snapshotting

With the same idea of container queries, we can pause the style resolution of an element if it's anchor positioned, and resume at layout time. As now we have all the layout information needed, we can choose and apply the correct fallback position to the computed style.

This is feasible since we require that the anchor element must be laid out before the target element.

This also gives a cleaner behavior, since we will never apply any stale information and trigger another frame to fix it, so rendering is always stable. #8171 is also solved naturally.

---

The discussion may also extend to a broader context: what to do when we have style depending on layout?

We currently have scroll-linked animations and anchor positioning that snapshot the previous frame, and container queries that do interleaving style and layout based on explicit dependencies between elements (as long as the dependency is acyclic).

Theoretically, we can use the same approach to solve all of them. And the CQ-like approach always seem to give a cleaner behavior, so it's still a tradeoff between implementation complexity and cleaner spec.

cc @mfreed7 @bfgeek @andruud 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8372 using your GitHub account


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

Received on Friday, 27 January 2023 20:50:11 UTC