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

Small side note:

<svg id="root" xmlns="http://www.w3.org/2000/svg" width="400" height="400">
    <svg id="inner" x="200" y="200" width="200" height="200">
    </svg>
</svg>

If I add a mouse click event, I get screen coordinates. To transform
them to "inner", there is the getScreenCTM().inverse() method.
Depending on whether "x" and "y" are considered or not, there are two
ways.

Given the event's screen coordinates are put into an SVGPoint p,
A) "x" and "y" contribute to "inner"s user coordindate system. Then I
can use q = p.matrixTransform( "inner".getScreenCTM().inverse() ).
B) don't contribute: Then I have to add an element "elem" to "inner"
(or take one, but take care it is a graphics element and not e.g. a
comment, and that it does not have a "transform" attribute which would
again modify the user coordinate system according to the spec), and
then use "elem".getScreenCTM().inverse(), and then remove "elem" again
in case I created it for this calculation.

B is a bit cumbersome for this situation where I am just interested in
the coordinates and not changing an element's position. For that
latter case, it is straigt-forward, see Robert's comment here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1064151#c27 , and this
version makes sense too.

But please let's let's clarify the specs.

thanks,
Simon

2014-09-15 13:59 GMT+02:00 Jonathan Watt <jwatt@jwatt.org>:
> 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 Tuesday, 23 September 2014 09:20:10 UTC