W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: Extending Mutation Observers to address use cases of

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 12 Feb 2014 14:33:02 -0800
Message-ID: <CA+c2ei_n1M0806PO2w5+Bw00fTDbOby9ux_e4iUx0sro=fnFqA@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Rafael Weinstein <rafaelw@google.com>, "Olli@pettay.fi" <olli@pettay.fi>, Bjoern Hoehrmann <derhoermi@gmx.net>, "public-webapps@w3.org WG" <public-webapps@w3.org>, Erik Arvidsson <arv@google.com>, Anne van Kesteren <annevk@annevk.nl>
On Wed, Feb 12, 2014 at 2:08 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Feb 12, 2014, at 11:23 AM, Rafael Weinstein <rafaelw@google.com> wrote:
>> In a certain sense, you can extend the argument that CE callbacks should be MO records, and you arrive at the conclusion that you don't need Custom Elements at all -- that everything can be implemented with Mutation Observers. But the point of Custom Elements is two fold:
>>
>> 1) To allow implementation of Elements by user-space code in roughly the same model as privileged code.
>> 2) To explain the platform.
>>
>> Put another way: the *implementation* of an element simply needs to be privileged in some respects. For custom elements, this means
>>
>> a) There can only be one. I.e., we don't allow multiple registration of the same element: Primary behavior is the domain of custom elements, secondary behavior is the domain of Mutation Observers
>> b) Callbacks need to fire ASAP. It's important that the implementation of an element get a chance to respond to events before other concerns so that it can create a synchronously consistent abstraction
>
> I'm not convinced that only custom elements require a synchronously consistent abstraction.

I want to be *very* careful about exposing synchronous callbacks.
While I'm sure a lot of authors will ask for it, it's a tremendous
footgun.

The first type of footgun that it is is that authors can footgun
themselves when using these callbacks. For example by accidentally
calling into external code while they are in an inconsistent state.
Another thing to remember here is that you can only really have one
consumer that truly receives synchronous callbacks. The moment you
have two observers it means that the second observer doesn't have time
to react before the first observer runs. This can be a problem both
for the first observer, since it sees a world where the mutation has
happened, but where the second observer hasn't had time to react to
it, and for the second observer, since the world can have changed
under it before it has had a chance to react to a mutation.

The second type of footgun is that by adding synchronous callbacks, we
are limiting our own ability to extend and optimize the platform since
we have to worry about JS callbacks running at inopportune times. So
by adding synchronous callbacks, we're footgunning ourselves.

>> To my mind, Custom Elements callbacks really *should* be fully sync (yes, including firing createdCallback during parse), but various technical and security constraints make that impossible.
>>
>> In short, Custom Elements and Mutation Observers are servicing very different needs. Custom Elements are privileged, but limited and singular (I can only react to changes in myself and I'm the only responding party), while Mutation Observers are unprivileged, pervasive and multiple (I get to respond to anything in the document, and there are likely other parties doing work in the same place I am).
>
> The problem I have with this approach is that we'll then end up with not two but three parallel API for observing DOM mutations that each has its own delivering/dispatching mechanism and timing: mutation events, mutation observers, and custom elements.  API fragmentation like that can't be good for the platform.

Hopefully mutation events can go away. In gecko we have since August
2012 warned authors whenever they are used that they are going to be
removed. We've gotten very little feedback (none that I know of) that
this is a problem.

>> I think there's an argument to be made that Mutation Observers *should* be extended to allow for observation of trees which include DOM reachable through shadowRoots. The motivation for this would be to allow existing de-coupled concerns to operate faithfully in the presence of custom elements implemented with shadowDOM. The obvious concern here is that de-coupled code may interfere with the implementation of elements, but that's no more true with custom elements than it is today, and shadowRoot is imperatively public, it's consistent to allow MutationObservers to continue to fully observe a document.
>
> I think this would be a nice opt-in feature; component authors should be able to choose whether or not to expose its internal DOM in embedding documents.

For now Mutation Observation never crosses shadow DOM boundaries. When
we add that ability I think it needs to be explicitly opted into, and
even when explicitly opted into, it should not cross the boundary into
private shadow DOM trees.

In short, I think this is an orthogonal discussion, and should follow
the decision of the open/close debate. This is just one more aspect of
how shadow DOM nodes can be exposed and should follow the policies
that are used elsewhere.

/ Jonas
Received on Wednesday, 12 February 2014 22:34:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC