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.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Chrome's DevTools supports setting event listener breakpoints for scrollsnapchanging and scrollsnapchange events.
scrollsnapchange and scrollsnapchanging are supported on all Blink platforms
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.
Shipping on desktop | 127 |
Shipping on Android | 127 |
Shipping on WebView | 127 |
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).
--
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.
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?
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.
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.
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,
--
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.
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.
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.