Re: beforescroll and using DOM events for extensibility

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?



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

Received on Friday, 3 October 2014 16:30:16 UTC