Re: Some questions regarding transformations in SVG

On Nov 17, 2014, at 1:16 PM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:

> Hello,
> 
> what is mentioned in the CSS drafts, is not necessarily always useful for
> graphics or SVG authors, for example what is mentioned about animation 
> of a matrix type (a general affine transformation) ist still borked by 
> contraproductive 'decompositions', authors cannot simply switch off.

The current behavior is a compromise between browser vendors. Even though I agree that it can return surprising results and that there are better solutions for decomposition even. Regardless, it is much better than no interpolation. I hope that we can keep the discussion open weather or not we provide additional algorithms for transformation matrix interpolation in the future.

> Unfortunately in SVG 1.1 and tiny 1.2 one cannot animate the
> matrix type at all, therefore one still needs to simulate the effect
> using some frame based animation, of example by animating
> xlink:href from use to provide 25 static transformed objects per
> second, resulting in quite big files to solve a simple task.

Correct, and matrix decomposition provides reasonable results for many simple animations.

> 
> Obviously due to the limited 3D, projection and non affine transformation
> capabilities of SVG, one has to work around with own programs anyway
> (typically such approximations generate quite big files).
> Use case/declarative example with a simulation/approximation 
> of a combination of  3D-tranformation, non-affine transformation/projection 
> and reordering of content (replacement for z-index):
> https://upload.wikimedia.org/wikibooks/de/f/f8/SVGzeichenreihenfolge06.svg

Yes, sometimes it is possible to narrow transformations to specific use cases to emulate non-affine transformations. For many of these cases scripting is involved. (Or programmatically created declarative content.)

> 
> With some mathematical capabilities one can simulate a lot of missing
> issues of SVG (or borked features), however, many authors might want
> to have access to this, which do not have such capabilities or specific
> scripts or programs to do the job.

I agree that not everything is possible with pure declarative solutions. I would argue that this will never be the case and that we concentrate on declarative solutions for the 80% use cases. But we want to provide ways to get to the last 20%. Looking at real world use case far more than 80% can be archived with the current level of CSS Transforms. However, there is no way to get to 100% with alternative techniques like scripting in SVG. Looking at the whole web stack, WebGL can bring us (close?) to the 100% and it might be more interesting to bring SVG and WebGL closer together than working on declarative solutions in too many too specific areas.

> Using JavaScript or ecmascript to simulate missing features, is no
> solution as well, just because such user sided scripts are just for
> decoration like CSS, but especially for graphics typically authors
> are more interested in content, therefore a declarative solution
> is required, respectively the workaround is done for example with
> PHP scripts from the server.

Accessibility and content awareness is indeed a strong argument for declarative solutions. However, scripting does for sure not exclude or limit both. Many modern web applications demonstrate that the opposite can be the case.

Greetings,
Dirk

> 
> 
> Olaf
>

Received on Monday, 17 November 2014 12:54:30 UTC