[css-scroll-snap-1] Compat between webkit and blink/gecko regarding "implicit" scroll boundary snap positions #4037
Description
https://drafts.csswg.org/css-scroll-snap-1/#choosing
Regarding https://codepen.io/anon/pen/XLwybE
scroll {
overflow-y: auto;
height: 100px;
scroll-snap-type: y mandatory;
}
block {
height: 50px;
margin: 150px 0;
scroll-snap-align: center;
}<scroll>
<block></block>
</scroll>All major vendors, of course, load in with a scroll position of 0. However, webkit is the only implementation where once scrolled, a user is allowed to snap back to the 0 scroll position, where "implicit" snap positions are created at the scroll boundaries.
Aside from language like...
A naïve algorithm for selecting a snap position can produce behavior that is unintuitive for users, so care is required when designing a selection algorithm.
User agents must ensure that a user can “escape” a snap position
...the current spec mostly eludes to matching the blink/gecko behavior. If no elements create a snap position for the "scrollmin" or "scrollmax" scroll positions of their scroll container, then a user can never snap/resolve to a scroll boundary without being "bounced" back, almost with pseudo-rubberbanding visual.
https://bugs.chromium.org/p/chromium/issues/detail?id=953979
https://bugzilla.mozilla.org/show_bug.cgi?id=1545316
Are blink/gecko correct? Should the spec be made clearer? Or changed to agree with webkit?