W3C home > Mailing lists > Public > www-svg@w3.org > March 2006

Re: Behaviour of SVGTransformable and it's objects

From: Jonathan Watt <jwatt@jwatt.org>
Date: Fri, 10 Mar 2006 02:34:04 +0000
Message-ID: <4410E59C.1070400@jwatt.org>
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:


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:


Received on Friday, 10 March 2006 02:34:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:07 UTC