W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [CSS3] transforms vs. transitions.

From: Dean Jackson <dino@apple.com>
Date: Wed, 2 Mar 2011 06:10:24 +1100
Cc: "www-style@w3.org list" <www-style@w3.org>
Message-Id: <1C3E7D79-F74E-42B7-8E87-08D670C3127E@apple.com>
To: Andrew Fedoniouk <news@terrainformatica.com>

On 27/02/2011, at 4:56 PM, Simon Fraser wrote:

> 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.

Not to mention that you'd also need to define the order of application for these split transform functions, and then people would complain because they wanted, eg,  the rotate before the scale before the translate in some cases.

>> 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 Tuesday, 1 March 2011 19:11:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:57 UTC