- From: Jonathan Watt <jwatt@jwatt.org>
- Date: Fri, 10 Mar 2006 02:34:04 +0000
- To: www-svg@w3.org
Jonathan Watt wrote: > > Dear SVG WG, > > While thinking through the refactoring of Mozilla's SVG implementation > we were wondering what should happen to the DOM objects under > SVGTransformable's 'transform' attribute when the SVG element's XML > 'transform' attribute is changed using setAttributeNS. Should the > objects be replaced with new objects? Or should any of the objects be > maintained and, if so, which? > > I believe it makes most sense to maintain the SVGAnimatedTransformList > and SVGTransformList objects, but to create new SVGTransform objects. > I've written a test to see how current implementations behave, and those > that implement SVGTransformable and that I have access to (Moz, Batik, > Opera 9 build 8246) seem to agree. You can find the test at: > > http://jwatt.org/svg/tests/transform-dom.svg > > Perhaps you could add it to the SVG test suite and spec out this > behavior if you agree with it? I thought I'd test a few more attributes. For attributes like 'x' and 'viewBox' where it doesn't make sense to create new objects, implementations seem to agree (they don't create them). See: http://jwatt.org/svg/tests/x-dom.svg http://jwatt.org/svg/tests/viewBox-dom.svg For another attribute where it makes sense to create new objects - 'd' on <path> - implementations don't quite currently agree. Batik and Opera 9 build 8246 seem to consistently create new objects. Mozilla on the other hand will only create new objects if the attribute value being set is different to the attribute's current value. We consider this to be a bug though. It would be simpler for the spec to just say that the objects get recreated whenever the attribute is set. (Rather than special casing and requiring a string comparison for the rare case that the attribute string is the same.) See: http://jwatt.org/svg/tests/d-dom.svg Regards, Jonathan
Received on Friday, 10 March 2006 02:34:09 UTC