Re: svgView transform behaviour (was: Re: [svg2] transform on <svg>)

(comments inline)

On 27 February 2015 at 05:15, Erik Dahlström <ed@opera.com> wrote:
>
> Should #svgView(transform(none)) mean that the transform set on the root
> <svg> element is ignored?
>

Not as we resolved it yesterday -- if transform is in *addition* to the
root transform, then this would be a no-op.

If we treated transformations like other svgView parameters -- so they
*replace* the value on the root element -- then it would be an override.


> If one wants to use more than one transform, say to scale and translate,
> should that be possible to do using svgView? The order of application
> would then need to be defined.
>

You would do it just the same as you would for a transform attribute, as a
list of transformation functions.  Just with more parentheses:

#svgView(transform(scale(2)rotate(45)translate(10,20)))

What happens if you add 'transform(none)' in the middle or the svgView
> syntax, e.g svgView(transform(scale(2)),transform(none),transform(
> scale(2)))?


It would be invalid.  The version you have above is invalid because it has
three different transform attributes, and you're not allowed to repeat
attributes in an svgView fragment(also, multiple attributes are separated
by semicolons, not commas).

If you changed it to  #svgView(transform(scale(2) none scale(2))) it would
be invalid because `transform:scale(2) none scale(2)` is an invalid
transformation list.

__________________________

For getting your head around svgView transformations, try out this test
case (also attached as HTML):
http://fiddle.jshell.net/mbgmL6ap/1/

The Firefox behavior is what we agreed to support.  I'm kind of having
second thoughts about that -- it is definitely weird that the same URL for
an image has very different results at different image sizes.  And not in
an intentional, media-query type way!

It's also quite different from transforming inline SVG elements, where the
layout box moves around the page but the content stays in the same place
within the box.  It is however, consistent with the way the CSS Transforms
module says that transformations on a root element should be applied.

The effect is as if the <img> is a window through which you're looking at
an infinite drawing canvas on which the SVG is drawn, and that canvas is
being moved or resized by the transformation.  However, before moving or
stretching the canvas, the image dimensions are marked out on it and the
graphic is scaled to fit it according to the viewBox.

All of which is quite separate from the question of whether transformations
should add to or replace any existing transformations on the root element.
I didn't have any sample SVGs to grab to use that, and the browsers
wouldn't support it anyway (maybe Firefox does, in which case I'm pretty
sure they would use a *replace* behavior for transformations in the svgView
fragment).

__________________________

I can come up with some alternatives for the spec text, clearly explaining
the resulting behavior, for discussion next week or the week after.

AmeliaBR


> [1] http://www.w3.org/2015/02/26-svg-minutes.html#item03.
>
> --
> Erik Dahlstrom, Web Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
>
>