[whatwg] DOMTokenList feedback

[Jonas Sicking]

On Thu, Jul 30, 2009 at 6:38 PM, Ian Hickson<ian at hixie.ch> wrote:
> On Mon, 27 Jul 2009, Jonas Sicking wrote:
>> > In general, I try to be as conservative as possible in making changes
>> > to the DOM. Are the algorithms really as complicated as you're making
>> > out? They seem pretty trivial to me.
>>
>> At least in the gecko implementation it's significantly more complex
>> than not normalizing whitespace. The way that the implementation works
>> in gecko is:
>>
>> When a class attribute is set, (during parsing or using setAttribute)
>> we parse the classlist into a list of tokens. We additionally keep
>> around the original string in order to preserve a correct DOM
>> (actually, as an optimization, we only do this if needed).
>>
>> This token-list is then used during Selector matching and during
>> getElementsByClassName.
>>
>> So far I would expect most implementations to match this.
>>
>> It would be very nice if DOMTokenList could be implemented as simply
>> exposing this internal token list. With the recent change to not
>> remove duplicates reading operations like .length and .item(n) maps
>> directly to reading from this token list. All very nice.
>>
>> However writing operations such as .add and .remove requires operating
>> on the string rather than the internal token-list. The current spec
>> requires .remove to duplicate the tokenization process (granted, a
>> pretty simple task) and modify the string while tokenizing. It would be
>> significantly simpler if you could just modify the token-list as needed
>> and then regenerate the string from the token-list.
>
> I've left it as is for now, but if other implementors agree that it would
> be significantly better to change it to normalise whitespace each time, I
> don't feel too strongly about it.

I too am interested in feedback from other implementors.

> (We're agreed that removing would remove all duplicates, and that the
> order would be preserved, right?)

Indeed.

/ Jonas