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

Re: CSS Transforms : computed value

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Tue, 13 Jan 2009 21:33:40 +0100
Message-ID: <496CFAA4.8000101@disruptive-innovations.com>
To: "www-style@w3.org" <www-style@w3.org>

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.

> 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 ? And if the SVG 1.1 is too
geeky about it, maybe a cleaner description is worth the time spent on
it ?

> Also, I have a question. Why are you using the computed value in your 
> editor?

Because it's the closest to what's really applied to a given element and
because you cannot climb up the cascade in any browser, there is API for
that. Please note I started asking for such an API roughly ten years
ago :-)

</Daniel>
Received on Tuesday, 13 January 2009 20:34:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT