[whatwg] Mutation Observer arguments format

[Brian Kardell]

On Mar 12, 2013 12:06 PM, "Anne van Kesteren" <annevk at annevk.nl> wrote:
>
> On Tue, Mar 12, 2013 at 3:05 PM, Brian Kardell <bkardell at gmail.com> wrote:
> > I was going to mention this the other day - it works inter-operably
today,
> > so it seems like you probably don't want to break that.  Simultaneously
it
> > does seem to me that the API is more sensible and less confusing - is
there
> > any reason not change the proposal such that the intent is to to
deprecate
> > the existing way and consider the new/proposed API as merely
superceeding
> > the old?  Given that one is merely sugar on the other anyway - it
should be
> > possible to propose the change and augment/prollyfill the mapping I
think
> > and I see no reason you couldn't quickly roll that out natively given
its
> > simplicity.
>
> Yes, that is the basic argument made time and again. It neglects the
> costs. It takes away time from people that should probably work on
> other stuff, it increases the API surface area and what needs to be
> tested, and thereby increases the chance for mismatching functionality
> across user agents. Making changes, even seemingly trivial ones,
> across multiple independent engines is not something that should be
> taken lightly.
>
>
> --
> http://annevankesteren.nl/

Anne,

I feel like you've misunderstood my comments/observations.  Let me clarify
and see:

1) I think this API is more sensible - I had the same problem with mutation
observers api.

2) we should not be forever stuck with an unintuitive API

3) we have interop now and a mature spec, that sucks in retrospect that we
didn't see this earlier, but it is what it is.

4) this adds nothing in the way of features, it is merely sugar/better API
so it should be easily prollyfillable.  As such, I am suggesting that we
draft a proposal to do so, explain in detail how it would work (I gave a
high-level suggestion), provide test cases, etc... That's what prollyfills
are all about - a way to evolve outside the browser impl itself based on
competition and data which makes that part easier and makes sure we don't
take turns that users have problems with

... and ...

5)  should we reach that point (it is entirely possible we dont) the actual
implementation should be *comparatively *low cost.

Does it make sense?  Do you feel like I am hand-waving away any of your
concerns?  I hope not because the idea there is precisely to help address
concerns like these (as well as many others).


-Brian