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

Is there any interest in fixing this part of the specs? Otherwise I would
sign off from the mailing list now.

Refresher: The question was if inner.getTransformToElement(root) on

  <svg id="root">
    <svg id="inner" x="1" y="0"></svg>
  </svg>

should return (0,0) or (1,0). In terms of the SVG specification, the
question is if the translation with x/y alters the “current user
space” of the inner SVG element. Browsers handle it differently, and
the specs is not clear about this point. (Further details see the
conversation history.)



2014-09-23 11:19 GMT+02:00 Simon Eugster <simon.eu@gmail.com>:

> 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.
> >
> >
> >
> >
> >
>