Re: [whatwg/dom] [discussion] Async nature of MutationObserver can cause room for error? (#399)

>We used to have that and mutation observers are the replacement as it caused all kinds of problems.

I suppose you're talking about [DOM mutation events](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events)?

If a feature like `childConnectedCallback`/`childDisconnectedCallback` triggers such methods in the same turn as `connectedCallback`/`disconnectedCallback` (respectively) of the child being connected **_only when those methods are defined_**, would that solve problems?

>From the discussion that is linked in the MDN page, the DOM mutation event problems

```
(1) Verbose (fire too often)
(2) Slow (because of event propagation -- and because they prevent certain UA run-time optimizations)
(3) "Crashy" (have been the source of many crashers for UAs because script can tear up the world in any way it wishes while a DOM operation is underway).
```

could they be solved with the callbacks, as in

```
(1) the callback methods only fire when they are defined
(2) no event propagation, they only fire on a parent custom element
(3) callbacks are called synchronously at the end of DOM operations.
```

The limitation of these new callbacks would be that they only exist on custom elements, so there's no way to arbitrarily watch some other node (f.e. a `div` element), and for that we can still use `MutationObserver`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/399#issuecomment-273006424