Re: Extending Mutation Observers to address use cases of

On Feb 12, 2014, at 11:23 AM, Rafael Weinstein <rafaelw@google.com> wrote:

> I pushed the Web Components folks about exactly this issue (why aren't these callbacks just MutationObservers?) early last year. They convinced me (and I remain convinced) that these signals should be Custom Element callbacks and not Mutation Observer records

I’m not arguing that custom elements should use mutation observers or that we should replace custom elements with mutation observers.

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

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

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

- R. Niwa

Received on Wednesday, 12 February 2014 22:09:21 UTC