[csswg-drafts] [css-conditional][css-anchor-position][scroll-animations] Snapshotting post-layout State (#10796)

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

== [css-conditional][css-anchor-position][scroll-animations] Snapshotting post-layout State ==
Multiple CSS specifications now rely on post layout state, like scroll state, for doing style and layout:

- Scroll/View progress timelines are animation timelines based on scroll progress of a scroll container
- Anchor positioning does scroll adjustments to anchored element to align with anchor, and scroll progress can affect style and layout through choosing different fallbacks: https://drafts.csswg.org/css-anchor-position-1/#fallback-apply
- 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](https://drafts.csswg.org/css-anchor-position-1/#issue-5446f06a)), but the Chromium implementation uses the same timing as for the scroll animations below.
- Scroll animations snapshotting is [specified](https://drafts.csswg.org/scroll-animations/#event-loop), but the HTML spec references are [out-of-date](https://github.com/w3c/csswg-drafts/issues/10769), 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:
  - Snapshotting is specified to happen at the beginning of [update animations and send events](https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events)
  - 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”.
- Invoke “run snapshot post-layout state steps” after [evaluate media queries and report changes](https://drafts.csswg.org/cssom-view/#evaluate-media-queries-and-report-changes), but before [update animations and send events](https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events) in the HTML event loop.
- Add these new steps to the [HTML event loop](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model) after the resizeObserver loop (new in bold):
  - If doc has skipped resize observations, then deliver resize loop error given doc.
  - **Run snapshot post-layout state steps**
  - **If any post-layout state changes invalidated layout or style**
    - **Recalculate styles and update layout for doc**


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


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

Received on Wednesday, 28 August 2024 07:06:22 UTC