W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2017

Re: [csswg-drafts] [cssom-view] New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining)

From: Matt Rakow via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Mar 2017 16:43:56 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-289831218-1490719435-sysbot+gh@w3.org>
> A bit of history here, we developed overscroll-action API idea first in response to a specific set of overscroll navigation usecases. But now we think it is possible to address those use cases with scroll-boundary-behavior API in a simpler and more generic way.

> We should avoid having two different ways to control overscroll navigation actions. So if we allow scroll-boundary-behavior to control overscroll navigation then it is best to ditch overscroll-action.

Agreed.  From the Edge perspective, any UA reactions to scrolls beyond the boundary (navigation, pull-to-refresh, Flip Ahead) are well-controlled by simply blocking the propagation of the scroll above the root scroller.

> Right now it's not possible to propagate scrolling while disabling the overscroll animation. If this is something that's important perhaps a better proposal to cover the 4 logical states could be:
> `scroll-boundary-behavior: [auto || [ [propagate || contain] | [overscroll || no-overscroll] ]`

I think this proposal should be `[auto | contain] || [overscroll | no-overscroll]` for the reasons David and Majid mentioned in the previous comments about input type discrepancies and spelling difficulty.

That said, I'm not aware of any implementation that propagates in combination with showing a visual effect of any sort.  Implementation-wise this would be unusual since the transform from the input is "applied towards" a particular target.  Visually to a user it would also look strange as the ancestor scrolls (or does some other effect) while the child displays an effect that is meant to signify "you can't scroll any further".  When that effect is a bounce e.g. in response to touch panning it would result in the bounced content moving twice as fast as the user's finger (the transform being applied to both the element and its ancestor).  I don't think that's a combination we should support.

Without that combination there are only 3 states, which map to the `auto | contain | none` values.  I strongly prefer this option over providing 4 states.

GitHub Notification of comment by ChumpChief
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/769#issuecomment-289831218 using your GitHub account
Received on Tuesday, 28 March 2017 16:44:02 UTC

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