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

On Thu, Sep 11, 2014 at 2: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 full thread on Mozilla's bug tracker, including some demos, is here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1064151

I can easily see arguments both ways.

Pro: x/y acts similarly to a translation, occurring before the
transform attribute.  Folding it in lets you really operate on the
same coordinate system as the element.  (In this case, we should
actually define it as such.)

Con: We should be consistent in our handling of x/y on all elements,
if possible.  Are you asking for the <rect x y> to be treated as a
transform as well?  You can't even get away with the "only affects
children" cop-out, since x/y on <rect> affects where it itself draws.
(And if we're treating x/y like this, we'd need to treat cx/cy that
way too.)

~TJ

Received on Friday, 12 September 2014 16:54:25 UTC