[whatwg] classList should perhaps move from HTMLElement to Element

[Boris Zbarsky]

On 5/2/12 6:09 PM, Ian Hickson wrote:
> On Fri, 19 Nov 2010, Boris Zbarsky wrote:
>>
>> Given that SVG also has classes, it would make some sense to move
>> classList from HTMLElement to Element.  That way SVG, and any other
>> languages that define classes (XUL comes to mind, actually) can benefit
>> from it as well.
>>
>> Note that Gecko's current classList implementation lives on Element.
>
> How do you handle the difference between SVG and HTML's className?

Right now in Gecko it's on HTMLElement (and XULElement), with a 
domstring return value and on SVGStylable with a SVGAnimatedString 
return value.

Longer term we could put it on Element and just have SVG shadow it, of 
course.

I would love being able to drop the SVG-specific className, but I bet 
there's content

> I think it would be confusing to have classList work the same on both but not
> className.

Why?  It doesn't seem to be any more confusing than the fact that 
className is present on both and just acts totally differently to start 
with...

> For the spec's purposes my plan is to follow whatever implementations
> converge on. Currently WebKit does what the HTML/SVG specs say (.className
> is a string in HTML, an object in SVG, and .classList is HTML-specific),
> Gecko does a mixture of DOM Core and HTML/SVG say (.className is a string
> in HTML, an object in SVG, and .classList is on both but returns null in
> unknown namespaces)

Thos last might be changing: see 
https://bugzilla.mozilla.org/show_bug.cgi?id=741295

-Boris