W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Mutation events replacement

From: Robin Berjon <robin@berjon.com>
Date: Fri, 5 Jun 2009 10:57:10 +0200
Cc: Webapps WG <public-webapps@w3.org>
Message-Id: <03D99CC8-0F8A-42BA-A49D-BE916FBAEA9A@berjon.com>
To: Jonas Sicking <jonas@sicking.cc>
On Jun 4, 2009, at 21:43 , Jonas Sicking wrote:
>> That's annoying. I'm guessing that creating an Attr node just for  
>> this
>> purpose is overhead we can live without given that they're never  
>> used, but
>> it would be cheap (and dead useful) to include at least the  
>> attribute's name
>> (ns/ln pair).
>
> Yeah, I definitely don't want to fore Attr nodes to be created just  
> for this.
>
> The reason for not supplying the ns/ln pair is that this way we can
> fire the callback just once even if multiple attributes were changed
> during a "DOM operation".

I think that this is a sweep-under-the-rug optimisation. For certain  
the dispatching will be faster, but the receiving end will have to  
iterate (and memorise) all attributes each time one is changed. Why  
not simply provide a list of ns/ln pairs? Presumably the  
implementation knows that at little extra cost.

> It's called with myNode. I actually got this wrong in the algorithm in
> my initial proposal. Here is a fixed version:

Ok, cool with me.

>> I don't feel strongly about it  but it seems that every time we do
>> something that's generic to nodes people come back and ask for an  
>> elements
>> only variant, because that's what they actually use.
>
> The only advantage I can see with this is that listeners that that
> only care about the element tree, would avoid getting notified when
> only non-element nodes were added or removed. The code in the listener
> would be exactly the same. So it's strictly a performance
> optimization.
>
> On the flip side, for something like the innerHTML setter, the UA will
> have to keep track of if the childlist used to contain any elements,
> and then check if the new childlist contains any element. I'm not
> convinced that this is worth it simply for a performance optimization.
> At least not in the initial revision of this API.

Well if you care only about elements changing you might have to walk  
the subtree to check that it was something else changing. But I don't  
have a strong use case and I'm happy to start with something simpler  
and toss in an element variant later if people scream.

>>> Ah, yeah, we could fire it for changes to the target too.
>>
>> Well, if you're firing on PIs it could be useful :)
>
> Actually, target is readonly.

Duh!

>> Precisely because they're rare, I'm worried about bugs when all of  
>> a sudden
>> they're triggered. I think that there's a distinction (in authors'  
>> minds)
>> between "content"  which includes text  and "the other stuff"   
>> like PIs
>> and comments. I think we should mirror that understanding, as it's  
>> rather
>> sensible. It'd be a shame if 99.99% of code had to start with if
>> (node.nodeType == PROCESSING_INSTRUCTION_NODE || node.nodeType ==
>> COMMENT_NODE) return; and half of it forgot to.
>
> Note that the mutation event DOMCharacterDataModified fires on comment
> nodes too. Has it been a problem there?

I always thought that was a bug :)

> The only way I can think of people using either mutation the mutation
> event, or this new API, is that once you get notified, you find the
> node you are interested in, and then get that nodes .textContent. This
> will work fine even the node being changed was a comment or PI.

I could live with a note in the specification saying that authors  
should use .textContent as indeed it is the right protective thing to  
do.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Friday, 5 June 2009 08:57:46 GMT

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