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.
--
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.
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 signalsHave 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?
--
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.
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.