- From: Dean Jackson <dino@apple.com>
- Date: Tue, 13 Jan 2009 14:52:54 -0800
- 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. http://webkit.org/specs/CSSVisualEffects/CSSTransforms.html#animation 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). Dean
Received on Tuesday, 13 January 2009 23:04:17 UTC