Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-conditional][css-anchor-position][scroll-animations] Snapshotting post-layout State #10796

Open
lilles opened this issue Aug 28, 2024 · 0 comments

Comments

@lilles
Copy link
Member

lilles commented Aug 28, 2024

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), 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:
    • Snapshotting is specified to happen at the beginning of 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, but before update animations and send events in the HTML event loop.
  • Add these new steps to the HTML event loop 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment