W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: 2.3.2. DOMTokenList

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 5 Sep 2007 19:04:39 +0000 (UTC)
To: Marek Pawłowski <marekp.w3c@gmail.com>
Cc: public-html@w3.org
Message-ID: <Pine.LNX.4.64.0709051823000.3943@dhalsim.dreamhost.com>
On Wed, 5 Sep 2007, Marek Pawłowski wrote:
>
> 1. I suggest DOMTokenList methods add() and remove() return
> DOMTokenList itself. This would allow for useful function chaining,
> f.e.:
>
>   myDiv.classList.add('toFront').toggle('maximized');

Wouldn't:

   with (myDiv.classList) {
     add('toFront');
     toggle('maximized');
   }

...be the better way to do this? In general the DOM doesn't do 
chaining-style APIs, so I'm reluctant to add it here.


> 2. Anyway, I know that this was discussed on WHATWG list but why not 
> extend className instead of adding classList? Is this producing some 
> serious compatibility problems? As I understand current spec classList 
> stringify to the same value as className.

Basically, you can't, because in JS strings are immutable. The spec used 
to be that way, but it doesn't work.


> 3. I'm not sure if it is intended but with current algorithms for adding 
> token in add() and toggle() methods when DOMTokenList object's 
> underlying string is empty it ends up with value of U+0020 SPACE + 
> token. Shouldn't there be condition that if underlying string is empty 
> then append only token? I believe that today's common way of obtaining 
> classList is via:
>
>   classArray = myDiv.classList.split(' ');
>
> With current algorithm it will lead to array with additional empty 
> elemets and could cause some compatibility problems with existing pages.

Yeah, I'll fix that eventually (I think that's been raised before).

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 5 September 2007 19:05:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:07 GMT