Capture scroll offsets when anchor is first evaluated, i.e. remembered scroll offset
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
People
(Reporter: dshin, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
884 bytes,
text/html
|
Details |
| Reporter | ||
Comment 1•9 months ago
|
||
Bit more context:
Spec is here: https://drafts.csswg.org/css-anchor-position-1/#remembered-scroll-offset
Whenever we hit an anchor recalculation point, we need to compute and store this offset for a positioned frame.
Anchor recalculation point is hit when:
- The element starts generating boxes
- Upon evaluating
position-try-fallbacks: Whatever fallback option is picked, we replace our remembered scroll offset with that one (Unless we stick with the current fallback)
| Reporter | ||
Comment 2•9 months ago
|
||
| Reporter | ||
Comment 3•9 months ago
|
||
Above is a demonstrative case - moving the scrollbar and clicking "Go" toggles display: none off for the positioned frame, gets its computed style, then prints it.
Seems that Chrome Canary 142.0.7444.0 does not have this implemented. Instead, it seems to implement the previous behaviour where offsets are computed with all scrollers at their initial positions.
OTOH, Safari Technology Preview 228 (WebKit 20623.1.7.19.1) does.
| Reporter | ||
Comment 4•9 months ago
|
||
Hm, the text that made me think that this needs to reflect at computed value time (e.g. through gCS) seems to have disappeared: https://github.com/w3c/csswg-drafts/commit/16f14cb2497cf24eab798925e87e0fa303940b36
| Reporter | ||
Updated•9 months ago
|
| Reporter | ||
Comment 5•8 months ago
|
||
With my latest comment on the spec issue, I am no longer sure if this should be in M2, especially considering that Chromium doesn't implement remembered scroll offset, where WebKit does.
Updated•8 months ago
|
Description
•