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 current specification defines a transform property for getComputedStyle(), but not a transformOrigin property. The spec should define transformOrigin too. The format should be "Xpx Ypx", where X and Y are numbers. Firefox 12.0a1 will sometimes return percentages instead of lengths for getComputedStyle().MozTransformOrigin, but seemingly only when the transform is "none". All other browsers tested (IE9, Chrome 17 dev, Opera Next 12.00 alpha) always return pixel values. (This ignores the three-value variant of transform-origin: see bug 15432.)
Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=715946 Boris points out that CSSOM says the resolved value of anything is the computed value unless otherwise noted: http://dev.w3.org/csswg/cssom/#resolved-value So the current spec probably does define behavior precisely, although CSSOM doesn't directly say how the transform-origin property is supposed to translate to a transformOrigin key in getComputedStyle()'s result. That's more CSSOM's problem, though. The question is now: do we want to stick with the current spec or change to match implementations? Switching to match implementations would mean one more case where resolved and computed values differ, which is bad. On the other hand, do implementations want to change?
(In reply to comment #1) > Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=715946 This has been fixed, so now all browsers agree (they return pixels, not percentages).
I'll update the spec accordingly if no one objects. It's annoying when getComputedStyle() doesn't match the computed style, but . . .
I updated the spec to match browsers. http://dvcs.w3.org/hg/csswg/rev/9338e35c5058