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

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. 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.


> 3. we desperately need Element.getCascadedValue(property) and
> Element.getCascadedPriority(property).

Agreed.

> 4. to be able to automatically manipulate styles in a wysiwyg
> editor, an API to find all rules applying to a given element
> (see inIDOMUtils in Gecko) is needed.

This turns out to have security issues.  This is why the inIDOMUtils 
functionality is not exposed to content in Gecko, for example.  See 
https://bugzilla.mozilla.org/show_bug.cgi?id=438278 for some discussion. 
  Perhaps now that we no longer load cross-site non-stylesheets as 
stylesheets some of the security restrictions here can be relaxed...

> An API to retrieve the specificity of each selector in the group of selectors
> (possibly reduced to one single selector) attached to a given
> style rule is needed too.

Yeah, agreed.

-Boris

Received on Friday, 3 September 2010 19:38:26 UTC