Re: [dom] Add EventListenerOptions and passive event listeners (#82)

> @@ -1057,6 +1096,25 @@ invoked, must run these steps:
>   <li><p><a>Dispatch</a> the <var>event</var> and return the value that returns.
>  </ol>
>  
> +<h3 id=observing-event-listeners>Observing event listeners</h3>
> +In general, developers do not expect the presence of an <a>event listener</a> to be
> +observable.  The impact of an <a>event listener</a> is determined by its <b>callback</b>.
> +That is, a developer adding a no-op <a>event listener</a> would not expect it to have
> +any side effects.
> +
> +Unfortunately, some event APIs have been designed such that implementing them
> +efficiently requires observing <a>event listeners</a>.  For example, sensor APIs which
> +enable an underlying device sensor, and touch APIs which can be used to block
> +asynchronous scrolling.  In some cases this problem can be mitigated by specifying
> +the event to be {{Event/cancelable}} only when there is at least one
> +non-{{EventListenerOptions/passive}} listener.  For example, non-{{EventListenerOptions/passive}}
> +{{TouchEvent}} listeners must block scrolling, but if all listeners are {{EventListenerOptions/passive}} then
> +scrolling can be allowed to start <a>in parallel</a> by making the {{TouchEvent}}
> +uncancelable (so that calls to {{Event/preventDefault()}} are ignored).

We should make a note here that this "passive" hint is being observed by the code that dispatches the event since any listeners added during dispatch that are not "passive" will not be able to affect the event. In effect, what happens is that having solely passive observers at the time of action influences the event being dispatched. (The dispatcher code will set its passive flag.)

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/82/files#r47618570