Re: beforescroll and using DOM events for extensibility

On 10/03/2014 04:14 PM, Rick Byers wrote:
> Jonas and Anne raised some good concerns (https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230) with the way we're thinking of using DOM events for
> beforescroll (https://docs.google.com/a/chromium.org/document/d/1oEVWIVdMZ2OlVZMvcZZ3IgaT6RAUNSKAzpzb9AlVeLw/edit#).  Moving the discussion here
> (independent from the other thread about the performance tradeoffs of enabling JS customization of scrolling).
>
>  > Jonas Sicking:
>  > >
>  > > Enabling pages to trigger actions that are triggered by other larger features is indeed usually a good idea,
>  > > for the reasons enumerated in the extensible web manifest.
>  > >
>  > > However enabling pages to trigger those actions by creating an event and calling dispatchEvent is very
>  > > awkward.
>  > >
>  > > Normally JS APIs are built using functions. Like "window.doStuff(5)". While possible to use a pattern like
>  > >
>  > > event = new CustomEvent("stuff");
>  > > event.detail = 5;
>  > > window.dispatchEvent(event);
>  > >
>  > > it is quite awkward.
>  > > Instead define a JS function, and then define that this function is called as default action in response to some particular event.
>  > >
>  > Anne van Kesteren:
>  >
>  > It's not just awkward, it doesn't match the prescribed events model. Which is that dispatchEvent() returns
>  > a boolean and based on that you might initiate a default > action (or not). So the polyfill would always be
>  > along the lines of
>  >
>  >   var ev = ...
>  >  if(obj.dispatchEvent(ev))
>  >    obj.defaultAction()
>  >
>  > That just dispatching the event invokes obj.defaultAction() breaks the event model and is a
>  > longstanding bug for some events in browsers (this bug, indeed).
> This makes perfect sense when the browser behavior for an event should come strictly after any behavior on the page (i.e. it's really the final
> "default action" - coupled with the thing that generated the event in the first place).  But that strict "JS before browser" pattern isn't always
> consistent with the extensible web ideas of some browser behavior being built on the same primitives available to the application.  For full
> composition of built-in and JS behavior, there may be cases where some JS behavior happens only after some built-in behavior has been given a chance
> to run.
>
> In particular, for scrolling, consider the case of a scrollable DIV nested inside a scrollable document.  We want to allow the scrolling behavior of
> the DIV to either be supplied by the browser or by some JS library.  In either case, when the DIV has reached its scroll extent, further scrolling
> chains up to the document.
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).



>
> In our efforts to make this behavior extensible, it seemed most natural to model the scroll request as a DOM event,
Events aren't requests. Events tell that something, well event, will happen or just happened.

(dispatching click event is a special legacy case, but I don't think we can ever get rid of it.)

> and the chaining as bubbling of
> that event.  But for proper composition, this implies that browser behavior must act as just an event handler - not a default action that occurs
> strictly after event processing.
>
> Personally I really like the idea of the browser relying on the same addEventListener mechanism available to applications in order to trigger certain
> behavior.
What same addEventListener mechanism? web pages add listeners in such way that stopPropagation affects to them.
Browser implementation don't care about stopPropagation.

> It ensures natural / seamless composition between JS and native behavior, similar to what you see in traditional OO UI frameworks (where
> the framework relies on the same OO design principles for composition as are available to the application for extensibility).  We actually already
> have a number of places that do this in blink and webkit (most commonly in shadowDOM components, eg. for form elements).
Sounds like a bug in shadow DOM if it needs to rely on event dispatching to trigger default action, and it is against the current spec.
There is a reason why XBL1 has a way to add listeners to system event group (aka, the group which is for browser implementation only for dealing 
default actions).


-Olli


>
> Thoughts?
>     Rick
>
>

Received on Friday, 3 October 2014 14:01:28 UTC