I hope you don't mind I put in my two cents since scroll snap is now stable and scroll-snap-stop might be dropped from the spec.

Snapping works well on smartphones but on an image gallery (like what you would see in Facebook or Google Photos), I invariably scroll too fast and go past a page when the behavior expected by an end user would be for the scrolling element to stop at the image immediately to the left or right. While I can think of other use cases for scroll snapping without scroll-snap-stop, adding it would make a much more significant impact on the web since we'll be able to get rid of many of the <framework>-image-gallery libraries

What is the reason scroll-snap-stop is "at risk"? After trying this new API for some carousels, it's clear that it's not something we will be able to use unless it has scroll-snap-stop. 

I think it's at-risk because it's possible to put an advertisement or some annoying thing in the middle of a page somewhere and with scroll-snap-stop: always make it so the user can't quickly scroll past it.

If a web site wants to do that, they will do it with JavaScript and there is nothing a user can do about it. If it is implemented in CSS at least it's possible for users and extensions to disable the feature for some sites.

I'm having trouble thinking of existing carousels or galleries in native apps and web sites implemented without a scroll-snap-stop equivalent so I doubt css-scroll-snap will have a real impact there unless it is implemented. That's unfortunate since custom scrolling and carousels are often severely broken on mobile.

Anyone know where discussion may be happening around scroll-snap-stop being "at risk"?

The closest, yet not really applicable, issue I could find raised with the csswg is https://github.com/w3c/csswg-drafts/issues/1552

I'm really hoping it's not removed, like stated previously, people can always force unhealthy ad viewing "stops" with javascript, we've all seen our share of roadblocks.

I already have a bunch of scroll-snap examples created that are severely hindered by a lack of scroll-snap-stop behavior.

Is it just internally that the blink devs are concerned about the implementation of `scroll-snap-stop`? If so, would it be good to bring it up to the whole csswg?

I understand the annoying/toxic ad example being a factor, but even so maybe there's a better way to go about it that folks across the working group can toss around and figure out?

Maybe stop should only have affect when used n conjunction with `mandatory`? That way it's in a snapport experience that affords "paging" always snapping to some point and not just scrollport that has one nasty ad placement snapping position in the middle that uses `scroll-snap-type: proximity`???

cc majidvp@chromium.org

I think it goes without saying everyone wants this but I don't blame the people who want to be careful about it.

Maybe a good middle ground would be to make scroll-snap-stop always only work with horizontal scrolling or something.