Re: More use-cases for mutation events replacement

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.

Received on Tuesday, 26 July 2011 03:17:38 UTC