- 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