W3C home > Mailing lists > Public > www-svg@w3.org > December 2014

Re: [svg2] transform on <svg>

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Mon, 8 Dec 2014 11:34:20 -0700
Message-ID: <CAFDDJ7z4axhTSF+31Xtia3DSaaLQeEZx_qUpCMNv5GBZ9XOO=g@mail.gmail.com>
To: Robert Longson <longsonr@gmail.com>, Erik Dahlstrom <ed@opera.com>
Cc: www-svg <www-svg@w3.org>
For both outer and nested <svg> elements, it seems simplest to apply the
transform to the viewport box -- for a top-level SVG in HTML5, that would
be the CSS content box, for nested SVGs it would be the box defined by
x,y,width, and height.

For transforms on root-level <svg> elements (i.e., in a stand-alone SVG
file), this would be consistent with the CSS Transform spec's advice on
handling root element transforms.  See
http://dev.w3.org/csswg/css-transforms/#transform-rendering, particularly
the note at the end of that section.

For dealing with viewBox, etc., there shouldn't need to be explicit rules,
but there will probably need to be some extra test cases to ensure the
existing rules are followed logically.

The transform on the parent element doesn't change the "official"
dimensions of the viewport, it just changes how those units are mapped to
the screen.  preserveAspectRatio dimensions would be calculated according
to the official dimensions, so SVG content might still be distorted even
with preserveAspectRatio other than none.  This is completely consistent
with the way it is currently handled if an SVG is nested inside a <g> with
a transform attribute.

All of this would be separate from setting a view via fragment identifiers;
that view over-rides the default viewBox, it doesn't change the view*port*.

The only aspect that would be different between nested SVGs and top-level
SVGs is the default value for transform-origin, consistent with the spec
definition that emphasizes whether or not a CSS layout box exists: "The
initial used value for SVG elements without associated CSS layout box is 0

*Comparing current implementations*

*For top-level SVGs:*
Erik's test case: http://jsfiddle.net/6pnnkoz3/5/

The Firefox (33 on Windows) implementation is currently applying the
transform attributes to the content but not to the element itself; based on
the rule above they should be applied using the exact same rules as the
transform style.  Maybe Robert could follow that up in Firefox Bugzilla?

As far as I know, other browsers currently ignore transform attributes on
<svg>, so it's just a matter of clarifying the rules for them.  Browsers
I've tested (FF33, Chrome 39, Opera 26, IE11) all behave consistently when
the transform is specified as a CSS style: the entire element is

*For nested SVGs:*
See test case: http://jsfiddle.net/fr6gcqgu/1/

<svg width="400px" height="400px">
    <circle cx="50%" cy="50%" r="25%" fill="blue" />
    <svg transform="scale(2,1)" viewBox="0 0 20 20"
         x="0" y="0" width="50%" height="100%">
        <circle cx="10" cy="10" r="10" fill="fuchsia" />

Firefox scales x,y, width and height and applies the viewBox as described
above, for both transform attribute and transform style.  The viewport for
the nested SVG gets stretched to fill the entire parent, but as far as the
content is concerned it is positioned within a viewport that is half as
wide as it is tall, and so the content is vertically centered first, and
then distorted by the non-uniform scale second.

Chrome, Opera, and IE currently ignore the transform on the nested SVG,
regardless of how it is defined.

Received on Monday, 8 December 2014 18:34:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:58 UTC