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

Ok, I'm adding some more text along these lines.  Rather than say the "passive" hint is being observed, I think it's valuable to be specific that it's only the "absence of non-passive listeners" that's being observed.  Eg. the dispatching code does NOT make any distinction between the cases of mixed passive/non-passive listeners and non-passive only listeners.

See also the discussion below about the passive flag.

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