Re: [whatwg] DOMTokenList: mutation clarification
On Mon, 10 Aug 2009, Sylvain Pasche wrote: 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? I don't think it changes the interpretation of this border case and I still think the spec implies that no attribute is added. You are correct, I misinterpreted my own text! I've added an example so that this is crystal clear. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList: mutation clarification
On Mon, Aug 10, 2009 at 1:09 AM, Ian Hicksoni...@hixie.ch wrote: I've reworded it to imply only one mutation event fires. Thanks. 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? I don't think it changes the interpretation of this border case and I still think the spec implies that no attribute is added. Maybe the ambiguity is about the definition of mutation in the when the object mutates this empty string sentence. If we have an element with no class attribute and call .remove(foo), we start the remove() algorithm with the empty string and it doesn't modify that string. So I would say that there wasn't a mutation and that no attribute should be added. One way to clarify that no attribute should be added might be (the change is between the parentheses): When the attribute is absent, then the string represented by the object is the empty string; when the object mutates this empty string (that is, the algorithm changes the underlying string to a non-empty string), the user agent must add the corresponding content attribute, with its value set to the value it would have been set to after mutating the empty string. I also assume an otherwise, do nothing at the end of that sentence. Do you think somebody could interpret this as an otherwise add an attribute set to the empty string? Sylvain
Re: [whatwg] DOMTokenList: mutation clarification
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. `._.-(,_..'--(,_..'`-.;.'
[whatwg] DOMTokenList: mutation clarification
Hi, 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. 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? Sylvain [1] http://simon.html5.org/test/html/dom/reflecting/DOMTokenList/getting/009.htm
