Re: [whatwg/dom] Future for unique tokens in DOMTokenList (#201)

@cdumez 
Yes, `el.classList` on setting is equivalent `el.classList.value` on setting, and DOM definition:
"Setting the value attribute must set an attribute value for the associated element using associated attribute’s local name and the given value."
I thought that in https://github.com/whatwg/dom/issues/105 you are focusing only on stringifier for `DOMTokenList, but yes, this fix https://github.com/whatwg/dom/commit/2920fc15b9e894c45ff84c5d3bb77f7513ff50e5 change `DOMSettableTokenList.value` too (but only getting, setting was change earlier, here https://github.com/whatwg/dom/commit/e48ced42e68ce540c8d7c05d43868082f9d86f11). This change was done probably because that was like stable browsers work (which implemented `DOMSettableTokenList` for some content attribute, now replaced by `DOMTokenList').

Changing stringifier for `DOMTokenList` doesn't need to enforce changing `DOMTokenList.value' . They don't need have to the same behavior, it all depends on what is more expected by the developers 
and compatible with actual content. Setting asociated attr through `DOMTokenList` to orginal passing value also can be useful.

Recently a lot of changes  were made around sets and hard to follow them, especially when browsers still operate in their own way. The current definition doesn't look bad and really, if others don't follow the new changes, it makes no sense to modify anything in DOM once again.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/201#issuecomment-208085164

Received on Sunday, 10 April 2016 22:27:22 UTC