[whatwg] classList should perhaps move from HTMLElement to Element

[Rik Cabanier]

On Wed, May 2, 2012 at 5:03 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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


There was a discussion in the SVG WG about dropping the SVGAnimatedxxx
objects and have replace them with regular values.
We would need some tricks so we can change the DOM, but make it backward
compatible at the same time.


>
>
>  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<https://bugzilla.mozilla.org/show_bug.cgi?id=741295>
>
> -Boris
>