- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Tue, 13 Jan 2009 21:33:40 +0100
- 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 UTC