[whatwg] Problems with DOMTokenString

Martin Atkins mart at degeneration.co.uk
Fri Feb 2 10:32:05 PST 2007


Maciej Stachowiak wrote:
> 
> Alternative #2: leave the className an ordinary string, but add a new 
> readonly DOMClassList classList property with something like the 
> following interface:
> 
> interface DOMClassList {
>     void add(DOMString newClass);
>     void remove(DOMString removeClass);
>     bool has(DOMString possibleClass);
> }
> 
> 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. Because the classList property would be 
> readonly, there would be no question of whether two elements ever share 
> a DOMClassList.
> 

Extending the DOMElement interface with a new, read-only property does 
seem better to me than overloading the existing className property. I 
like this approach, but I don't like the name DOMClassList.

If you leave it called DOMTokenString (or DOMTokenList, if you like) 
then it can also be used for other strings of space-separated tokens:

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.




More information about the whatwg mailing list