Re: [CSS3] transforms vs. transitions.

On Feb 26, 2011, at 4:08 pm, Andrew Fedoniouk wrote:

> For the reference:
> Transforms [2d] are defined here: http://www.w3.org/TR/css3-2d-transforms
> Transitions are defined here: http://www.w3.org/TR/css3-transitions/
> 
[snip]
> 
> But that is not quite possible at the moment as there are no independent
> properties like 'transform-scale' or 'transform-translate' - only single 'transform' aggregate
> that defines all of them. But for the need of animations as in this case
> we should have them separated so it will be able to apply different timing
> functions to different components of the transform matrix.
> 
> I think it makes sense to split the 'transform' into atomic properties, at least on
> 'transform-scale', 'transform-translate', 'transform-skew' parts
> and to left 'transform' as it is now but to declare it as a shorthand of these three.

I think that adding new transform-foo properties for each kind of transform function is adding
too much complexity. 

You could achieve the effect you want with an additional container element for each child.

> And yet it is not clear why do we need that pretty controversial matrix() thing:
> transform:matrix(<number>, <number>, <number>, <number>, <number>, <number>)
> Exactly the same result can be achieved by using scale(), translate() and skew().
> Why such a redundancy?

Various reasons. One is that authoring tools may want to provide the ability to create arbitrary 
transforms using whatever UI affordance they think is appropriate.

Secondly, getComputedStyle() has to return something when you're in the middle of a
transition between mismatched sets of functions.

Thirdly, some people may just want to provide a raw transformation matrix.

Simon

Received on Sunday, 27 February 2011 05:56:42 UTC