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

Quote from the spec, 7.9:
  7.9
  The bounds of the new viewport are defined by the ‘x’, ‘y’, ‘width’ and
  ‘height’ attributes on the element establishing the new viewport, such as an
  ‘svg’ element. Both the new viewport coordinate system and the new user
  coordinate system have their origins at (‘x’, ‘y’), where ‘x’ and ‘y’
  represent the value of the corresponding attributes on the element
  establishing the viewport.
Doesn't the spec say that <svg x="2"> creates a new coordinate system
with its origin at (2,0), and therefore x and y do contribute, and
they have to be considered in the matrix transform?

The spec should be very clear about (a) which coordinate system the
getTransform methods refer to, and (b) after which transform
applications. Browsers understand it in different ways.


a) On any element, is it the coordinate system the element
establishes, or is it the coordinate system it uses for positioning
itself?
As of my understanding, the spec suggests that it is the coordinate
system it establishes, because of:
  4.5.23
  Returns the transformation matrix from the user coordinate system on the
  current element (after application of the ‘transform’ attribute, if any)
If it refers to the coordinate system used, there is no way of getting
any transform from/to the coordinate system created of innermost/leaf
elements.


b) Is x and y included? As quoted above, the spec only mentions
"transform" on the discussed get*() methods. Section 7.9 says that "x"
and "y" modify the origin of the user coordinate system for elements
defining a new viewport, which is the "svg" element. This would not
apply to e.g.
* g – it does not have x/y attributes at all
* rect – see argument of Tab Atkins about circle's cx/cy which would
have to be handled as well for consistency reasons

It is not clear though if the new coordinate system is defined *on*
the current element or *on* the children.
  7.9
  By establishing a new viewport, you also implicitly establish a new
  viewport coordinate system, a new user coordinate system, and,
  potentially, a new clipping path (see the definition of the ‘overflow’
  property) [missing here: ON the current element, or ON the child elements].
Section 4.5.23 (quote above) suggests that it is *on* the current
element as it clarifies that the "transform" attribute is applied to
the coordinate system on the current element.

>From a logical point of view, x and y have to be included, because it
affects the coordinate system and hereby the children. getScreenCTM
for example would not make sense if it did not consider x/y because
you would have to add those values again in order to really get the
screen coordinates of a point.


TLDR version of my conclusion:
1. Every transform attribute defines a new coordinate system ON the
current element
2. Coordinate systems ON SVG elements with "x" and "y" attributes have
their origin at (x,y), so they correspond to a transform="translate(x
y)"
3. The spec should be clarified so there is less room for interpretation :)

Simon

2014-09-14 9:04 GMT+02:00 Dirk Schulze <dschulze@adobe.com>:
>
> 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. Therefore, SVGMatrix should be the identity transform. In face, in your example, for all elements getTransformToElement would return the identity transform.
>
> Greetings,
> Dirk
>
>>
>> The full thread on Mozilla's bug tracker, including some demos, is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1064151
>>
>> Greetings,
>> Simon
>

Received on Monday, 15 September 2014 08:18:48 UTC