- From: Simon Fraser <smfr@me.com>
- Date: Fri, 03 Sep 2010 16:28:34 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "www-style@w3.org" <www-style@w3.org>
Agreed on the difficulty of parsing the gradient stuff. On Sep 3, 2010, at 12:37 PM, Boris Zbarsky wrote: > On 9/3/10 3:12 PM, Daniel Glazman wrote: >> 2. manipulating CSS 3 Transforms is also difficult because the computed >> value of a very simple and highly readable set of transforms like >> >> rotate(45deg) translateX(100px) >> >> is a matrix... Decomposing the matrix to retrieve the various >> components composing the transformation is documented in the spec >> but I really don't understand why this is not implemented somewhere >> in the DOM. We have an TODO for WebKit to expose methods on CSSMatrix to assist with decomposition. >> It will be faster and safer than hundreds of various >> matrix decomposition codes (and their bugs...). >> In the case of a larger set of individual transforms - let's say >> a dozen of transforms in a row - the "history" of transforms >> chronologically applied by the web author is entirely lost when you >> look at a specified value or the computed value. That loss is >> huge for a web author. > > Er... nothing is lost when looking at specified values. At least in Gecko. > > Furthermore, we keep track of the original value even in computed style data, because transitions need it.... But that's not what we surface in getComputedStyle, per spec. We'd be happy to change the spec to say that getComputedStyle() for 'transform' can return a function list, when possible. If you're in the middle of an animation, and the two endpoints have unmatched lists, then you'll get matrix(...), but otherwise we should be able to preserve the lists. Simon
Received on Friday, 3 September 2010 23:29:24 UTC