Re: beforescroll and using DOM events for extensibility

On Fri, Oct 3, 2014 at 12:29 PM, Olli Pettay <olli@pettay.fi> wrote:

> On 10/03/2014 07:25 PM, Rick Byers wrote:
>
>> On Fri, Oct 3, 2014 at 12:10 PM, Rick Byers <rbyers@chromium.org <mailto:
>> rbyers@chromium.org>> wrote:
>>
>>     On Fri, Oct 3, 2014 at 11:38 AM, Olli Pettay <olli@pettay.fi <mailto:
>> olli@pettay.fi>> wrote:
>>
>>         On 10/03/2014 06:26 PM, Rick Byers wrote:
>>
>>             On Fri, Oct 3, 2014 at 10:00 AM, Olli Pettay <olli@pettay.fi
>> <mailto:olli@pettay.fi> <mailto:olli@pettay.fi <mailto:olli@pettay.fi>>>
>> wrote:
>>
>>
>>
>>                  So something like element.requestScroll(x, y); could be
>> exposed to the web pages and it would behave as if user had initiated the
>> scroll
>>                  (at least in most cases. Maybe we'll need something like
>> trusted scroll which is coming from user).
>>
>>
>>             We already have that - Element.scrollBy. What we don't have
>> is a way to customize how scroll inputs (deltas) are distributed to the
>>             outputs (which
>>             element(s) will respond).
>>
>>
>>
>>         Which is why I think we should have another method which
>> propagates scrolling request to the nearest scrollable element or so.
>>
>>
>>     The challenge is that "nearest scrollable element" is exactly what
>> needs to be customizable.  Eg. imagine I'm implementing a 3d spinning
>>     carousel.  It's just a DIV, not scrollable by any native browser
>> scroll logic.  How should this DIV register itself as being a handler of
>> scroll
>>     gestures?
>>
>>
>> I guess the obvious thing to do is add methods like:
>>
>> Element.dispatchScrollRequest(ScrollRequest)
>> Element.addScrollHandler(callbackTakingScrollRequest)
>> Element.removeScrollHandler(callback)
>>
>
>
> So sounds like you want something pretty close to wheel event, which one
> can cancel.
> Why wouldn't Element.requestScroll() work, if it ends up dispatching an
> event, and if prevent default isn't called it scrolls the nearest
> scrollable area?


For correct semantics we need the JS handling and native handling to be
interleaved in a single walk up the tree.  Not one walk for JS handling,
then afterward a separate walk for native handling.  Take the
pull-to-refresh component on the document example again.  If someone (or
some JS) scrolls inside of an element with it's own native scroller, it
should reach it's scroll limit first (native behavior) before attempting to
scroll the document (custom JS behavior).

In many cases you could probably work around this.  Eg. the component's
event handler could do it's own walk up from the event target node to see
if there's a native scroller that isn't yet at it's scroll limit in the
direction scrolled.  This is complex and brittle though.  An
"Element.findNearestScrollableAncestor(scrollDirection)" API could help a
lot here.  But the main case that's very hard to solve is when the nested
scroller is inside of a cross-origin iframe.


>> This feels like it duplicates a lot of the DOM event handling machinery
>> (eg. we'd probably want capturing handlers, constructors, propagation
>> through
>> shadow DOM / HTML templates, etc.).  But if there's consensus that this
>> is better than using (abusing?) DOM events here, then it's probably OK with
>> me.  We'd probably want to define this system in a generic way so other
>> rich composition scenarios could follow the same pattern without having to
>> re-specify the whole thing.  Perhaps DOM events should even be explained
>> in terms of some lower level composition pattern like this?
>>
>>
>>
>>         -Olli
>>
>>
>>
>>
>