Intent to Implement and Ship: Scroll Snap Stop

186 views
Skip to first unread message

Majid Valipour

unread,
May 6, 2019, 10:43:19 AM5/6/19
to blink-dev
maj...@chromium.org https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop Specification: https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop Demo: https://snap.glitch.me/carousel-with-snap-stop.html N/A. Pre-existing feature of an established specification. Normally an inertial scroll operation (such as a swipe gesture) may skip several possible snap positions in favor of a snap position that is closer to its natural end point (which depends on platform and gesture characteristics such as velocity). scroll-snap-stop enables authors to designate a snap position such that it traps the inertial scrolling operations preventing the scroll from skipping it.
Requesting to ship in M75. Some forms of paginated scrolling experiences require more control over inertial and directional scroll gestures. A common example of this are full-sized paginated image carousels where they move one image at the time (this is common in native mobile galleries as well). This feature enables css scroll snap to support such usecases.
We are the first to implement this feature. So there is some risk that other vendors would not implement it. But I believe the risk is small here since the there was consensus in CSSWG to include it and since 2016 which it was added we have not heard any objections from other vendors. This was initially low priority for us but developer feedback has convinced us that this is needed for some key usecases of the css scroll snap. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive Several developers (e.g., comments on crbug, AirBnb , AMP) have requested this. A particular popular usecase is to create full-size image carousels that only snap to the next image (e.g., similar to native mobile apps). Normally a fling gesture snaps to the closest area near its "natural end point" which is not the right behavior in such usecases. Unfortunately the css property `scroll-snap-stop` was inadvertently exposed to the web when css scroll snap was initially shipped (M69). This means that it is impossible to easily feature detect this via `CSS.supports()`. A more convoluted way to feature detect is to create a hidden scroller with two snap areas and scroll it using `Element.scrollBy()` to see if it snaps to the correct one. At the moment the usage is low (0.005%) which is good. If we decide not to ship we should remove this ASAP.
Yes Yes https://wpt.fyi/results/css/css-scroll-snap/scroll-snap-stop-always.html https://bugs.chromium.org/p/chromium/issues/detail?id=823998 https://www.chromestatus.com/features/5439846480871424

Yoav Weiss

unread,
May 9, 2019, 11:50:29 AM5/9/19
to Majid Valipour, blink-dev
On Mon, May 6, 2019 at 7:43 AM Majid Valipour <maj...@chromium.org> wrote:
maj...@chromium.org https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop Specification: https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop Demo: https://snap.glitch.me/carousel-with-snap-stop.html N/A. Pre-existing feature of an established specification.

What do you mean by "pre-existing"?
 
Normally an inertial scroll operation (such as a swipe gesture) may skip several possible snap positions in favor of a snap position that is closer to its natural end point (which depends on platform and gesture characteristics such as velocity). scroll-snap-stop enables authors to designate a snap position such that it traps the inertial scrolling operations preventing the scroll from skipping it.
Requesting to ship in M75.

Hasn't M75 branched already?
 
Some forms of paginated scrolling experiences require more control over inertial and directional scroll gestures. A common example of this are full-sized paginated image carousels where they move one image at the time (this is common in native mobile galleries as well). This feature enables css scroll snap to support such usecases.
We are the first to implement this feature. So there is some risk that other vendors would not implement it. But I believe the risk is small here since the there was consensus in CSSWG to include it and since 2016 which it was added we have not heard any objections from other vendors. This was initially low priority for us but developer feedback has convinced us that this is needed for some key usecases of the css scroll snap. Firefox: No public signals Edge: No public signals Safari: No public signals

Have you tried to gather signals from other vendors? Filed issues?
 
Web developers: Positive Several developers (e.g., comments on crbug, AirBnb , AMP) have requested this. A particular popular usecase is to create full-size image carousels that only snap to the next image (e.g., similar to native mobile apps). Normally a fling gesture snaps to the closest area near its "natural end point" which is not the right behavior in such usecases. Unfortunately the css property `scroll-snap-stop` was inadvertently exposed to the web when css scroll snap was initially shipped (M69). This means that it is impossible to easily feature detect this via `CSS.supports()`. A more convoluted way to feature detect is to create a hidden scroller with two snap areas and scroll it using `Element.scrollBy()` to see if it snaps to the correct one.

That seems bad... Is there any discussion happening on ways to resolve this?
 
At the moment the usage is low (0.005%) which is good. If we decide not to ship we should remove this ASAP.

Is this a Chrome-only issue? Or does it effect other vendors?
 
Yes Yes https://wpt.fyi/results/css/css-scroll-snap/scroll-snap-stop-always.html https://bugs.chromium.org/p/chromium/issues/detail?id=823998 https://www.chromestatus.com/features/5439846480871424

--
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/CAB8RdXsbo6QgNEp%3DoFJn8LKxuoUGD5jDmR1YUSJj1YmkowttHQ%40mail.gmail.com.

Majid Valipour

unread,
May 9, 2019, 3:06:11 PM5/9/19
to Yoav Weiss, Majid Valipour, blink-dev
From: Yoav Weiss <yo...@yoav.ws>
Date: Thu, May 9, 2019 at 11:50 AM
To: Majid Valipour
Cc: blink-dev



On Mon, May 6, 2019 at 7:43 AM Majid Valipour <maj...@chromium.org> wrote:
maj...@chromium.org https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop Specification: https://drafts.csswg.org/css-scroll-snap/#scroll-snap-stop Demo: https://snap.glitch.me/carousel-with-snap-stop.html N/A. Pre-existing feature of an established specification.

What do you mean by "pre-existing"?

By pre-existing I am referring to the fact that this feature has been in the scroll snap specification since 2016 per CSSWG process. This is a fairly small 
feature of the scroll snap and the rest of the scroll snap feature set has shipped in Chrome and Safari (and soon in Firefox).

I am not sure what is our TAG review requirement for something like this. It didn't seem to me that it was needed so I put N/A.  I have also discussed this offline with Tab (one of the spec editors) and he agrees with this assessment.
If API Owners think it is required that I can retro-actively submit a TAG review request as well.

 
 
Normally an inertial scroll operation (such as a swipe gesture) may skip several possible snap positions in favor of a snap position that is closer to its natural end point (which depends on platform and gesture characteristics such as velocity). scroll-snap-stop enables authors to designate a snap position such that it traps the inertial scrolling operations preventing the scroll from skipping it.
Requesting to ship in M75.

Hasn't M75 branched already?

That is correct. This is already implemented and is in M75 currently.
We should have sent this intent to ship sooner really but it was missed. (See below for a bit more explanation on that).
 
 
Some forms of paginated scrolling experiences require more control over inertial and directional scroll gestures. A common example of this are full-sized paginated image carousels where they move one image at the time (this is common in native mobile galleries as well). This feature enables css scroll snap to support such usecases.
We are the first to implement this feature. So there is some risk that other vendors would not implement it. But I believe the risk is small here since the there was consensus in CSSWG to include it and since 2016 which it was added we have not heard any objections from other vendors. This was initially low priority for us but developer feedback has convinced us that this is needed for some key usecases of the css scroll snap. Firefox: No public signals Edge: No public signals Safari: No public signals

Have you tried to gather signals from other vendors? Filed issues?

Firefox has alread a bug tracking implementation of feature which states that they want to implement it to match spec. So I think it is more accurately "Public support" but I just asked them to confirm again.
I just filed a Webkit bug to get their signal as well.

FWIW here is the meeting notes for the standard discussion where the feature was added to the spec and Microsoft and Apple engineers were actively involved. I will update if I hear anything else.

 
Web developers: Positive Several developers (e.g., comments on crbug, AirBnb , AMP) have requested this. A particular popular usecase is to create full-size image carousels that only snap to the next image (e.g., similar to native mobile apps). Normally a fling gesture snaps to the closest area near its "natural end point" which is not the right behavior in such usecases. Unfortunately the css property `scroll-snap-stop` was inadvertently exposed to the web when css scroll snap was initially shipped (M69). This means that it is impossible to easily feature detect this via `CSS.supports()`. A more convoluted way to feature detect is to create a hidden scroller with two snap areas and scroll it using `Element.scrollBy()` to see if it snaps to the correct one.

That seems bad... Is there any discussion happening on ways to resolve this?
 

I filed a bug with more details on this and two alternative approaches to dealing with it. My current thinking is that we should ship and thus fix the implementation as soon as possible since there is no practical way to unship.
I have developed an alternative feature detection mechanism. While this is not as simple as `CSS.supports` but it is not too bad. It does means a bit more work on the developer side but I cannot think of any solution that avoids this without somehow unshiping the
property from M69-M74. Right now usage is very low and as the feature gets wider adoption and M74 usage becomes lower hopefully this becomes less of a problem.

Note that scroll-snap-stop was included in the original Intent-to-Ship as a list of features we like to ship in subsequent milestones. I think this may have been a contributing factor on it being inadvertently exposed too early and was not considered
a new API surface.
 
At the moment the usage is low (0.005%) which is good. If we decide not to ship we should remove this ASAP.

Is this a Chrome-only issue? Or does it effect other vendors?

Chrome only. We are not aware of any other browser shipping this property yet.

Boris Zbarsky

unread,
May 9, 2019, 4:12:26 PM5/9/19
to Majid Valipour, Yoav Weiss, blink-dev
On 5/9/19 3:05 PM, Majid Valipour wrote:
> Firefox has alread a bug
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1312165> tracking
> implementation of feature which states that they want to implement it to
> match spec.

The only statement along those lines in that bug is from the bug
reporter, who has been involved in various Mozilla-related things
(Firebug, MDN, devtools a bit) but not any of the decision-making or
implementation work that would be relevant here.

"No public signals" is the right signal at the moment, as far as I can tell.

I don't think anyone who knows anything about implementation and
position status was cced on that bug; I poked someone who might know at
least who would know.

-Boris

Majid Valipour

unread,
May 10, 2019, 9:50:57 AM5/10/19
to Boris Zbarsky, Majid Valipour, Yoav Weiss, blink-dev
Thanks Boris for the correction and pinging that issue. Hiroyuki who is 
implementing this on Gecko side has now confirmed that they plan to 
implement it but only after they get the core features implemented. 
This makes sense to me. We basically implemented scroll snap in the 
same order as well.

Now we can confidently put Firefox in the "Public support" category.

Majid

Daniel Bratell

unread,
May 16, 2019, 3:59:18 PM5/16/19
to Boris Zbarsky, Majid Valipour, Yoav Weiss, blink-dev
Alex, Yoav and I discussed this at the weekly Blink API Owner meeting and concluded that it was possible to ship it.

We have one request though: Since this might cause web sites to behave in an unintended fashion if a web site use @supports and run in Chromium 69-75 (approx, you have the exact versions), we want you to send a PSA to embedd...@chromium.org to give lagging embedders a bit of a heads-up.

And LGTM1

/Daniel
--
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/CAB8RdXsVOf-u%2B0ovtAuB2-5gYb3tLrP%2BSYddDvDdDvH0hUWR8w%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Yoav Weiss

unread,
May 22, 2019, 4:06:37 PM5/22/19
to Daniel Bratell, Boris Zbarsky, Majid Valipour, blink-dev
LGTM2

Rick Byers

unread,
May 22, 2019, 4:35:43 PM5/22/19
to Yoav Weiss, Daniel Bratell, Boris Zbarsky, Majid Valipour, blink-dev
LGTM3

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

Majid Valipour

unread,
May 23, 2019, 11:39:53 AM5/23/19
to Rick Byers, Yoav Weiss, Daniel Bratell, Boris Zbarsky, Majid Valipour, blink-dev
Thank you!

To close the loop on this one. I have sent a PSA note to this PSA note to embedder-dev as requested.
The affected versions are 69-73 and here a handy table with more details for future reference.


| Chrome Version | scroll-snap-stop property |
|----------------------------|------------------------------------------------------------|
| 68 and before | Does not exist |
| 69 - 73 | Property exists [1] but not functional |
| 74 and after | Property exists and functional [2] |


[1] CSS.supports('scroll-snap-stop:always') returns true but the property is not honored. Here is an alternative feature detection method that works.
[2] In 74 we honor scroll-snap-stop but there is a known bug (fixed in M75) where it is possible to sometimes escape it in particular on diagonal swipe gestures.

Majid

Reply all
Reply to author
Forward
0 new messages