This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
""" In addition to the interfaces listed above, the getComputedStyle method of the Window object has been updated. The transform property of the style object returned by getComputedStyle contains a single CSSTransformValue with a type of CSS_MATRIX3D. The 16 parameters represent the 4x4 matrix that is the result of applying the individual functions listed in the transform property. """ http://dev.w3.org/csswg/css3-3d-transforms/#dom-interfaces This says getComputedStyle().transform should be an object rather than string in the 3D case. But the test-case data:text/html,<!doctype html> <body style="transform:rotateX(90deg)"> <script> document.documentElement.textContent = typeof getComputedStyle(document.body).transform + " " + getComputedStyle(document.body).transform </script> (adjusted for vendor prefixes) outputs string matrix3d(1, 0, 0, 0, 0, 0, 1, 0, 0, -1, 0, 0, 0px, 0px, 0px, 1) or something close to it in both Firefox 12.0a1 and Chrome 17 dev. (I wasn't able to test IE10.) This matches the behavior of transform in the 2D case, and also every other CSS property I'm aware of. CSSOM gives DOMString as the type for all the properties it discusses: http://dev.w3.org/csswg/cssom/#cssstyledeclaration I suggest the spec be changed to require that if the matrix is of the form [a c 0 e b d 0 f 0 0 1 0 0 0 0 1] then the output be a DOMString "matrix(a, b, c, d, e, f)". Otherwise it should be "matrix3d(...)".
We should have more functionality for CSS Transforms in general and not differ between 2D or 3D at all. I created a Wiki http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issues with some issues on CSS OM and wanted to discuss that on the next CSS WG meeting or FX meeting. But I used getComputedStyle(element).getPropertyCSSValue('transform') for my research. Why should the transform property return a matrix and not a list of the transformation functions, all objects?
I think it should return the transform list (with percentage values resolved, of course), but WebKit doesn't implement it this way.
(In reply to comment #1) > We should have more functionality for CSS Transforms in general and not differ > between 2D or 3D at all. 2D behavior is already interoperable, and we don't want to break getComputedStyle() for existing sites that rely on 2D behavior. So we have to switch between matrix() and matrix3d() as appropriate. > But I used getComputedStyle(element).getPropertyCSSValue('transform') for my > research. As far as I can tell, getPropertyCSSValue() is nonstandard. If someone standardizes it, we can talk about how it should behave, but not before then. > Why should the transform property return a matrix and not a list of > the transformation functions, all objects? getComputedStyle()'s properties are all strings, so 'transform' shouldn't be any different. If we want to expose nicer things like lists of transforms to authors, we should use some other API.
BTW, "not matching implementations" isn't necessarily a spec bug. The spec should describe what we want the behavior to be, not what it happens to be now.
If implementers want to change their behavior, yes, but it's rarely worth it for implementations to change when they're already interoperable, so I normally assume they don't want to change until proven otherwise. Regardless, IMO it *should* be a string. Every preexisting property on CSSStyleDeclaration that corresponds to a CSS property is a DOMString: http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface 'transform' should not be treated differently from every existing property.
I'm confused. We are talking about returning a string. The question is whether the string is "matrix(....)" or "translate(20px, 100px) scale(1.5)".
Okay, I thought by "transform list" you meant "CSSTransformList object". I think that's what Dirk meant, based on <http://www.w3.org/Graphics/fx/wiki/Merged_Transforms#CSSOM_issues> and by the phrase "all objects" in comment #1. It would very possibly have made sense to have the *string* be a list of transforms to start with, but it doesn't seem worth it to change now. If implementers really want to change, that's okay with me, but we have almost complete interop at this point (modulo Gecko throwing in "px", and slight disagreement about when to return "none").
*** This bug has been marked as a duplicate of bug 15797 ***