[whatwg] DOMTokenList: mutation clarification

Ian Hickson ian at hixie.ch
Sun Aug 9 16:09:16 PDT 2009

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.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list