- From: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
- Date: Sun, 16 Jun 2019 22:54:48 +0000
- To: public-css-archive@w3.org
jonjohnjohnson has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-scroll-snap-1] Compat between webkit and blink/gecko regarding "implicit" scroll boundary snap positions == https://drafts.csswg.org/css-scroll-snap-1/#choosing Regarding ```css scroll { overflow-y: auto; height: 100px; scroll-snap-type: y mandatory; } bock { height: 50px; margin: 150px 0; scroll-snap-align: center; } ``` ```html <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? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4037 using your GitHub account
Received on Sunday, 16 June 2019 22:54:50 UTC