Re: DOM Mutation Events Replacement: When to deliver mutations

On 8/09/11 8:57 AM, Travis Leithead wrote:
> When I proposed watchSelector [2], the idea was clearly to propose an option that provided semantics similar to Option 4 as described here.
> The primary benefits I sought were:
> Pros:
> * batching - allow a script to operate on the DOM's cumulative changes, vs. incremental changes.
> * filtering - provide a well-known mechanism for quickly and precisely identifying the nodes in the document that should be observed.
> * performance - fully async has the potential to very fast to implement

Hi Travis,

I like the watchSelector proposal and think it would combine well with 
the independent shadow DOM proposal to facilitate Javascript 
implementations of (something like) XBL2.

The *batching* described in the proposal seems to allow out-of-order and 
even post-relayout mutation notifications. I don't think this feature 
would be used, nor that it makes much of a performance difference 
relative to the *filtering* implicit in your proposal.

Could you give more details on why fully async would be very fast 
relative to other solutions?

> I think the filtering benefit could be extended to either Option 2 or 3.
> I prefer Option 3 because if offer a larger opportunity for batching.
>
> Cons:
> * See previously stated use case as argument against this approach
> * The approach didn't account for node "movement" within the document (reparenting of elements).

I would like to have watchSelector AND mutation events (or their 
replacement). Maybe you do too?

> * The approach (using Selectors) was deemed "too risky" because web developers can provide complex selectors that make running the mutation detection algorithm expensive for the UA.

Could you explain how this could be more expensive than what the browser 
already does with handling CSS?


regards,
Sean

Received on Friday, 9 September 2011 01:32:03 UTC