Re: Scroll focus when reaching the end of a scrollable element

On Tue, Sep 23, 2014 at 5:58 PM, Rick Byers <rbyers@chromium.org> wrote:
> On Tue, Sep 23, 2014 at 8:31 PM, Eric Andrew Lewis
> <eric.andrew.lewis@gmail.com> wrote:
>>
>> On Tue, Sep 23, 2014 at 7:21 AM, Rick Byers <rbyers@chromium.org> wrote:
>> > IE has -ms-scroll-chaining for precisely this problem.  Does that do
>> > everything you'd want?
>>
>> Yes, that's the ticket. One note: -ms-scroll-chaining only applies to
>> touch-based devices. I'd hope this would apply to mouse-based browsers as
>> well.
>
>
> The MSDN docs say "touch and touchpad".  To me this means any statefull
> scrolling - that is scrolling with a begin (touch down), series of updates
> (movement), and end (lift) phases.  The problem with true mouse wheel
> scrolling is that each step is independent - there's no state to associate
> one step with a previous step, so it's not clear when you should "lock" to a
> target node and so the concept of scroll-chaining is probably not well
> defined.
>
> In blink we really only have this statefull property for touch scrolling
> (i.e. we hit-test once when scrolling starts, and don't re hit-test on each
> update in the gesture).  We convert touchpad into a series of wheel events,
> each of which hit tests on each update.  Personally I find this annoying -
> it means I may scroll through a long document and suddenly switch to
> scrolling an overflow:scroll div without having lifted my fingers.  To make
> scroll-chaining apply to touchpad scrolling, I think we'd want to first
> shift our touchpad scrolling from the wheel-like behavior to the
> touchscreen-like behavior.

That actually goes beyond what scroll-chaining offers.  You're talking
about "locking" a scroll to a given container, such that you don't go
further up *or* further down the scrolling-container hierarchy during
a scroll.  -ms-scroll-chaining only covers the "dont' go further up"
scenario.

If you limit yourself to only being concerned about it going further
up the tree, you don't need to worry about "stateful" scrolls;
preventing a scroll from moving further up the tree works equally well
for multiple individual updates a la mousewheel scrolling.  It's only
the "down the tree" limitation (which I agree, is rather annoying and
would be nice to control) which needs to differ between stateful and
non.

~TJ

Received on Wednesday, 24 September 2014 01:04:01 UTC