This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The new spec wording says """ The computed value of the transform property is a matrix() or matrix3d() value that describes the matrix that results from concatenating the individual transform functions. If the resulting matrix can be represented as a two-dimensional matrix with no loss of information, then a matrix() value is returned, otherwise a matrix3d() value. For elements with no transform applied, the computed value is ‘none’. """ http://dev.w3.org/csswg/css3-transforms/#transform-property The previous spec (until a few days ago) said transform's computed value is as specified. Consider this test-case: <!doctype html> <div style="width:1000px;transform:translate(10%)"> <div style="height:100px;width:100px;background:blue; transform:inherit"></div></div> In IE9, Firefox 12.0a1, Chrome 17 dev, and Opera Next 12.00, the div is translated 110px, so "inherit" here is the same as "translate(10%)". This matches the old spec. The new spec implies that "inherit" should be the same as "matrix(1, 0, 0, 1, 100, 0)", so it should be translated 200px. This doesn't match browsers. Likewise, all engines other than WebKit do not convert lengths to absolute lengths for inheritance, which also matches the old spec and not the new. I suggest the old wording be restored: the computed value (i.e., what's inherited) should be "As specified", and the resolved value (i.e., what's returned by getComputedStyle()) should be "matrix(...)" or "matrix3d(...)" or "none". Note that "computed value" is not what is returned by getComputedStyle(), confusingly.
I've probably mis-used "computed value" several times in the new text.
However, http://dev.w3.org/csswg/cssom/#resolved-values says that the resolved value is the same as the computed value except for some subset of properties (excluding transform).
...nor does http://www.w3.org/TR/css3-values/#value-stages talk about resolved values.
(In reply to comment #2) > However, http://dev.w3.org/csswg/cssom/#resolved-values says that the resolved > value is the same as the computed value except for some subset of properties > (excluding transform). Right, but this doesn't match implementations, as the test-case in comment #0 demonstrates. The same is true for transform-origin (see bug 15433). Unless all implementations want to change incompatibly, the transforms spec has to add additional exceptions. Or get the CSSOM spec to add the exceptions, but that seems less desirable. (In reply to comment #3) > ...nor does http://www.w3.org/TR/css3-values/#value-stages talk about resolved > values. Because there's not enough cooperation between Values and Units editors and CSSOM editors, I guess. Either way, browsers return significantly different things from getComputedStyle() from what they do on inheritance, so unless they want to change to align them, we have to change the spec.
(In reply to comment #4) > (In reply to comment #2) > > However, http://dev.w3.org/csswg/cssom/#resolved-values says that the resolved > > value is the same as the computed value except for some subset of properties > > (excluding transform). > > Right, but this doesn't match implementations, as the test-case in comment #0 > demonstrates. The same is true for transform-origin (see bug 15433). Unless > all implementations want to change incompatibly, the transforms spec has to add > additional exceptions. Or get the CSSOM spec to add the exceptions, but that > seems less desirable. Sigh. The Transforms implementations are *so* messed up on details. Following the convention of every properly-specified "computed value" line, it should say something like "as specified, but with relative lengths converted into absolute lengths". As you noted in IRC, this should still be web-compatible, since transforms aren't inherited by default, so impls can safely change to match. > (In reply to comment #3) > > ...nor does http://www.w3.org/TR/css3-values/#value-stages talk about resolved > > values. > > Because there's not enough cooperation between Values and Units editors and > CSSOM editors, I guess. Either way, browsers return significantly different > things from getComputedStyle() from what they do on inheritance, so unless they > want to change to align them, we have to change the spec. "resolved value" isn't a value stage at all. It's a term for "what we used to call 'computed value' in CSS2, before we changed what that term means in CSS2.1 to be saner". It *should* be just the computed value except for the handful of things that return the used value for legacy reasons. We probably need another API for used values everywhere (as they're often more useful), but this should probably just be baked into the Values API when we build that out.
(In reply to comment #5) > Following the convention of every properly-specified "computed value" line, it > should say something like "as specified, but with relative lengths converted > into absolute lengths". > > As you noted in IRC, this should still be web-compatible, since transforms > aren't inherited by default, so impls can safely change to match. I support this change.
(In reply to comment #1) > I've probably mis-used "computed value" several times in the new text. Maybe we should explicitly write computed style for 'transform'? "computed value" could really be misinterpreted.
We should use the same terminology as CSS2.1/CSSOM/etc., but maybe link the terms to the other specs so people know what we're talking about.
(In reply to comment #8) > We should use the same terminology as CSS2.1/CSSOM/etc., but maybe link the > terms to the other specs so people know what we're talking about. Yes, whatever is usual.
Editors decided that getComputedStyle() should return a string containing a list of transform values with lengths resolved to absolute lengths.
I filed a Gecko bug on that: https://bugzilla.mozilla.org/show_bug.cgi?id=732153 As far as the computed value goes, however, it still needs to be "As specified, but with relative lengths converted into absolute lengths", as Tab says in comment 5. This is the computed value as defined by CSS 2.1, i.e., the thing that's inherited. Leaving aside getComputedStyle(), does anyone object to changing the computed value as Tab suggests?
Fixed: http://dvcs.w3.org/hg/csswg/rev/b491a045f29a Of course, this doesn't match browsers anymore.
*** Bug 15431 has been marked as a duplicate of this bug. ***
*** Bug 15535 has been marked as a duplicate of this bug. ***