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
