- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 19 Mar 2006 18:18:56 -0800
- 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 UTC