# Re: Mutation Observers: a replacement for DOM Mutation Events

From: Sean Hogan <shogun70@westnet.com.au>
Date: Thu, 13 Oct 2011 20:52:18 +1100
Message-ID: <4E96B4D2.6090401@westnet.com.au>
To: Ryosuke Niwa <rniwa@webkit.org>
CC: Olli@pettay.fi, Olli Pettay <Olli.Pettay@helsinki.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adam Klein <adamk@chromium.org>, public-webapps@w3.org, Ojan Vafai <ojan@chromium.org>, rafaelw@chromium.org, rniwa@chromium.org, Jonas Sicking <jonas@sicking.cc>, annevk@opera.com, arv@chromium.org
On 13/10/11 7:58 PM, Ryosuke Niwa wrote:
>
> On Thu, Oct 13, 2011 at 1:32 AM, Sean Hogan <shogun70@westnet.com.au
> <mailto: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.

For that use case I think you would be happy with my proposal which
doesn't implement any filtering of mutation events at all.

By the way, I'm not arguing that the mutation observers proposal should
provide a mechanism for hiding some mutations. I'm arguing that whatever
solution is provided (even a complex one) still won't make mutation
handling straight-forward... so why not just provide the simplest
solution and let the js libs sort out the details.

Sean

Received on Thursday, 13 October 2011 09:52:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:45 UTC