Bug 15797 - Computed value for 'transform' should be "As specified" again
Computed value for 'transform' should be "As specified" again
Status: RESOLVED FIXED
Product: CSS
Classification: Unclassified
Component: Transforms
unspecified
All All
: P2 normal
: ---
Assigned To: Simon Fraser
public-css-bugzilla
:
: 15431 15535 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-30 19:49 UTC by Aryeh Gregor
Modified: 2012-03-12 21:32 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2012-01-30 19:49:59 UTC
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.
Comment 1 Simon Fraser 2012-01-30 20:52:27 UTC
I've probably mis-used "computed value" several times in the new text.
Comment 2 Simon Fraser 2012-01-30 20:55:13 UTC
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).
Comment 3 Simon Fraser 2012-01-30 20:58:14 UTC
...nor does http://www.w3.org/TR/css3-values/#value-stages talk about resolved values.
Comment 4 Aryeh Gregor 2012-01-30 21:34:10 UTC
(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.
Comment 5 Tab Atkins Jr. 2012-02-02 18:17:39 UTC
(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.
Comment 6 Aryeh Gregor 2012-02-02 21:38:52 UTC
(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.
Comment 7 Dirk Schulze 2012-02-17 17:29:42 UTC
(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.
Comment 8 Aryeh Gregor 2012-02-17 19:17:47 UTC
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.
Comment 9 Dirk Schulze 2012-02-17 19:20:59 UTC
(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.
Comment 10 Simon Fraser 2012-02-21 20:14:50 UTC
Editors decided that getComputedStyle() should return a string containing a list of transform values with lengths resolved to absolute lengths.
Comment 11 Aryeh Gregor 2012-03-01 20:58:21 UTC
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?
Comment 12 Aryeh Gregor 2012-03-12 21:32:26 UTC
Fixed: http://dvcs.w3.org/hg/csswg/rev/b491a045f29a

Of course, this doesn't match browsers anymore.
Comment 13 Aryeh Gregor 2012-03-12 21:32:39 UTC
*** Bug 15431 has been marked as a duplicate of this bug. ***
Comment 14 Aryeh Gregor 2012-03-12 21:32:58 UTC
*** Bug 15535 has been marked as a duplicate of this bug. ***