Re: [svg2] transform on <svg>

I did not mean using fragment identifiers to set a view, I mean something
like #svgView(transform(scale(2)))

Robert.

On 8 December 2014 at 18:34, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> 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
> 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
> transformed.
>
> *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" />
>     </svg>
> </svg>
>
>
> 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.
>
>
> ~ABR
>
>