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

[whatwg] Problems with DOMTokenString

From: Martin Atkins <mart@degeneration.co.uk>
Date: Fri, 02 Feb 2007 18:32:05 +0000
Message-ID: <45C383A5.9070005@degeneration.co.uk>
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.
Received on Friday, 2 February 2007 10:32:05 UTC

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