Intent to Ship: Snap Events

[David Awogbemila]

Contact emails

awogb...@google.com, arg...@google.com

Explainer

https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanged
https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-snapChanging

Specification

https://drafts.csswg.org/css-scroll-snap-2#snap-events

Summary

Snap Events allow developers to reliably listen for when the "snap target" of a scroll container changes and perform style adjustments as desired. CSS scroll snap points are often used as a mechanism to create scroll interactive "selection" components, where selection is determined with javascript intersection observers and a scroll end guestimate. By creating built-in events, the invisible state will become actionable, at the right time, and always correct. This feature adds two JavaScript events: scrollsnapchange and scrollsnapchanging. Scrollsnapchange lets developers know, at the completion of a scroll operation (including snapping), that the element to which a scroll container is snapped has changed. Scrollsnapchanging gives developers a hint, during a scroll operation, that the user agent intends to snap the scroll container to a new snap target based on the scrolling input so far.

PS: Separate Intent To Prototypes were sent for events named "snapchanged" and "snapchanging" but the events have since been renamed to "scrollsnapchange" and "scrollsnapchanging" respectively and now share a single chromestatus page.

Blink component

Blink>Scroll

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1008#issuecomment-2043260081)

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

Web developers: Positive (https://github.com/w3c/csswg-drafts/issues/156)

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

Chrome's DevTools supports setting event listener breakpoints for scrollsnapchanging and scrollsnapchange events.

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

Yes

scrollsnapchange and scrollsnapchanging are supported on all Blink platforms

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

Yes

https://wpt.fyi/results/css/css-scroll-snap-2/scrollsnapchange contains the scrollsnapchange tests. https://wpt.fyi/results/css/css-scroll-snap-2/scrollsnapchanging contains the scrollsnapchanging tests.

Flag name on chrome://flags

None

Finch feature name

CSSScrollSnapChangeEvent, CSSScrollSnapChangingEvent

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40273052

Estimated milestones

Shipping on desktop

127

Shipping on Android

127

Shipping on WebView

127

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).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5826089036808192?gate=5441243751907328

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6pwF6S4v5fQjpeEHk4zgeVhUxn%3DRR%2BOVMSTL8-H%2Br2xd7h%3DQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Emilio Cobos Álvarez]

Has this been reviewed by the CSSWG? (not only the PR I mean, but the
feature as a whole). The spec PR:
https://github.com/w3c/csswg-drafts/pull/9515

Doesn't mention any issue or discussion in a CSSWG call. Usually having
a resolution for a new feature is a requirement to get it merged...

We recently discussed a similar process mishap in
https://github.com/w3c/csswg-drafts/issues/7767, would be good not to
repeat it.

I see some follow-up issues on naming and such things are still open
(though some /do/ have resolutions). Do you plan to update the spec and
tests?

Some of them seem pretty substantial and seems like it'd block shipping.
E.g., the event name was changed in
https://github.com/w3c/csswg-drafts/issues/9697. It seems the spec edits
landed but the issue remained open. I just closed since it seems there
are also tests.

https://github.com/w3c/csswg-drafts/issues/10173 seems open and resolved
but no edits (not sure about tests).

Thanks,

-- Emilio

On 5/27/24 5:01 PM, David Awogbemila wrote:
>
> Contact emails
>
> awogb...@google.com <mailto:awogb...@google.com>, arg...@google.com
> <mailto:arg...@google.com>
>
>
> Explainer
>
> https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-
> snapChanged <https://github.com/argyleink/ScrollSnapExplainers/tree/
> main/js-snapChanged>
> https://github.com/argyleink/ScrollSnapExplainers/tree/main/js-
> snapChanging <https://github.com/argyleink/ScrollSnapExplainers/tree/
> main/js-snapChanging>
>
>
> Specification
>
> https://drafts.csswg.org/css-scroll-snap-2#snap-events <https://
> drafts.csswg.org/css-scroll-snap-2#snap-events>

>
>
> Summary
>
> Snap Events allow developers to reliably listen for when the "snap
> target" of a scroll container changes and perform style adjustments as
> desired. CSS scroll snap points are often used as a mechanism to create
> scroll interactive "selection" components, where selection is determined
> with javascript intersection observers and a scroll end guestimate. By
> creating built-in events, the invisible state will become actionable, at
> the right time, and always correct. This feature adds two JavaScript
> events: scrollsnapchange and scrollsnapchanging. Scrollsnapchange lets
> developers know, at the completion of a scroll operation (including
> snapping), that the element to which a scroll container is snapped has
> changed. Scrollsnapchanging gives developers a hint, during a scroll
> operation, that the user agent intends to snap the scroll container to a
> new snap target based on the scrolling input so far.
>
>
> PS: Separate Intent To Prototypes were sent for events named

> "snapchanged <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/
> c/AGsZy1WSIS0/m/iZwFmo9PAQAJ>" and "snapchanging <https://
> groups.google.com/a/chromium.org/d/msgid/blink-dev/
> CAA6pwF7tYZgc8A6Kh5ZczDhjP%2BxyQ0_fWbxNFSPgs-az0nc4Jg%40mail.gmail.com>"

> but the events have since been renamed to "scrollsnapchange" and
> "scrollsnapchanging" respectively and now share a single chromestatus page.
>
>
> Blink component
>

> Blink>Scroll <https://bugs.chromium.org/p/chromium/issues/list?
> q=component:Blink%3EScroll>
>
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/943 <https://github.com/
> w3ctag/design-reviews/issues/943>

>
>
> TAG review status
>
> Pending
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> None
>
>
>

> /Gecko/: Positive (https://github.com/mozilla/standards-positions/
> issues/1008#issuecomment-2043260081 <https://github.com/mozilla/
> standards-positions/issues/1008#issuecomment-2043260081>)
>
> /WebKit/: No signal (https://github.com/WebKit/standards-positions/
> issues/333 <https://github.com/WebKit/standards-positions/issues/333>)
>
> /Web developers/: Positive (https://github.com/w3c/csswg-drafts/
> issues/156 <https://github.com/w3c/csswg-drafts/issues/156>)
>
> /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
>
> Chrome's DevTools supports setting event listener breakpoints for
> scrollsnapchanging and scrollsnapchange events.
>
>
>
> Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
>
> Yes
>
> scrollsnapchange and scrollsnapchanging are supported on all Blink platforms
>
>
>

> Is this feature fully tested by web-platform-tests <https://
> chromium.googlesource.com/chromium/src/+/main/docs/testing/
> web_platform_tests.md>?
>
> Yes
>
> https://wpt.fyi/results/css/css-scroll-snap-2/scrollsnapchange <https://
> wpt.fyi/results/css/css-scroll-snap-2/scrollsnapchange> contains the
> scrollsnapchange tests. https://wpt.fyi/results/css/css-scroll-snap-2/
> scrollsnapchanging <https://wpt.fyi/results/css/css-scroll-snap-2/
> scrollsnapchanging> contains the scrollsnapchanging tests.

>
>
>
> Flag name on chrome://flags
>
> None
>
>
> Finch feature name
>
> CSSScrollSnapChangeEvent, CSSScrollSnapChangingEvent
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>

> https://crbug.com/40273052 <https://crbug.com/40273052>

>
>
> Estimated milestones
>
> Shipping on desktop 127
>
> Shipping on Android 127
>
> Shipping on WebView 127
>
>
>
> 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).
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5826089036808192?gate=5441243751907328
> <https://chromestatus.com/feature/5826089036808192?gate=5441243751907328>
>
>
> Links to previous Intent discussions
>
> Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/
> blink-dev/CAA6pwF6S4v5fQjpeEHk4zgeVhUxn%3DRR%2BOVMSTL8-

> H%2Br2xd7h%3DQ%40mail.gmail.com <https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/
> CAA6pwF6S4v5fQjpeEHk4zgeVhUxn%3DRR%2BOVMSTL8-
> H%2Br2xd7h%3DQ%40mail.gmail.com>
>
> This intent message was generated by Chrome Platform Status <https://
> chromestatus.com/>.
>
> --
> 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 <mailto:blink-
> dev+uns...@chromium.org>.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CAA6pwF6jFwLW-0t46A-AKkDUVkdKc-
> ssqv26V3UqM6S8FJ51zA%40mail.gmail.com <https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CAA6pwF6jFwLW-0t46A-AKkDUVkdKc-
> ssqv26V3UqM6S8FJ51zA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Tab Atkins Jr.]

On Mon, May 27, 2024 at 1:04 PM 'Emilio Cobos Álvarez' via blink-dev
<blin...@chromium.org> wrote:
> Has this been reviewed by the CSSWG? (not only the PR I mean, but the
> feature as a whole). The spec PR:
> https://github.com/w3c/csswg-drafts/pull/9515
>
> Doesn't mention any issue or discussion in a CSSWG call. Usually having
> a resolution for a new feature is a requirement to get it merged...
>
> We recently discussed a similar process mishap in
> https://github.com/w3c/csswg-drafts/issues/7767, would be good not to
> repeat it.

The feature was discussed and resolved on back in 6985
<https://github.com/w3c/csswg-drafts/issues/6985#issuecomment-1049029573>
(the issue is originally just about pseudo-classes, but the discussion
on the call was about snap events as well, and the resolution covered
that explicitly). We've also discussed some of the features's issues
in the WG in the last few months.

But since it's been a while since the original resolution, I've gone
ahead and tagged 6985 with Agenda+ just to give a heads-up to the
group. (David and flackr will be able to discuss it on the WG call
next week; I'll be at CSS Day. Or we can talk about it at the f2f in
two weeks.)

> I see some follow-up issues on naming and such things are still open
> (though some /do/ have resolutions). Do you plan to update the spec and
> tests?

The relevant issues have all been resolved, but you're right, only the
naming one had been editted so far. David's working on the other two
(bubbling, and pseudo-elements), and we'll get them reviewed and
merged asap. Thanks for the heads up.

~TJ

[Emilio Cobos Álvarez]

Sounds good, thanks Tab!

 -- Emilio

[Alex Russell]

For the avoidance of doubt, we don't block on WG consensus. If there's sufficient evidence that a feature has been developed with high quality and strong developer support, that's enough for us. CSS WG blessing is strictly nice-to-have.

[Alex Russell]

Ok, looking at these explainers, I'm not sure we have enough to go on to approve this Intent right now.

First, use-cases are listed, but no example code is provided to show what developers have to do today vs. how this new design will address what's problematic about the current situation. These documents are regurgitated IDL with no considered alternatives provided. It also isn't clear if or why the SnapEvent interface contains enough information to address any of the listed use-cases.

As we'd be going first, I'd be looking for some amount of developer support to move forward. Is there a reason this isn't going to OT to get that sort of input?

Best,

Alex

[Philip Jägenstedt]

Developer excitement about this is evident in https://github.com/w3c/csswg-drafts/issues/156. It was filed by a web developer and the 100 thumbs up are probably mostly from other web developers.

These events seem like obvious missing functionality similar to the scrollend events, without the events you need to listed to scroll events and guess when it has come to a stop.

That being said, examples of what can be built with these events would be very nice. For the scrollsnapchange event it's easy to imagine updating some state below a carousel to match the snapped element, such as item description or store inventory. For scrollsnapchanging I don't dare hazard a guess, can someone say what the canonical use case for this is?

Looping in @Adam Argyle 

--

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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50e066e9-c852-403d-970c-6a1e691cdb98n%40chromium.org.

[Robert Flack]

On Wed, Jun 5, 2024 at 12:16 PM Philip Jägenstedt <foo...@chromium.org> wrote:

Developer excitement about this is evident in https://github.com/w3c/csswg-drafts/issues/156. It was filed by a web developer and the 100 thumbs up are probably mostly from other web developers.

These events seem like obvious missing functionality similar to the scrollend events, without the events you need to listed to scroll events and guess when it has come to a stop.

That being said, examples of what can be built with these events would be very nice. For the scrollsnapchange event it's easy to imagine updating some state below a carousel to match the snapped element, such as item description or store inventory. For scrollsnapchanging I don't dare hazard a guess, can someone say what the canonical use case for this is?

IMO scrollsnapchanging is the more useful event. It has a similar purpose to what the input event is prior to the change event fired on form controls or the scroll event is to scrollend, being an earlier signal of the eventual final result which can be useful for immediate feedback. scrollsnapchanged could be inferred by the combination of the latest scrollsnapchanging before the scrollend event.

For carousels, it can be extremely useful for immediate feedback when the carousel is scrolling to a particular item to highlight the destination right away. E.g. right now the carousels on https://gui-challenges.web.app/carousel/dist/ only update on scrollend but in many native carousels (e.g. https://www.airbnb.ca/) the active item is updated throughout the scroll before it settles.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfmkDtPv6vW_dbhB6WAayVkkLor0fsRdtdK5rcVU_1%2BYw%40mail.gmail.com.

[David Awogbemila]

Hi Alex, thanks for yout input!

(Like Tab said, we’re planning to have a review of the feature as a whole so I plan to share any feedback from that here, but since that won’t happen for at least another week, I wanted to update this thread in the meantime.)

I'm now hosting the explainer and I've updated it to reflect the research and investigation which went into the API design (which I certainly should have done earlier). We've discussed all of the non-trivial decisions made for the API over many CSSWG issues.  The API choices reflect the minimum amount of information that meets the needs of use cases we have evidence of interest in: the element that was selected as the snap target, and deferred adding other bits of information for which we don't have quite as much evidence. We think that an origin trial might bring to light other things that could be added to the interface but is not likely to provide more information about the single data point we've currently put in the interface (the selected element, which satisfies most of the use cases we are aware of) so we thought not blocking that piece on an origin trial might be a good idea. Happy to hear further thoughts.

[Alex Russell]

Thanks for the link, Phillip. Absolutely agree that this is an unmet need and something we should have added long ago; I'd just like to see evidence that we're matching that need with a sufficient solution and that we've done our homework. There's almost nothing worse than getting to the end of a launch and realizing that some important use-cases isn't covered, and I don't have confidence based on what we've produced that we would not end up in this situation.

An exhaustive explainer with considered alternatives and sample code would unblock this from my end.

Best,

Alex

[Adam Argyle]

Indeed, developer sentiment is full of excitement! Who wouldn't want to throw out their hyper intersection observers with a perfectly timed callback? or even better, getting insights into the concept of "changing" which is currently opaque to authors.

> Philip: For the scrollsnapchange event it's easy to imagine updating some state below a carousel to match the snapped element, such as item description or store inventory. For scrollsnapchanging I don't dare hazard a guess, can someone say what the canonical use case for this is?

I think you'll find that snapchanging is very prominent in mobile gesture based UI and may be used even more than snapchange. Like one of those features you can't unsee once you see it working. Consider this video I took of a game on mobile, snapchanging and snapchanged are distinctly used for 2 separate moments of UI feedback. I have many examples like this! The examples are what led to the APIs. Another really common example will be revealing the caption or action buttons in a carousel. Which it's probably worth noting we're working on a CSS way to know some of this information too, we're prototyping snapped as a "state query."  

Here's a few demo's showing some "picker" use cases, which I feel will be the majority cases, where folks are observing the snapped or soon to be snapped item and updating ancillary UI for the user. I have a backlog of many more to make 😅 Think of these things like snap triggered animation, which can be a very healthily compliment to scroll driven animation (which currently doesn't have a "trigger" feature, only linked).

I bucket the 2 events like:

- the scrollsnapchanging event is eager to provide user feedback, can fire many more times than change

- while scrollsnapchange is great for user feedback after they've lifted their finger or scroll has ended, timed better for confirmation or whatever. I show an example below that I use change instead of changing so the animation trigger isn't too busy.

Color picker: 

https://codepen.io/argyleink/pen/zYXdgew 

Date time picker (both eager and timed): 

https://codepen.io/argyleink/pen/WNageoZ

Date time picker (eager): 

https://codepen.io/argyleink/pen/oNOWwKq

Date time picker (timed for view transitions): 

https://codepen.io/argyleink/pen/LYvzGRW 

> Regarding origin trials: 

I havent met a front-end dev who's been interested in an origin trial, but fullstack or backend devs needing a high impact business feature (like a fugu feature) do. We didn't do an origin trial for scrollend, and that felt like the right path forward. Feels like these 2 events are in a similar bucket as scrollend.

Let me know how else I can help!  

[Yoav Weiss (@Shopify)]

On Fri, Jun 7, 2024 at 5:47 PM 'Adam Argyle' via blink-dev <blin...@chromium.org> wrote:

Indeed, developer sentiment is full of excitement! Who wouldn't want to throw out their hyper intersection observers with a perfectly timed callback? or even better, getting insights into the concept of "changing" which is currently opaque to authors.

> Philip: For the scrollsnapchange event it's easy to imagine updating some state below a carousel to match the snapped element, such as item description or store inventory. For scrollsnapchanging I don't dare hazard a guess, can someone say what the canonical use case for this is?

I think you'll find that snapchanging is very prominent in mobile gesture based UI and may be used even more than snapchange. Like one of those features you can't unsee once you see it working. Consider this video I took of a game on mobile,

It's 404ing for me.. 

 

--

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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEZW8QGW%2BY1oRLHOEAOKpbQhZBjNCLdRJWeT6jF8uwtBQw1niw%40mail.gmail.com.

[Adam Argyle]

Slightly different strategy to share a public photo https://photos.app.goo.gl/5vHQ4cecJqHWN7DGA, try this one?  😅

[Yoav Weiss (@Shopify)]

LGTM1

This seems like a useful addition, with lots of developer demand. While more detailed explainers would have been helpful, I don't feel it's a blocker atm, as the demos provided helped me understand what we're shipping and how developers will use it.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKwCDrS8c%3DS33mFkqzWP-ntCfn1TUBuuqUDX0MSJei5FQ%40mail.gmail.com.

[Chris Harrelson]

LGTM3

Please do ping this thread with an updated explainer once you have it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/49102cc1-6d3f-406e-a98c-19f44a80a20f%40gmail.com.

[David Awogbemila]

Thanks all! I've updated the explainer (it's now one unified explainer for both events).