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

Yes, agreed that the observability needs more mention here.  Part of the problem is that "observability" is a bit of a fuzzy concept when it comes to performance.  Is the scroll performance of a page "observable"?  Well if scrolling is blocked for 1s, or there's noticeable UI mis-synchronization (as can be seen [here](http://output.jsbin.com/qixakeh)) then I'd say that counts as "observable".  I'm tweaking this text to better reflect that.

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