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: bmaurer via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Mar 2017 17:41:30 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-289847944-1490722889-sysbot+gh@w3.org>
I think it'd be reasonable for a UA to show a visual indication of overscroll on a contained scroll. Rather than showing a bounce on the ancestor which would indeed look weird you'd show it on the element that was over scrolled. 

Sent from my iPhone

> On Mar 28, 2017, at 9:44 AM, Matt Rakow <notifications@github.com> wrote:
> 
> 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.
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


-- 
GitHub Notification of comment by bmaurer
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/769#issuecomment-289847944 using your GitHub account
Received on Tuesday, 28 March 2017 17:41:37 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:38 UTC