Re: Mutation Observers: a replacement for DOM Mutation Events

On Wed, Oct 12, 2011 at 7:51 PM, Sean Hogan <shogun70@westnet.com.au> wrote:
>
> It is different to event listeners. The following
>
>    document.body.**addEventListener("**DOMAttrModified", handler, false);
>    document.getElementById("**target").addEventListener("**DOMAttrModified",
> preferred_handler, false);
>

What prevents scripts from then doing
document.getElementById("**target").addEventListener("**DOMAttrModified",
handler, false);
?

allows preferred_handler to prevent handler receiving the event.


The problem with allowing some event observer to prevent other observers to
receive certain mutation events is that we'll then lose any
integrity guarantee once we do that. e.g. when an observer is called with
some list of mutations, you wouldn't know whether the current DOM state is
the result of those mutations or there had been some other mutations.

Without this guarantee, you can't unwind mutation lists to restore the
original DOM state for example, and it makes mutation observation useless in
some use cases.

As such, I'll be strongly opposed to allow such a prevention mechanism.

On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan <shogun70@westnet.com.au> wrote:
>
> Another way of phrasing this deficiency is that the proposal provides a way
> to signal interest in mutations in regions of a page, but doesn't provide a
> way to ignore mutations within those regions. So the libs using this API may
> have to provide their own mechanism for this.


Right, and I'd argue that we should NOT provide such a mechanism.

On Thu, Oct 13, 2011 at 1:32 AM, Sean Hogan <shogun70@westnet.com.au> wrote:
>
> Why do you assume that all other mutation observers should ignore such
> changes? If there's a library that's automatically syncing the document with
> a server, then such an observer certainly needs to know any mutations that
> happen in the document.
>
> - Ryosuke
>
>
> In the case of MathJax, the HTML rendering for math is generated in the
> browser. It is only the LaTeX that you would want synced on the server.
>

No, my use case addresses the case where you want to mirror the exact DOM
state (except event handlers and script elements) elsewhere. And for that to
work, I need to be able to see whatever MathJax is generating, NOT the LaTeX
code.


> - it still doesn't allow different mutation event listeners to safely
> ignore the possibility of each-other.
>

I repeat myself again that we shouldn't allow mutation observers to do this.

- Ryosuke