Re: getTransformToElement: Include nested SVG's x/y attributes?

On 14/09/2014 08:04, Dirk Schulze wrote:
>
> On Sep 11, 2014, at 11:49 AM, Simon Eugster <simon.eu@gmail.com> wrote:
>
>> Dear list,
>>
>> we are currently discussing coordinate systems of getTransformToElement and co. since Firefox implements them in a different way as the other browsers do.
>>
>> The basic question is, in this example,
>>    <svg id="root">
>>      <svg id="inner" x="1" y="0"><rect id="r" x="1" y="0"/></svg>
>>    </svg>
>>
>> what is the user coordinate system on the current element supposed to be? Should inner.getTransformToElement(root) return an identity matrix, because there is no 'transform' attribute on "inner", or should it return a translation matrix by (1,0) because, according to section 7.9, "inner"s user coordinate system has its origin there? Or, again (0,0) because the new user coordinate system only affects the children of  "inner" like "r”?
>
> The spec says that getTransformToElement returns the transformations from one coordinate space to another. In you case, x and y do not contribute to modifications to the coordinate space.

I don't agree with this. If you want to get the transform from an SVG element to 
some arbitrary ancestor then if you don't take account of the x/y translations 
on any intermediary <svg> elements the transform returned would be nonsense. The 
x/y attributes absolutely contribute translations to the resulting transforms.

Please read comment 10 (lengthy, sorry) on:

https://bugzilla.mozilla.org/show_bug.cgi?id=1064151#c10

to get a deeper understanding of how I think about this topic, and why I think 
the spec text is broken.

Regards,
Jonathan

> Therefore, SVGMatrix should be the identity transform. In face, in your example, for all elements getTransformToElement would return the identity transform.

Received on Monday, 15 September 2014 11:59:48 UTC