[css-transforms] Transforms on the Root SVG Element

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


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)