W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

comments on transforms

From: Dean Jackson <dino@apple.com>
Date: Tue, 17 Feb 2009 20:59:20 +1100
Message-Id: <DE386490-A480-4D9F-939C-F17C554925B6@apple.com>
To: public-svg-wg@w3.org

Firstly, sorry I'm not there in person, despite it being so close to  
home for me.

I read today's minutes: http://www.w3.org/2009/02/16-svg-minutes.html

A few questions/comments:

* why not adopt the syntax for CSS Transforms (which was written to be  
as compatible as possible with SVG)?

In particular, I see this:
[[[
AG: I agreed to remove translateX/Y/Z and scaleX/Y/Z
JF: translateX/Y is part of the CSS specification but that's just  
syntactic sugar
]]]

While these might shortcuts look like syntactic sugar, they allow for  
something important - which is the ability to break a transform list  
into components that can manipulated individually. This is especially  
important when you're animating between transforms (not necessarily  
with CSS Animations, even JS gets the benefit). Flattening all the  
transform operations is a lossy process (not in the final matrix  
result, but you lose the list).

In general I'm not sure there is benefit in minimising the syntax.  
What is the cost?

* if there are features that are missing, it might be best to suggest  
them as changes to CSS, so everyone can share the same spec. From  
reading your requirements, I can't see anything that isn't met by CSS  
Transforms. Now, I'm saying that mostly because I like it, but really  
I wouldn't like to see another incompatible approach - much better to  
merge :)

* I suggest you stick with 4x4 matrices over 3x3. I wouldn't let the  
fact that OpenVG is 3x3 (is it? I read this in the minutes but didn't  
check) impact the decision. Cameron says that "general 3d effects are  
not useful" - maybe I misunderstood that? I guess I'm unclear as to  
the goal: is it to add a transforms capability that is compatible with  
OpenVG? If so, why? Or is the goal to add simple perspective  
transforms to SVG?

I'll also note that Apple has shipped a mobile product that supports  
arbitrary 4x4 matrix transforms applied to SVG content since about  
July last year.

* There is an extremely important feature to 3d transforms that you  
haven't discussed. In CSS Transforms we call it transform-style:  
preserve-3d. Without this it is difficult to meet your requirements of  
nested 3d transformations. On this point, I suggest you write up your  
rendering model. As far as I can tell, this is the most important part  
of applying 3d to SVG. What happens to the painters' model? Do things  
closer in Z space draw in front, regardless of document order? What  
about elements in adjacent siblings with different Z? Do you flatten  
at group containers? Do objects intersect?

PS. I'm not sure if this should be sent to the public discussion list.  
Feel free to forward it if that is the better place for discussion.
PPS. Please CC on replies - I'm not on the group email list, nor the  
public list.

Dean
Received on Tuesday, 17 February 2009 10:00:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 February 2009 10:00:06 GMT