- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 10 Dec 2014 19:26:11 +0100
- To: www-svg@w3.org
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