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

Re: [whatwg] classList should perhaps move from HTMLElement to Element

From: Erik Dahlstrom <ed@opera.com>
Date: Fri, 04 May 2012 10:17:38 +0200
To: "Rik Cabanier" <cabanier@gmail.com>, "Cameron McCormack" <cam@mcc.id.au>
Cc: "Boris Zbarsky" <bzbarsky@mit.edu>, whatwg <whatwg@lists.whatwg.org>, www-svg <www-svg@w3.org>, "Ian Hickson" <ian@hixie.ch>
Message-ID: <op.wdrynojzgeuyw5@localhost.localdomain>
On Thu, 03 May 2012 02:31:40 +0200, Cameron McCormack <cam@mcc.id.au>  

> Rik Cabanier:
>> 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.
> We have discussed this a few times, and I would desparately love for it
> to work, but I am unconvinced it will.  I can an imagine an author
> writing code like:
>    if (!elt.className) ...
> to test if a class has been set.  Even if we made the
> SVGElement.className SVGAnimatedString object one that stringifies to
> the class, add a [PutForwards] on to it so that assigning a string
> works, it would still break the above code, since the ! operator always
> returns false for an object.

I don't think the use of animated 'class' attributes in svg is all that  
common, and I'd favor an approach that'd makes .className in svg a bit  
more like the html .className, perhaps in the way Cameron is suggesting.

On the topic of which interface the .classList property should be in,  
Element seems better than HTMLElement.

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 4 May 2012 08:18:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:34 UTC