W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2019

[csswg-drafts] [css-scroll-snap-1] Compat between webkit and blink/gecko regarding "implicit" scroll boundary snap positions (#4037)

From: jonjohnjohnson via GitHub <sysbot+gh@w3.org>
Date: Sun, 16 Jun 2019 22:54:48 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-456690781-1560725687-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:49 UTC