- From: Dean Jackson <dino@apple.com>
- Date: Tue, 17 Feb 2009 20:59:20 +1100
- 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 UTC