[csswg-drafts] Transforms on root SVG element

smfr has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== Transforms on root SVG element ==
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 <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)


Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/894 using your GitHub 
account

Received on Thursday, 12 January 2017 17:08:26 UTC