Re: [css-transforms] Transforms on the Root SVG Element

On May 20, 2015, at 11:44 PM, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com<mailto:amelia.bellamy.royds@gmail.com>> wrote:
[...]
The question:

  *   Does the root element of a stand-alone <svg> have an "associated CSS layout box"?  If so, transformations on the root SVG should rotate/skew/scale relative to the center of the canvas.
     *   I argue yes, since borders & backgrounds (part of CSS layout) apply in all web browsers and the WG has resolved to make that part of the spec.

It is certainly an interesting question. Are we talking about SVG as root document or inline SVG here? I assume the latter.

Having a background or a border does not require a associated CSS layout box. However, it requires a definition what rectangular reference boxes mean.

That said, I don’t know how Safari treats SVG root in this case. It seems that Blink and Gecko do treat it similar to CSS layout boxes.


Current Behavior on the latest stable major browsers available on Windows (additional tests appreciated):

  *   When the transformation is specified as a style property
(see the attached svgRootTransformOrigin.svg, which uses a transform style rule to rotate the root element of an SVG):
     *   Firefox & Internet Explorer rotate around the center of the SVG element's drawing box (e.g., treat it as a CSS layout box)
     *   Chrome rotates around the top left corner of the drawing box (*not* the origin created by the SVG viewBox)
     *   In all browsers tested, translation units are calculated before viewBox scaling

Safari doesn’t support the `transform` property on outermost SVG root elements for standalone SVG documents.

The different transform origin is a result of the applied UA stylesheet as Cameron wrote and would be fixed by that.


     *
  *   When the transformation is specified as an attribute
(see svgRootTransformOriginAttribute.svg)
     *   Firefox transforms the internal content using the coordinate system created by the viewBox, but does not transform the SVG's layout box

Even though SVG 1.1 didn’t support the `transform` attribute/property on outermost SVG, it already defines that the whole “element” gets transformed (As the spec states it: including x,y, width,height attributes.).
(See last paragraph in http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute)
The behavior you see in Firefox does not seem to be correct. I clarified the text in SVG2.


     *   None of the other browsers tested currently apply any transform

That is odd in Blinks case since it supports the property. This is a bug in Blink.

     *
  *   When the transformation is specified using the svgView spec
(see svgViewTransform.html)
     *   None of the browsers transform the SVG layout box (note that the inner thin black border is from the <svg> element)
     *   Firefox applies the transformation after the viewBox
     *   Chrome and Internet Explorer apply the transformation before the viewBox

It seems like IE and Chrome are correct.

     *
  *   Things get even more complicated when you use an svgView on an element that already has a transformation.  See my previous email.

Could you link it please?

  *
  *   In other words, whatever we decide, everyone's going to have to fix their implementations somewhere.

It is pretty much apply all transforms first, then viewBox. We still need to decide:

* transform property first or the SVGView transforms first. (need to think about that..)
* Is root SVG on standalone SVG a CSS layout box or not. (It probably should and I agree with you and Cameron)

Greetings,
Dirk



What part of the SVG spec needs to be cleared up?

  *   Somewhere it should state that the SVG root element is a CSS layout box for the purposes of transformations.  Probably in the same place where we state that backgrounds, borders, and other properties apply on the root element.

  *   In the SVG view spec (linking chapter), it should state that an svgView transformation applies in the same way as a transformation on the root element.

  *   In the SVG view spec, it should clarify whether the transformation
     *   is in addition to the transformation defined in the SVG file (e.g., take whatever would normally be drawn, and transform it)
     *   OR, a replacement for it, as if it was an !important style override (all the other svgView parameters override values specified in the SVG file)

If the SVG WG agrees on the above (and decides on the last point), and the CSS transforms team doesn't have any objections, I can draft the language for the spec.

AmeliaBR

References:
[1]: http://www.w3.org/2015/05/07-svg-minutes.html#item03

[2]: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0017.html

[3]: http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers

[4]: http://dev.w3.org/csswg/css-transforms/#transform-origin-property

[5]: http://dev.w3.org/csswg/css-transforms/#transform-rendering (See note at very end of the section)
<svgViewTransformSimplified.html><svgRootTransformOrigin.svg><svgRootTransformOriginAttribute.svg><svgNoTransform.svg>