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

On Tue, Sep 23, 2014 at 9:03 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:
>
>
> 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.
>

Right, I agree there's two separate concepts here.  The latter isn't really
about "going down" the scrolling hierarchy though - it's about when you do
hit testing vs. using the result from previous hit test.  Eg. one mouse
wheel turn may scroll a div and the next scroll one of it's ancestors due
to the new hit test returning a different result from the previous one.

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.
>

Hmm.  I don't have a Windows device handy to check, but I don't believe
that's quite how scroll-chaining works.  In particular consider the
following sequence on a touchpad or touchscreen:
 1. touch down on a div
 2. drag until the div reaches it's scroll limit
 3. continue dragging
 4. lift and touch down on the div again
 5. drag again in the same direction

With '-ms-scroll-chaining: chained' the scroll at step 3 and 5 will scroll
the ancestor.  With '-ms-scroll-chaining: none', the scroll at step 3 will
invoke the bounce effect, but the scroll at step 5 will scroll the
ancestor.  Otherwise it would be possible to "get stuck" and be unable to
scroll the document when the only element in view was a DIV with scroll
chaining disabled.  The key text in the MSDN documentation is "when a user
hits the scroll limit *during a manipulation*".  It doesn't change anything
about what will happen when you start a new manipulation.  This "during a
manipulation" is why I say it's dependent on the concept of stateful
scrolling.

Of course Roc's describing of inferring transactions for input devices that
don't otherwise supply them is a good solution to making this apply
everywhere.