W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

Re: DOM3 Events: range of DOMAttrModified modifications

From: Ray Whitmer <ray@personallegal.net>
Date: Sat, 17 Dec 2005 12:33:28 -0700
Message-Id: <DD4B7103-25FF-4555-A84F-6601FE81BD1D@personallegal.net>
Cc: www-dom@w3.org
To: Bjoern Hoehrmann <derhoermi@gmx.net>

On Dec 17, 2005, at 9:44 AM, Bjoern Hoehrmann wrote:

> Hi,
>   http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/ defines
> DOMAttrModified as follows:
>   Occurs after an Attr has been modified on a node. The target node of
>   this event is the parent Element node whose Attr changed. It is
>   expected that string based replacement of an Attr value will be  
> viewed
>   as a modification of the Attr since its identity does not change.
>   Subsequently replacement of the Attr node with a different Attr node
>   is viewed as the removal of the first Attr node and the addition of
>   the second.
> It's not clear from the document what qualifies as an Attr  
> modification
> and what does not. It is not clear whether changing e.g. Attr.prefix
> would trigger the event, or more importantly, whether changing the  
> isId
> attribute through setIdAttribute et al would trigger it. Other cases
> would include e.setAttributeNS(null, 'x', e.getAttributeNS(null, 'x'))
> which would not modify the value but the .specified attribute (if  
> it had
> a defaulted value before the call).

The relevant explanation seems to be: "It is expected that string  
based replacement of an Attr value will be viewed as a modification  
of the Attr since its identity does not change".

Yes, there are some other (more unusual in my opinion) sorts of  
changes that might not be well tracked by events, such as prefix  
changes.  Prefixes are highly irrelevant to most interpretations of  
the Level 3 DOM hierarchy, because it does not affect the  
namespaceURI (which is read-only) which should establish the meaning  
of the node.  The serializer may even choose or be forced  to not  
preserve the prefix of an attribute, i.e. if if conflicts with other  
attributes on the element using the same prefix, so I wouldn't  
generally worry about a prefix of an attribute being modified.

Likewise, setting or clearing isID does not affect the meaning of the  
node, but is only a device for communicating knowledge about the  
meaning of an ID from an underlying understanding of the DTD, which  
may or may not be available.  That a node has changed the value does  
not, in my opinion, merit a mutation event, because the meaning and  
the serialization of the document has not changed at all.

I think it is just like the sentence says: changing the attribute  
value in a string-based replacement (not the prefix or id status)  
without changing the identity is an attribute modification meriting  
this event.

I think there is no mention of being able to skip the event if the  
replacement is a replacement with the current value.  The key in this  
case would not seem to be that the specified flag is affected, but  
that there was a replacement, I think.  I could imagine an  
implementation believing it could skip the event in this case if  
there was no actual modification involved, but such a call would  
perhaps involve a judgement call that might be unjustified about the  
actual use to which the mutation events are put.  I think there has  
been some clarification in similar situations in the past, but I'd  
have to go look at it (such as for the replace node call if it is  
replacing a node with itself).

You are probably safest giving the event in all cases, but that may  
not answer performance concerns, not that I really think the self- 
replacement is a common enough occurrence to worry about from a  
performance perspective, and if it is, the application can just as  
easily test and avoid it.  You could probably even get away with  
giving events in extra cases where the actual value was not replaced  
(changing the prefix), but I think relying on these events would be  
non-portable so they would seem useless.

Any more questions and I might be forced to go back and read the  
specification more thoroughly again :-)

Ray Whitmer
Received on Saturday, 17 December 2005 19:33:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC