http://www.w3.org/mid/CAFDDJ7xQp+j2c+18zkRyPWPtnuk+dbVA6Dc_L7ACr-tptAGicA@mail.gmail.com

A couple weeks back [1], I promised to come up with a summary of current
behavior of transformations applied to the root element of an SVG. I've
previously sent some notes on this subject with respect to the svgView spec
[2], but we really need to narrow down the basic behavior first!

Background:

• In SVG 1.1, you cannot transform an element, so there was no
  clear description of how it should behave.

• In SVG 1.1, you can specify a transformation to apply to the SVG when
  you embed it, using an svgView target fragment. However, the text was
  rather vague (it "has the same meaning as the corresponding attribute has
  on a <g> element", without addressing the differences between <svg> and
  <g>). [3]

  • The result: cross-browser inconsistencies about whether or not
    transformations apply before or after viewBox scaling!

  • CSS transforms allows transformations on everything! However, CSS
    doesn't have a coordinate system like SVG, so they introduced
    transform-origin and set the default for non-SVG content to be the center
    of the element. SVG content would by default still use the coordinate
    system origin.

• But this was weird for inline SVG in HTML, since it behaved
  differently from all the rest of HTML. So, they came up with a more
  specific language:
  "The initial used value for SVG elements without associated CSS layout
  box is 0 0." [4]

• CSS transforms also gives more general guidance on how transformations
  on the root element should work. E.g., the canvas as a whole is
  transformed inside the viewport made by the browser window or frame. The
  canvas is infinite, and any parts that move into view because of the
  transformation should be painted. [5]

The question:

• Does the root element of a stand-alone 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.

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

  • 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

  • None of the other browsers tested currently apply any transform

  • 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

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

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

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)