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

Amelia Bellamy-Royds:
>    - 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]

I thought this was just about defining the default transform-origin for
(non-outer) SVG elements, regardless of whether they are in an HTML
document.

Also I think the concept of an “initial used value” doesn’t make sense.
A used value can be defined based on the computed value of the property
plus some other conditions (other property values, perhaps what element
it’s on).  But I don’t think it’s possible to say that the used value
becomes 0 0 if the computed value came from the initial value (which is
50% 50%), unless you wanted all occurrences of 50% 50% – even explicit
ones – to be treated as 0 0 on these SVG elements.

Instead the spec should define this using a UA style sheet rule.  In
Firefox we have:

  @namespace url(http://www.w3.org/2000/svg);

  *:not(svg),
  *:not(foreignObject) > svg {
    transform-origin: 0 0;
  }

I feel like we discussed this recently, but I’m not sure whether
foreignObject should get this rule applied to it too.  Does it have an
associated CSS layout box?

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

Yes I agree.

> 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

Is this just because the other browsers don’t yet support the transform=""
attribute on <svg> elements in general?

Since the CSS Transforms spec defines transform="" as being a
presentation attribute for the ‘transform’ property, that should make
its behaviour identical to svgRootTransformOrigin.svg.

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

I’ll echo my sentiment from a telcon a couple of weeks ago and say that
I think the svgView transformation should be applied after the viewBox,
root transform property value, and the transfrom from currentScale, etc.

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

Sounds good.

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

What does in the same way mean?  Although we discussed not extending the
svgView syntax with the four other transform-related properties, would
they (e.g. transform-origin) affect the transform given in svgView
syntax?  If not, what would be the “assumed” transform-origin value –
i.e., would it be 50% 50% because we are still applying a transform to
an element that has a CSS layout box?

>    - 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)

IMO it should be additional.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 21 May 2015 06:49:25 UTC