Re: [svg2] transform on <svg>

Robert reminds me (see below) that <pattern> elements already have viewBox
in combination with transformations, through the patternTransform attribute.

On 8 December 2014 at 15:01, Robert Longson <longsonr@gmail.com> wrote:

> Firefox will replace any transform on the root element with the fragment
> identifier transform, just like it does for viewBox.
>
> I really think that fragment identifier transforms should work the same as
> setting a transform on the root SVG element and setting a transform on the
> root element should work the same way as setting a transform on an inner
> SVG element. Anything else would be confusing.
>
> Note also that patterns have always had x, y, width and height, a viewBox
> and a (pattern)Transform.
>
> Robert.
>

The specs say (
http://www.w3.org/TR/SVG11/pservers.html#PatternElementPatternTransformAttribute,
wording is currently the same in SVG2):


patternTransform = "<transform-list>"
Contains the definition of an optional additional transformation from the
pattern coordinate system onto the target coordinate system
(i.e.,'userSpaceOnUse' or 'objectBoundingBox'). This allows for things such
as skewing the pattern tiles. This additional transformation matrix is
post-multiplied to (i.e., inserted to the right of) any previously defined
transformations, including the implicit transformation necessary to convert
from object bounding box units to user space.
...
The contents of the ‘pattern’ are relative to a new coordinate system. If
there is a ‘viewBox’ attribute, then the new coordinate system is fitted
into the region defined by the ‘x’, ‘y’, ‘width’, ‘height’ and
‘patternUnits’ attributes on the ‘pattern’ element using the standard rules
for‘viewBox’ and ‘preserveAspectRatio’.
...
The ‘viewBox’ attribute introduces a supplemental transformation which is
applied on top of any transformations necessary to create a new pattern
coordinate system due to attributes ‘x’, ‘y’, ‘width’, ‘height’ and
‘patternUnits’.

None of that specifically defines whether the transform should be applied
before or after an implict transformation from viewBox, but it seems to
imply that the transformation applies first, in the definition of the tile
area into which the viewBox will be fitted.

A simple test case confirms that that's the way that browsers currently
implement it: http://fiddle.jshell.net/qydnk8ng/

(A separate issue for SVG 2 would be to edit these sections to clarify the
relationship between viewBox and patternTransform, by changing "...height
and patternUnits" to "...height, patternUnits, and patternTransform" in the
final sentence, and maybe clarifying the main attribute definition.)

For transforms on SVG elements:

I agree that consistency should the primary goal.  Consistency with pattern
supports applying transforms *before* applying the viewBox, as a distortion
of the viewport region.

Again, if this is adopted, it would mean changing the draft test
"linking-frag-01-f.svg" from the SVG1.1 2nd Edition test suite.  Other
browsers would need to change their treatment of transformations in SVG
view fragments and implement transform attributes/styles to match.

(Firefox would still need to fix how it handles transform attributes on
inline SVG, so it affects the CSS box as well as the graphic content and so
that it respects the default transform-origin for elements with CSS box
layouts.)

I like the idea that a transformation specified via a #svgView() fragment
replaces a transform attribute, but it gets a little tricky when you also
have the possibility of styles defined within the SVG setting a transform
on the root element, and maybe manipulating it based on hover states or
media queries -- where would fragment values fit in the cascade?

ABR