On 13/10/11 2:33 PM, Ryosuke Niwa wrote:
On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan <shogu...@westnet.com.au
<mailto:shogu...@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