On 09/28/2011 07:01 PM, Adam Klein wrote:
On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettay<olli.pet...@helsinki.fi> wrote:
On 09/24/2011 12:16 AM, Adam Klein wrote:
For each observer, if a registration exists which requests the
matching mutation type and whose observed node set contains the target
node of the mutation, a MutationRecord is appended to the observer's
pending mutation queue. If multiple such registrations exist for a
given observer, a single MutationRecord is delivered having the union
of the information requested by all registrations (e.g.
attributeOldValue).
This is actually still ambiguous.
What if attributeOldValue is first set to true for document.documentElement,
and then false (implicitly or explicitly)
for document, should attribute values be reported?
Another problematic case is that if we have subtree A and B and both
are being observed by same observer but different options. Then some
node from A is moved to B. Which options should be used?
So, should we define that "union" means that 'true' values override
'false' values, and attributeFilter values are union'ed the usual way?
Yes, I think this is what I actually had in mind: true values override
false values.
Actually attributeFilter is union'ed the usual way only if it is defined
always (in all the options). If it is missing, all the
attributes should be observed.
To make API somewhat more consistent, should we change
"Subsequent calls to the same MutationObserver made with the same |target|
have the effect of resetting the options associated with the registration. "
to follow the union-ing.
If we're going to do that, I think we need to add the ability to stop
listening to a single target (rather than disconnecting from all).
But I'm not convinced we need this consistency, as I suspect the above
case (covering multiple nodes with different registrations and
different options) is quite unusual.
OK, let's keep the re-observe a target the way it is.
-Olli
- Adam
