Re: Mutation Observers: a replacement for DOM Mutation Events

On 10/13/2011 11:32 AM, Sean Hogan wrote:
> 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
If that is the case, it is implementation problem.
And the the API isn't *that* complex to implement. It has some 
complexity, especially, I could imagine, if the browser engine doesn't
have its internal mutation observing APIs.
But that is all implementation details.

Also, I'd rather add some complexity to browser implementations than to
each web page using the API.


> - it is easy to imagine that the preliminary analysis has missed
> problems, and
If you find any such problems, please tell us :)
It would be better to improve the API sooner than later.


> - it still doesn't allow different mutation event listeners to safely
> ignore the possibility of each-other.
Depending on how to interpret this, the API does exactly that.
a MutationObserver doesn't know, nor is handled differently, if there
are other MutationObservers. The old mutation event listeners affect
to each others and some listeners may not be called if
a listener happens to call stopPropagation(). And since you can't know 
where all document tree has mutation event listeners, and in which 
order, you don't actually always know what all effects calling 
stopPropagation() /   stopImmediatePropagation() has.


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

Yeah, hopefully real soon.



-Olli


>
> Sean
>

Received on Thursday, 13 October 2011 10:25:52 UTC