W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2007

[whatwg] Problems with DOMTokenString

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 12 Feb 2007 07:41:56 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0702120654280.4112@dhalsim.dreamhost.com>
On Fri, 2 Feb 2007, Maciej Stachowiak wrote:
> 
> I looked into DOMTokenString with keen interest, because I believe an 
> API for manipulating individual classes of an HTML element is 
> increasingly important as we see more dynamic sites that use CSS 
> styling. However, I think the design for this is not suitable as-is.

Fixed.


> Alternative #2: leave the className an ordinary string, but add a new 
> readonly DOMClassList classList property with something like the 
> following interface: [...]

I've done this. (Calling it DOMTokenList, since it applies to more than 
just classes.)


> If you add DOMString index(unsigned i) and unsigned length, you would 
> also have the ability to enumerate the classes easily, which the API as 
> currently specced lacks.

Do you think we should add this?


> In both of these alternatives, the DataGrid methods would be changed to 
> return a string instead of taking and modifing an existing 
> DOMTokenString. It is in any case highly unusual in DOM APIs for getters 
> to mutate a provided "out" object rather than to return a value. Also 
> the spec does not appear to provide a way to make a brand new empty 
> DOMTokenString, so these methods would otherwise only be useful for 
> altering the class of existing elements based on the classes of some 
> other elements, which seems unuseful.

These methods are callbacks into author code, the UA provides the 
DOMTokenList objects. It seems easier to support .add() on that object 
than accept a string back (it also makes it possible to avoid having to 
split the string on the receiving end).


On Fri, 2 Feb 2007, Martin Atkins wrote:
> 
> If you leave it called DOMTokenString (or DOMTokenList, if you like) 
> then it can also be used for other strings of space-separated tokens:

Agreed.


> interface HTMLLinkElement : HTMLElement {
>     // ... all of the existing stuff ...
> 
>     readonly DOMTokenList relList;
>     readonly DOMTokenList revList;
>     readonly DOMTokenList mediaList;
> 
> }
> 
> Admittedly these are much less likely to be toggled at runtime in the 
> browser than the class, but it may be useful for scripts that search the 
> document for anchors with particular relationships, for example.

mediaList is complicated, but will get its own accessor in due course. The 
rev attribute is gone.

Adding this for 'rel' seems to make sense though. Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 11 February 2007 23:41:56 UTC

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