- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 02 May 2012 20:03:54 -0400
- To: Ian Hickson <ian@hixie.ch>
- CC: whatwg <whatwg@lists.whatwg.org>, www-svg <www-svg@w3.org>
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
Received on Thursday, 3 May 2012 00:04:28 UTC