[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