You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scroll-state container queries apply style directly or indirectly based on scroll progress of a scroll container:
Whether a sticky positioned have offsets applied in a given direction
Whether an element is scroll snapped in a given direction
Whether an element has scrollable overflow in a given direction
The current state on the spec and implementation side:
Snapshot timing is not specified for anchor positioning (see issue), but the Chromium implementation uses the same timing as for the scroll animations below.
Scroll animations snapshotting is specified, but the HTML spec references are out-of-date, and the “stale timelines” concept does not exist in the Chromium implementation. A second update can happen, even for non-stale timelines, in the Chromium implementation:
A second update of the timelines happens (for stale timelines per spec) after the first style and layout update in the resizeObserver loop of the HTML spec. There seems to be a discrepancy between the spec and the implementation in that the spec says the update should happen after the resizeObserver loop, but not very clear.
For scroll-state() queries, there is a prototype implementation where the snapshotting happens at the same time as the former two.
The two-stage snapshotting happens to avoid a first rendering where there is one frame without a snapshot, since there is no previous frame, with a second frame that applies the state from the first frame, leading to flicker for the first rendering.
Instead of having multiple specs describing when this snapshotting happens, and how it interacts with the HTML spec, we could introduce common spec steps for doing post-layout state snapshots.
Introduce a new “run snapshot post-layout state steps” to CSSOM View spec. Say that this is where the post-layout state used for style and layout is snapshotted for any specs that need to. Leave for each spec to say what they snapshot as part of “run snapshot post-layout state steps”.
Multiple CSS specifications now rely on post layout state, like scroll state, for doing style and layout:
The current state on the spec and implementation side:
The two-stage snapshotting happens to avoid a first rendering where there is one frame without a snapshot, since there is no previous frame, with a second frame that applies the state from the first frame, leading to flicker for the first rendering.
Instead of having multiple specs describing when this snapshotting happens, and how it interacts with the HTML spec, we could introduce common spec steps for doing post-layout state snapshots.
The text was updated successfully, but these errors were encountered: