On Feb 12, 2014, at 11:23 AM, Rafael Weinstein <rafa...@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
