W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

ACTION-24: Attribute mutation events

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 19 Mar 2006 18:18:56 -0800
Message-ID: <441E1110.9090407@sicking.cc>
To: Web APIs WG <public-webapi@w3.org>

I have an action to check what various mutation events mozilla sends out 
when various properties are changed on an attribute.

When changing the prefix of an attribute, we currently unset the 
attribute and then reset it with a different prefix. Both the removing 
and setting will send out a mutation event. However, I'm not very happy 
with this behaviour and I don't think this is what the spec should 
replicate (and I plan to fix this in future versions of moz).
What would make most sense is to just send out a single event when the 
old and the new value is the same, or not send out an event at all. I 
don't have a strong preference.

Mozilla does not support the .specified property and so we don't treat 
attributes without .specified set as anything special at all. Thus we do 
not send out a mutation event if you set an already specified attribute 
to the same value. If you set it to a new value we will of course send 
out an event.

Again, I don't have a real preference either way on this one.


When it comes to DOMNodeInserted/DOMNodeRemoved we don't send any events 
at all for attribute changes. Neither from the attribute or from its 
contained textnode. This sort of makes sense since the parent chain is 
broken at the attribute. I.e. the owner element is not a parent of the 
attribute.

It could be argued that an event should be dispatched to the 
attributenode itself, its contained textnode, but not any parents. But 
we do not currently do that. I don't think that sending those events for 
the attribute itself is useful, the DOMAttrModified event covers those 
usecases.

/ Jonas
Received on Monday, 20 March 2006 02:18:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT