Intent to Ship: ::scroll-marker and ::scroll-marker-group for Carousel, ::column pseudo element for Carousel and ::scroll-button() pseudo elements

[Ajay Rahatekar]

Contact emails

fla...@chromium.org, sakh...@chromium.org

Summary

This is a combined Intent to ship for the following features:

::scroll-marker and ::scroll-marker-group for scrolling containers:

Pseudo elements that allow to create a set of focusable markers for all of the associated items within the scrolling container.

::scroll-button(<direction>):

Focusable pseudo-element button that allows scrolling the scrolling container in the associated direction.

::column

Supports associating ::scroll-marker elements with column fragments and scroll snap aligning to columns.

Explainer

https://chrome.dev/carousel/

https://github.com/w3c/csswg-drafts/blob/main/css-overflow-5/carousel-explainer.md

Specification

https://drafts.csswg.org/css-overflow-5/#scroll-navigation

https://drafts.csswg.org/css-multicol-2/#column-pseudo

Blink component

Blink>CSS

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: https://github.com/mozilla/standards-positions/issues/1161

WebKit: https://github.com/WebKit/standards-positions/issues/447

Web developers: Positive

• https://x.com/f3rg_codes/status/1889283883910472004

• https://www.youtube.com/watch?v=rE-qmyPHHGw&t=1s#:~:text=those%20carousel%20examples%20are%20wild!%20holy%20smokes%20

• https://utilitybend.com/blog/love-at-first-slide-creating-a-carousel-purely-out-of-css

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

Basic DevTools support is expected to be available when the features ship. Extended support for debugging is under investigation

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

css/css-overflow/{column*, scroll-button*, scroll-marker*}

Flag name on about://flags

None

Finch feature name

CSSPseudoScrollButtons, CSSPseudoScrollMarkers, CSSPseudoColumn

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/332396355

https://issues.chromium.org/issues/358119263

https://issues.chromium.org/issues/365680822

Estimated milestones

135

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/5160035463462912

https://chromestatus.com/feature/5192332683771904

https://chromestatus.com/feature/5093129273999360

Links to previous Intent discussions

Intent to Prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/4hDfC6nBoP0

https://groups.google.com/a/chromium.org/g/blink-dev/c/hoBT5TPKRrw

https://groups.google.com/a/chromium.org/g/blink-dev/c/ZPXC1I9E1Vw

This intent message was generated by Chrome Platform Status.

[Rick Byers]

I'm excited to see this ship! 

I see a number of open issues on GitHub, at least one or two of which sound like they would have web compat implications. Can you do a triage pass over the open issues and summarize here what you see the web compat risk to be for potentially upcoming spec changes to resolve the issues? Given this is an unpolyfillable CSS feature I assume we don't expect much adoption until there's multi-engine support and so are likely to be able to make breaking changes for a while after we ship if necessary, right?

 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5160035463462912

https://chromestatus.com/feature/5192332683771904

https://chromestatus.com/feature/5093129273999360

Links to previous Intent discussions

Intent to Prototype:

https://groups.google.com/a/chromium.org/g/blink-dev/c/4hDfC6nBoP0

https://groups.google.com/a/chromium.org/g/blink-dev/c/hoBT5TPKRrw

https://groups.google.com/a/chromium.org/g/blink-dev/c/ZPXC1I9E1Vw

This intent message was generated by Chrome Platform Status.

--
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/CAHB%2BDAg57vSk1VeA-yi8HmM5XV%3D0fKba2kJQFOkwoC13kDL4mg%40mail.gmail.com.

[Robert Flack]

On Fri, Feb 21, 2025 at 5:19 PM Rick Byers <rby...@chromium.org> wrote:

I'm excited to see this ship! 

Thanks, me too! 

Thanks for calling this out.

one is partially implemented (::scroll-button has button style). I thought we had a resolution for it but I couldn't find it. I've added a proposed resolution and put it on the agenda for discussion.

I closed two as we have resolved on, spec'd and implemented the name we expect.

You're correct that this is extremely difficult to polyfill (my prototype does - but would not be well suited for production environments).

Looking over the rest of the issues, many of them have already been fully spec'd and implemented or were generic meta-issues that are now obsolete and I was able to close (#11098, #11165, #11361, #10720, #10912). Of those that remain, some are not relevant to the shipping features here (#10493, #11553, #10916), many are clarifying the implementation that won't require implementation changes (#11198, #10705, #10708, #10704, #11166), many are minor changes not likely to break typical use cases (#11600, #11746, #10494, #11709, #11708, #11213, #11249) and #11705 we are implementing / specing. As you mentioned, we should be able to make minor breaking changes as we identify edge cases for a while as we don't expect significant adoption until there's multi-engine support.

[Rick Byers]

Thank you Rob, sounds good to me!

So the UA stylesheet issue sounds like it's the only real potential compat risk to worry about here, and probably not really that risky in practice right, right?

 

I'm comfortable giving my LGTM1 to ship now. But please keep pushing on this for a resolution and if the WG comes to a consensus that doesn't match our impl prior to March 26 when 135 starts to roll out to stable, please consider either a merge or finch kill-switch and delay if a bug-fix in M136 would have non-trivial web compat implications. It's normal that we'd fix a bunch of minor web-exposed bugs in a new feature that don't really rise to the level of a meaningful breaking change, so in general I'm not too worried and trust you and your team's focus on achieving interop.

[Mike Taylor]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_mf398JNbm3mb6DU3tf%2BFaSdNd0vr3f%3DXZkjPFnwyMXw%40mail.gmail.com.

[Dan Clark]

LGTM3

[Xiaocheng Hu]

(With my TAG hat on)

Could the shipping of this feature be held until 3/18?

We have discussed the Carousel-related features at the TAG F2F and have some concerns. We've invited flackr@ to our breakout meeting on 3/18 to help us resolve them.

Thank you!

Regards,

Xiaocheng

[Rick Byers]

[Repeating the same response as in the other carousel feature]

Hi Xiaocheng,

Thank you for digging in and scheduling time with Rob to discuss further. However our policy is not to delay launching features based on a desire for review and discussion beyond one month from the point of formally soliciting feedback (Jan 9 in this case). If there are specific concrete concerns (especially ones which might credibly give rise to compatibility issues if fixed one or two months from now), then we can discuss those and evaluate whether they warrant a delay. But otherwise we should just continue to collaborate and explore making changes post-ship.

As I know you well know, a new web feature (especially in the CSS space) shipping in one engine is really still near the beginning of the process of standards maturation and full interoperability. I trust Rob and his team to continue to engage in alignment within the standards community and to invest in additional changes as necessary for achieving wide interoperability and full standardization.

Thanks,

   Rick