Intent to Ship: CSS Scroll State Container Queries

[Rune Lillesveen]

Contact emails

fut...@chromium.org

Explainer

https://drafts.csswg.org/css-conditional-5/scroll_state_explainer.html
https://drafts.csswg.org/css-conditional-5/scroll_state_explainer.md

Specification

https://www.w3.org/TR/css-conditional-5/#scroll-state-container

Summary

Use container queries to style descendants of containers based on their scroll state. The query container is either a scroll container, or an element affected by the scroll position of a scroll container. The following states can be queried: - Whether a sticky positioned container is stuck to one of the edges of the scroll box (stuck) - Whether a scroll snap aligned container is currently snapped horizontally or vertically (snapped) - Whether a scroll container can be scrolled in a queried direction (overflowing) A new container-type:scroll-state is introduced to allow such containers to be queried. For instance: #sticky { position: sticky; container-type: scroll-state; } @container scroll-state(stuck: top) { #sticky-child { font-size: 75% } }

Blink component

Blink>CSS

TAG review

https://github.com/w3ctag/design-reviews/issues/885

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Risk: none of the other vendors have committed to implement yet.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/896)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/261)

Web developers: Positive (https://utilitybend.com/blog/is-the-sticky-thing-stuck-is-the-snappy-item-snapped-a-look-at-state-queries-in-css) Also, https://ishadeed.com/article/css-state-queries/

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

- Elements are marked with a "container" badge for scroll-state as for size containers - @container rules in matching styles have a link back to the container element as for size containers - No further support as of now. Future improvements could be - Having an indication of container type in the element badge - Some indication along with the query which feature is matched with which value

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

Yes

https://wpt.fyi/results/css/css-conditional/container-queries/scroll-state

Flag name on about://flags

#enable-experimental-web-platform-features

Finch feature name

CSSStickyContainerQueries, CSSSnapContainerQueries, CSSOverflowContainerQueries

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40268059

Sample links

https://codepen.io/argyleink/pen/JjqVzxq
https://codepen.io/argyleink/pen/rNgbbOP
https://codepen.io/argyleink/pen/wvbZZWP
https://codepen.io/argyleink/pen/zYbEdGm
https://codepen.io/argyleink/pen/vYPzdGp
https://codepen.io/argyleink/pen/PoMJvXN

Estimated milestones

Shipping on desktop	133
DevTrial on desktop	116
Shipping on Android	133
DevTrial on Android	116
Shipping on WebView	133

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5072263730167808?gate=5092937152593920

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeQyse1btL_jhkEQJT9WCsR2sndRo8i%3DyHmzgPu6sDpDOw%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

--

Rune Lillesveen

[Rune Lillesveen]

Four issues are opened against the spec:

https://github.com/w3c/csswg-drafts/issues/11181
https://github.com/w3c/csswg-drafts/issues/11182
https://github.com/w3c/csswg-drafts/issues/11183
https://github.com/w3c/csswg-drafts/issues/11127

The one that's blocking shipping is the potential renaming from 'overflowing' to 'scrollable': https://github.com/w3c/csswg-drafts/issues/11182

Two of the others are convenience keyword additions, and the last one is a non-behavioral editorial change to the spec.

--

Rune Lillesveen

[Alex Russell]

Does this integrate with scroll timelines and animations at all?

[Rune Lillesveen]

On Wed, Nov 13, 2024 at 10:38 AM Rune Lillesveen <fut...@chromium.org> wrote:

Four issues are opened against the spec:

https://github.com/w3c/csswg-drafts/issues/11181
https://github.com/w3c/csswg-drafts/issues/11182
https://github.com/w3c/csswg-drafts/issues/11183
https://github.com/w3c/csswg-drafts/issues/11127

The one that's blocking shipping is the potential renaming from 'overflowing' to 'scrollable': https://github.com/w3c/csswg-drafts/issues/11182

This has now been resolved.

Two of the others are convenience keyword additions, and the last one is a non-behavioral editorial change to the spec.

11181 and 11183 have been scheduled for async resolution. 

--

Rune Lillesveen

[Rune Lillesveen]

On Wed, Nov 20, 2024 at 5:24 PM Alex Russell <sligh...@chromium.org> wrote:

Does this integrate with scroll timelines and animations at all?

Scroll positions are intentionally snapshotted at the same time for scroll-timeline and scroll-state() queries: https://drafts.csswg.org/cssom-view/#post-layout-snapshot

Otherwise there is no particular interaction between scroll-state() queries and scroll-timelines different from other CSS features.

--

Rune Lillesveen

[Mike Taylor]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeSqvXZcGbJwczY_anrcTuN2_2Sd19ALKjtLq7am-P7wzw%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a02ee4a6-8ec9-44aa-ae1a-c3cdc54db67a%40chromium.org.

[Rick Byers]

LGTM3

Is anyone looking into why the tests have harness errors on non-chromium browsers? Is that a bug in the test failing to fail properly?

Rick

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_k7nC22L-2YrNU6FB9grft%3D%2BtBJrx08PNoniNZVGrugQ%40mail.gmail.com.

[Rune Lillesveen]

On Wed, Nov 27, 2024 at 4:49 PM Rick Byers <rby...@chromium.org> wrote:

LGTM3

Is anyone looking into why the tests have harness errors on non-chromium browsers? Is that a bug in the test failing to fail properly?

The issue is that I use assert_implements() for container-type:scroll-state in the setup() function as it makes no sense to continue without it, and to make sure there are no false positives in subtests. But consulting the wpt documentation it seems I need to repeat that in every single subtest instead. It would be convenient to have some pre-condition check in setup() that causes every subtest to fail instead of causing a harness error.

--

Rune Lillesveen

[Rick Byers]

On Fri, Nov 29, 2024 at 5:02 AM Rune Lillesveen <fut...@chromium.org> wrote:

On Wed, Nov 27, 2024 at 4:49 PM Rick Byers <rby...@chromium.org> wrote:

LGTM3

Is anyone looking into why the tests have harness errors on non-chromium browsers? Is that a bug in the test failing to fail properly?

The issue is that I use assert_implements() for container-type:scroll-state in the setup() function as it makes no sense to continue without it, and to make sure there are no false positives in subtests. But consulting the wpt documentation it seems I need to repeat that in every single subtest instead. It would be convenient to have some pre-condition check in setup() that causes every subtest to fail instead of causing a harness error.

Interesting, thanks for looking into it. Feel free to file a WPT bug for improving the infra (/cc @Panos Astithas).

[Panos Astithas]

On Fri, Nov 29, 2024 at 7:18 AM Rick Byers <rby...@chromium.org> wrote:

On Fri, Nov 29, 2024 at 5:02 AM Rune Lillesveen <fut...@chromium.org> wrote:

On Wed, Nov 27, 2024 at 4:49 PM Rick Byers <rby...@chromium.org> wrote:

LGTM3

Is anyone looking into why the tests have harness errors on non-chromium browsers? Is that a bug in the test failing to fail properly?

The issue is that I use assert_implements() for container-type:scroll-state in the setup() function as it makes no sense to continue without it, and to make sure there are no false positives in subtests. But consulting the wpt documentation it seems I need to repeat that in every single subtest instead. It would be convenient to have some pre-condition check in setup() that causes every subtest to fail instead of causing a harness error.

Interesting, thanks for looking into it. Feel free to file a WPT bug for improving the infra (/cc @Panos Astithas).

There is already a bug filed and I added it to my team's prioritized backlog.