Re: [svg2] transform on <svg>

Robert Longson:
>#svgView(transform(...);transform(...);viewBox(...);viewBox(...);transform(...)).
>
>Firefox treats repetition as an error and ignores the view spec
>completely in that case.
>
>Robert.

Yes, the recommendation notes at least that there are five parameters,
which either replace some attribute value of a view or implicate a
transformed g element.
This implicates for me, that multiple usage of one parameter is
either undefined or nonsense, therefore surely a good approach
to ignore it ;o)


Erik Dahlström:

>An svgView transform could very well differ in how it's applied compared  
>to being as an attribute directly on the <svg> element, assuming that's  
>how we want to define it.

Sure, why not, would be pretty exciting to see, how a viewer manages
to rotate or skew the viewport or even a window with an SVG document
inside to get a nice effect for this ;o)
On my Linux systems with properly working monitors 
I have never seen windows skewed or rotated with an arbitrary angle
to get a meaningful interpretation of this.
Just to transform and to generate another artificial canvas or viewport
with the ususal aligment just to keep such a transformed canvax/viewport
would be pretty boring and is maybe superfluous and even
complex to adjust the rotated viewBox properly again within such
an additional artificial canvas or viewport.
Some viewers have already major problems to determine the
correct viewBox of a g element containing a transformed object
in it, to require them to rotate and align a viewBox/preserveAspectRatio
combination correctly sounds like a lot of fun for authors again to report 
bugs ;o)

I got already the impression, that some viewerrs do not get it right now
for all currently possible combinations of viewBox and preserveAspectRatio,
different units for the root width and height (or if they are implicated to be 
100%) - even worse, if this is embedded as a fragment within another
((X)HTML) document - most seem to igore in such a case for example
an implicated 100% height in combination with a CSS viewbox with defined
width and height or in case of usage as a CSS background image, 
therefore I'm pretty pessimistic about meaningful implementations of even 
more complex stuff as rotated and skewed SVG documents as 
scalable CSS background images ;o)

I might have a few (one or two) use cases for this, especially with
preserveAspectRatio of the slice type to fill all the background of some 
XHTML documents completely. 
But currently this is already a funny nightmare to see, 
how different and bad this works with current viewers without additional
transforms, taking into account all there bugs and gaps to get the size 
and clipping right.

Maybe better to keep it simple to have some predictable and usable result 
at all for authors in a finite time ;o)

Olaf

Received on Wednesday, 10 December 2014 18:26:42 UTC