W3C home > Mailing lists > Public > www-svg@w3.org > May 2012

Re: classList should perhaps move from HTMLElement to Element

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 2 May 2012 15:48:34 -0700
To: Ian Hickson <ian@hixie.ch>
CC: Boris Zbarsky <bzbarsky@MIT.EDU>, Chris Lilley <chris@w3.org>, Cameron McCormack <cam@mcc.id.au>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "Tab Atkins Jr." <jackalmage@gmail.com>, whatwg <whatwg@lists.whatwg.org>, www-svg <www-svg@w3.org>
Message-ID: <7DBA148C-78DE-4867-93B8-CE6A8DB6B609@adobe.com>

On May 2, 2012, at 3: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? I think 
> it would be confusing to have classList work the same on both but not 
> className.
> 
> (Currently, DOM Core and HTML both define classList; the former on Element 
> and the latter on HTMLElement, because Anne and I disagree on what should 
> happen here.)
> 
> 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), and Opera does a different mixture (.className is a 
> string in HTML, an object in SVG, and .classList is on SVG and HTML nodes 
> but not on nodes from unknown namespaces). (Didn't have other browsers 
> available to test on this machine.)
It is an object to support SVG animations on className. It is of type SVGAnimatedString. To support classList the same way we would need an object SVGAnimatedStringList, what we don't have at the moment. I don't think that their will be plans to support it in the future.

Nevertheless, we had a lot of bug reports where web developers want to use functionality form HTML in SVG as well. Therefore I would like SVG and HTML to be consistent here. I don't think that moving classList to Element would break backwards compatibility. So I think it should be in Element since it indeed can be a win for all markup languages.

Dirk

> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 
Received on Wednesday, 2 May 2012 22:49:33 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:51 GMT