Re: Mutation Observers: a replacement for DOM Mutation Events

On 13/10/11 2:33 PM, Ryosuke Niwa wrote:
> On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan <shogun70@westnet.com.au 
> <mailto:shogun70@westnet.com.au>> wrote:
>
>         Maybe you can provide concrete examples (i.e. with code snippets,
>         actual instances of use cases, etc...)
>
>
>     Actually, it is the proponents of changing the status-quo and of
>     the more complex solution who bear more responsibility for
>     providing these. But if it helps, here's a specific example:
>
>     MathJax (http://mathjax.org) is a js lib for rendering math in
>     web-pages. One feature it provides is converting LaTeX into
>     (typically) a HTML representation of the math. It is desirable for
>     the LaTeX source to remain available in the document, and MathJax
>     stores it as the content of a <script type="math/tex"> element.
>     MathJax provides an API for changing the LaTeX source and thus the
>     rendered output.
>
>     It might be desirable if MathJax could update the rendering
>     automatically in response to changes in the script content.
>     Mutation events would be necessary for this. But what is the
>     appropriate way to signal to other consumers of mutation events
>     that the math rendering changes are to be ignored?
>
>
> 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.

However, my main concern (which I probably haven't emphasized 
sufficiently) is that the current proposal is more complex than 
absolutely necessary. Therefore
- it will be complex to implement
- it is easy to imagine that the preliminary analysis has missed 
problems, and
- it still doesn't allow different mutation event listeners to safely 
ignore the possibility of each-other.

My concerns may be unreasonable. Given there is an implementation just 
around the corner, we'll soon have a better idea, rather than just 
speculating.

Sean