- 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>
On Thu, 03 May 2012 02:31:40 +0200, Cameron McCormack <cam@mcc.id.au> wrote: > 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