- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Mon, 27 Mar 2006 17:08:36 +0200
- To: www-dom@w3.org
Hi, I'm not sure, but I think that the full operation should always be performed, since either the user could have retrieved an instance of the removed attribute node before calling 'removeAttribute' or 'removeAttributeNS', or such an instance would be returned by 'removeAttributeNode'. So, if removing an Attr with the default values (specified=false) turned into a nop, any modify to the previous gained instance would lead to unwanted side-effects. However, such an event could be rare in practice, because that instance should be directly not usable, being stated that "The DOM user must explicitly clone Attr nodes to re-use them in other elements", but yet possible (i.e. by mistake the removed Attr value is modified after removing), so the DOM need to implement always a full removing/regeneration in order to avoid such problems. Anyway, I think tha some clarification on the implementation side could be useful. Particularly I refer to the 'ownerElement' property of the Attr node, which is 'readonly' for the user but not for the implementation (of the element object): infact, for a newly created Attr, or a cloned one, it is set to null and so the attribute may be set for an element, but after setting the Attr is owned by an element and its 'ownerElement' property is set, so any other attempt to set it for another element would rise an 'INUSE_ATTRIBUTE_ERR'; but a removed Attr node (i.e. the one returned by 'removeAttributeNode') is not currently a used one, so the implementation (or an implementation) could cancel any relation between the attribute node and its previous owner (that is the 'ownerElement' is turned back to null), so the attribute whould become reusable in other elements without cloning, by just setting a proper value and attaching it to the wanted element. I think this should be clarified, to avoid different implementation and different behaviours for the same document manipulation through DOM (i.e. such a manipulation could appear correct with an implementation while leading to an error with another - but I'm not acquainted with such situations as real, I just think they're possible). Regards. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Prestiti e Finanziamenti con un semplice click, scopri subito se sei finanziabile cliccando qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2910&d=27-3
Received on Monday, 27 March 2006 15:09:01 UTC