W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Thoughts on CSS 3 Images, CSS 3 Transforms and CSS OM

From: Simon Fraser <smfr@me.com>
Date: Fri, 03 Sep 2010 16:28:34 -0700
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <378B748B-8606-4699-9ACF-F092147D7467@me.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
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.

Received on Friday, 3 September 2010 23:29:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC