- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 7 Aug 2009 10:24:22 -0700
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