W3C home > Mailing lists > Public > www-style@w3.org > January 2009

Re: CSS Transforms : computed value

From: Dean Jackson <dino@apple.com>
Date: Tue, 13 Jan 2009 14:52:54 -0800
Message-Id: <18716124-8CFD-4ED4-B90C-80FD4AB363D0@apple.com>
To: www-style@w3.org

On Jan 13, 2009, at 12:33 PM, Daniel Glazman wrote:

> Dean Jackson wrote:
>> So you'd like the computed style to keep the same list of transform  
>> operations, but have computed the values for units?
> Exactly.
>> Maybe it is easier to ask: what type of computed value do you  
>> expect to see from an input of
>> transform: translate(2em, 3ex) scale(1.2) translate(3em)  
>> rotate(1grad) ?
> I don't really care about the units. For instance Gecko turns all
> lengths into pixels. But having the ordered series of translate(),
> scale(), translate() and then rotate() is immensely useful to us.

I tend to agree with David that computed style should be the final  
value (which is a matrix), but I see your problem in that you can't  
tell what the input style was.

>> FWIW, the specification does go into detail about decomposing  
>> matrices into components.  Obviously you won't always be able to  
>> recreate the input (especially if the property has a list with  
>> multiple copies of the same transform function), but it might allow  
>> an editing application to take a matrix value and enable editing of  
>> translation, rotation and scale parameters (or even more when you  
>> get into 3d).
> Ah. That's useful information. Thanks. May I recommend a link to that
> decomposition from the CSS Transforms spec?

It's already there, although it is a little hidden.


Basically, this is necessary to get interoperable (and attractive)  
animation of transform values.

> And if the SVG 1.1 is too
> geeky about it, maybe a cleaner description is worth the time spent on
> it ?

The matrix decomposition is well-known math and, as such, not worth  
describing in the specification (other than specifying exactly which  
method of decomposition is being used).

Received on Tuesday, 13 January 2009 23:04:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC