Re: why not MediaQueryList.onchange

btw, I looked at implementation in blink and it only supports the (speced)
callback variant. Still, the code is sufficiently different from other APIs
using events, and in fact, we found yet another bug in the implementation
:-/

I hear the concern that changing to events will change the semantics of
registering one listener multiple times. Would it help with this discussion
if I added a counter to see what percentage of page loads in chrome
register the same listener multiple times?

best
-jochen


On Thu, Apr 17, 2014 at 1:35 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Wed, Apr 16, 2014 at 12:34 PM, L. David Baron <dbaron@dbaron.org>
> wrote:
> > On Wednesday 2014-04-16 15:21 -0400, Elliott Sprehn wrote:
> >> lists = copy of mediaLists.
> >> for each list in lists:
> >>   eval media query of list.
> >> for each list in lists:
> >>   if list is dirty:
> >>     dispatch change event on list.
> >
> > I don't think there's any substantive difference in complexity
> > there; whether the copying is done at the start or inside the first
> > for loop doesn't really make much difference.
> >
> > (On the other hand, I don't recall how much complexity it adds to
> > make something be an EventTarget.  That said, I'm fine with using
> > events because they fit with the platform [1]; I just think the
> > complexity argument is not relevant.)
> >
> > -David
> >
> > [1] Although I'm not sure to what extent events work well as a
> >     mechanism for notifications about events internal to the
> >     platform rather than notifications of changes external to the
> >     platform.  For example, mutation events didn't work out all that
> >     well.
>
> Mutation events were bad for several reasons unrelated to "they're
> events", which don't apply to MQ change events.
>
> ~TJ
>
>