Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Prototype: CSS anchor positioning remembered scroll offset

65 views
Skip to first unread message

Morten Stenshorne

unread,
Feb 14, 2025, 5:07:04 AMFeb 14
to blink-dev

Contact emails

mste...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-anchor-position-1/#scroll

Summary

Add support for the concept of "remembered scroll offset" - see https://drafts.csswg.org/css-anchor-position-1/#scroll When a positioned element has a default anchor, and is tethered to this anchor at one edge, and against the original containing block at the other edge, the scroll offset will be taken into account when it comes to sizing the element. This way a developer can use all visible space (using `position-area`) for the anchored element when the document is scrolled at a given scroll offset. In order to avoid layout (resizing the element) every time the document is scrolled (which is undesired behavior, and also bad for performance), what will be used is a so-called "remembered scroll offset", rather than always using the current scroll offset. The remembered scroll offset is updated at a so-called "anchor recalculation point", which is either: - When the positioned element is initially displayed - When a different position option (`position-try-fallbacks`) is chosen



Blink component

Blink>Layout

Motivation

A developer should be able to use all available visible space (or a percentage of it) for an anchored element (using `position-area`), to fit as much content as desirable, rather than either using fixed sizes, or requiring that everything be scrolled to the initial scroll offsets for it to work. One important use case is customizable select. The select popup picker should use all available space in the viewport and be scrollable on its own, if needed (i.e. if there are enough options).



Initial public proposal

None

TAG review

None

TAG review status

Pending

Risks



Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/373874012

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4710507824807936?gate=6071039949537280

This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
Forward
0 new messages