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

[whatwg] DOMTokenList feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 7 Aug 2009 10:24:22 -0700
Message-ID: <63df84f0908071024qf633f72qae0a07fbe09ef6a1@mail.gmail.com>
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
Received on Friday, 7 August 2009 10:24:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:51 UTC