On 25/07/11 2:18 AM, Aryeh Gregor wrote:
When discussing mutation events use-cases, mostly so far people have
been talking about editors. However, I think mutation event
replacements would have a much more general appeal if they were easily
usable in certain cases with little performance impact. Specifically,
one use-case I've run into a lot is "I want to modify some class of
node soon after it gets added to the DOM, but before it's actually
painted". Examples of where this has come up for me in practice:
<snip>
What would solve all of these use-cases is a way to register a handler
that would get notified every time an element is added to the DOM that
matches a particular CSS selector, which is guaranteed to run at some
point before the element is actually painted. Thus it could be a
special type of event that runs when the event loop spins *before*
there's any opportunity to paint, or it could be semi-synchronous, or
whatever, as long as it runs before paint. Then I could easily solve
all the use-cases:
<snip>
It seems to me this dovetails pretty nicely with some of the proposed
mutation events replacement APIs. Specifically, people have been
talking about allowing filtering of events, so this use-case should be
solved easily enough if you can use CSS selectors as filters. In that
case, the perf hit from using such events should be negligible, right?
I assume you are referring to the NodeWatch proposal from Microsoft.
1st draft:
http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events
2nd draft:
http://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.28A_Microsoft_Proposal.29
I think the utility of this proposal is unnecessarily limited by the
restriction of one watcher per node.
Also, it is not clear that handlers would be called before page reflow /
repaint.
If these issues were resolved, then this feature plus some shadow DOM
capabilities would facilitate a performant JS implementation of
(something approaching) XBL2.
