- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 25 Mar 2009 14:49:04 +0100
- To: www-style@w3.org

Hello, this comment applies to 3d-transforms as well: http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/#animation http://www.w3.org/TR/2009/WD-css3-3d-transforms-20090320/#animation I think, it is not a good idea, that a matrix is decomposed in an (arbitrary) set of other transformations for animation purposes, because: 1. Authors should have the choice. If they need a (non) arbitrary set of other transformations, they can simply write down these sets instead of a matrix. If they need an animation between two matrices, it is the simplest idea to write down exactly two matrices. 2. Interpolation between the matrix components within the animation results in different effects than with a decomposition and animation of each decomposition transformation. Matrix animation can be interesting for authors too, but is currently not available, if the matrix is decomposed before the animation interpolation takes place. 3. The decomposition is almost opaque for the author, the author has no control over this. And it cannot be expected, that authors have to learn c to understand, what happens. The separation in his own set of transformations including matrices without any manipulation ensures transparency and complete control for the author. 4. As far as I understand the source code referenced for the decomposition, this can introduce unneccessary mathematical problems. I'm not a c-programmer, I use other programming languages, but as far as I understand the code, it makes use of a matrix inversion do get the decomposition. Within the animation (especially if a given value is somehow mirrored), there may appear matrices without an inverse, for them there is obviously no decomposition with this code. With skewing it is possible too to have infinite matrix elements, if a transform list is converted into a matrix and decomposed again, this may result in an undefined matrix. 5. There is no real benefit for authors with this decomposition, I think this is only introduced to simplify the life of implementors without any usecase not avialable without the decomposition, therefore there is no loss, if this is skipped. To resume, I suggest to skip the decomposition idea completely. This avoids mathematical problems and paternalism of authors. Best wishes Olaf

Received on Wednesday, 25 March 2009 13:54:14 UTC