Re: Extending Mutation Observers to address use cases of

On Feb 12, 2014, at 2:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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 foot gun.

Right.  This is why I’d like to know exactly why end-of-microtask synchronicity isn’t sufficient for custom elements.

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

That is a good point.  There is a clear disadvantage in the case of multiple observers observing the same node.

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

But why is it okay to add semi-synchronous callbacks to custom elements then?

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

I agree. This should be discussed separately.

- R. Niwa

Received on Wednesday, 12 February 2014 22:56:30 UTC