On 13/10/11 4:50 AM, Rafael Weinstein wrote:
Hi Sean,
I find it hard to reason about cases in the abstract. None of the
examples you list seem concerning to me (i.e. I believe they can be
properly handled), but perhaps it's a failure of my imagination.
I didn't say they can't be properly handled. I said that the proposal by
itself doesn't properly handle them, and I suggested a similar but
simpler solution that also doesn't properly handle them by itself.
Another way of phrasing this deficiency is that the proposal provides a
way to signal interest in mutations in regions of a page, but doesn't
provide a way to ignore mutations within those regions. So the libs
using this API may have to provide their own mechanism for this.
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?
On Wed, Oct 12, 2011 at 4:00 AM, Sean Hogan<shogu...@westnet.com.au> wrote:
On 12/10/11 3:26 AM, Tab Atkins Jr. wrote:
On Mon, Oct 10, 2011 at 7:51 PM, Sean Hogan<shogu...@westnet.com.au>
wrote:
On 24/09/11 7:16 AM, Adam Klein wrote:
- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)
A simpler solution that is free from the faults listed in that email
would
be to have (at max) one mutation observer for the whole page context. I
guess this would be called at the end of the task or immediately before
page
reflows.
If a js lib (or multiple libs) want to provide finer grained mutation
handling then let them work out the details.
That seems unworkably restrictive. It's very easy to imagine multiple
libraries listening for different kinds of things at the same time.
Libraries would just end up re-implementing event distribution, which
is something we can avoid by doing it correctly now.
This proposal doesn't entirely avoid the issue of event distribution. There
is no equivalent of event.stopPropagation() and hence no way to prevent
mutation records being delivered to observers. The observers may have to be
written with this is in mind.
For example, what if two observers can potentially handle the same mutation
- which one should handle it?
Alternatively, some code might respond to an attribute by adding content to
the DOM. What if there are mutation listeners that could respond to that
added content? Is it desired that they ignore or handle it?
Another pattern that doesn't seem to be reliably handled is mutations within
DOM fragments that are temporarily removed from the document. That is:
- if the fragment always remains in the document then all mutations can be
monitored by observers on the document (or document.body), but
- if the fragment is removed from the document followed by mutation
observers being called, then any further mutations won't be delivered to
the observers, even when the fragment is reinserted into the document.
The exact behavior in this scenario depends on whether mutations complete
within one microtask or more than one
Sean.
