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
