W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] DOMTokenList: mutation clarification

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 9 Aug 2009 23:09:16 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0908092308290.6420@hixie.dreamhostps.com>
On Thu, 9 Jul 2009, Sylvain Pasche wrote:
> 
> 1) in http://www.whatwg.org/specs/web-apps/current-work/#common-dom-interfaces
> 
> "When the attribute is absent, then the string represented by the object is
> the empty string; when the object mutates this empty string, the user agent
> must first add the corresponding content attribute, and then mutate that
> attribute instead"
> 
> Does it mean it should fire two DOMAttrModified events, one with the empty
> string addition, and the other with the attribute mutation?
> 
> I think it should simply fire only one mutation event in that case as in 
> all other cases (should be simpler and more efficient, although that 
> case shouldn't happen very often). I don't see a good reason to fire one 
> with the empty string.

I've reworded it to imply only one mutation event fires.


> 2) (using the class attribute for the discussion) What should happen when you
> do a remove("foo") on an element which has no class attribute?
> 
> My understanding is that it shouldn't add a class attribute with an empty
> string. That's because the remove() algorithm starts with an empty string and
> doesn't change it, so the " when the object mutates this empty string, " case
> shouldn't be true (and thus no attribute modification should happen).
> 
> However Simon's testcase [1] doesn't agree with this, and adds an empty
> string. So maybe it's worth clarifying this situation?

I think that the spec now implies that you set the attribute to the empty 
string. Do you agree?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 9 August 2009 16:09:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:15 UTC