- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Mon, 8 Dec 2014 11:34:20 -0700
- To: Robert Longson <longsonr@gmail.com>, Erik Dahlstrom <ed@opera.com>
- Cc: www-svg <www-svg@w3.org>
- Message-ID: <CAFDDJ7z4axhTSF+31Xtia3DSaaLQeEZx_qUpCMNv5GBZ9XOO=g@mail.gmail.com>
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
Received on Monday, 8 December 2014 18:34:48 UTC