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