W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: More use-cases for mutation events replacement

From: Sean Hogan <shogun70@westnet.com.au>
Date: Tue, 26 Jul 2011 13:12:46 +1000
Message-ID: <4E2E30AE.3060007@westnet.com.au>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: W3C WebApps WG <public-webapps@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT