On Fri, Oct 3, 2014 at 12:10 PM, Rick Byers <rbyers@chromium.org> wrote: > On Fri, Oct 3, 2014 at 11:38 AM, Olli Pettay <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>> 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) 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:26:19 UTC