This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
No browser appears to implement the three- or four-value versions of transform-origin per spec. IE9 and Opera Next 12.00 alpha don't seem to support three or more values at all. Firefox 12.0a1 and Chrome 17 dev seem to support three arguments (not documented on MDN: https://developer.mozilla.org/en/CSS/transform-origin), but not per spec. For instance, "-(moz|webkit)-transform-origin: left bottom -1px" works (is parsed), but "0% 100% -1px" does too, which the spec doesn't allow; and "bottom -1px left" doesn't work, although the spec says it should. The easiest way forward seems like just dropping the three- and four-value variants of transform-origin. Aren't they redundant with calc() anyway? You can do things like "transform-origin: calc(0% - 10px) calc(100% + 5px)" instead of "transform-origin: left -10px bottom 5px".
The 2D version of transform-origin is intended to have exactly the same behavior as background-position. The 3D version adds a final option value which is the z-offset.
Do browsers plan to try implementing transform-origin as the spec says, though? AFAICT, none currently do.
I think WebKit's version matches background-position.
From black-box testing in Chrome 17 dev, background-position doesn't accept more than two arguments. Setting document.head.style.backgroundPosition = "left bottom 1px" has no effect. Also, I just figured out that WebKit accepts three arguments to -webkit-transform-origin, but treats them completely differently from the spec. Setting document.head.style.webkitTransformOrigin = "left bottom 1px" adds the attribute style="-webkit-transform-origin-x: 0%; -webkit-transform-origin-y: 100%; -webkit-transform-origin-z: 1px; ". So the third argument is interpreted as z-axis, totally different from <http://dev.w3.org/csswg/css3-transforms/#transform-origin-property>. I suspect Gecko does the same, because it doesn't accept percentages for the third argument. They seem to implement it per <http://dev.w3.org/csswg/css3-3d-transforms/#transform-origin-property>. So it looks like the 2D three-argument variant of transform-origin conflicts with the 3D variant. Browsers appear to implement the 3D variant or nothing, so as far as I can see it, the 2D spec should still not define a three-argument variant for transform-origin. Am I missing something?
The transforms spec matches the backgrounds & border spec: http://www.w3.org/TR/css3-background/#the-background-position
Okay, I feel like we're talking past each other. Let me say what I mean in more detail: The 2D and 3D transform specs conflict: <http://dev.w3.org/csswg/css3-transforms/#transform-origin-property> vs. <http://dev.w3.org/csswg/css3-3d-transforms/#transform-origin-property>. We can't give 2D transform-origin the same syntax as CSS 3's background-position if 3D transform-origin gives a different meaning to the same value. Per the current 2D transform spec, transform-origin: left bottom 10px; means the transform origin is ten pixels above the bottom-left corner of the element along the *Y*-axis. Per the current 3D transform spec, the exact same property declaration means that the transform origin is ten pixels above the bottom-left corner of the element along the *Z*-axis. They can't both be right. Gecko and WebKit both implement the 3D spec, not the 2D, as demonstrated by the following test-case: data:text/html,<!doctype html> <div style="height:50px;width:50px;background:blue"> <div style="height:20px;width:20px;background:red; -webkit-transform:rotate(45deg); -moz-transform:rotate(45deg); -webkit-transform-origin:left bottom 10px; -moz-transform-origin:left bottom 10px"></div> </div> Per the 2D transform spec, this should rotate the red box 45 degrees around the center of its left edge, same as this: data:text/html,<!doctype html> <div style="height:50px;width:50px;background:blue"> <div style="height:20px;width:20px;background:red; -webkit-transform:rotate(45deg); -moz-transform:rotate(45deg); -webkit-transform-origin:left center; -moz-transform-origin:left center"></div> </div> Per the 3D transform spec, it should rotate it 45 degrees around its bottom left corner, same as this: data:text/html,<!doctype html> <div style="height:50px;width:50px;background:blue"> <div style="height:20px;width:20px;background:red; -webkit-transform:rotate(45deg); -moz-transform:rotate(45deg); -webkit-transform-origin:left bottom; -moz-transform-origin:left bottom"></div> </div> Firefox 12.0a1 and Chrome 17 dev both do the latter. I suggest the 2D spec change to not conflict with the 3D spec here, since browsers follow the 3D spec. The easiest way to do this is to change the 2D spec to only accept two values.
This is the same as bug 14647.
*** Bug 14647 has been marked as a duplicate of this bug. ***
*** Bug 15631 has been marked as a duplicate of this bug. ***
21 Feb Informal editors meeting: resolution was to send to public-fx with the alternatives and suggestion: - transform origin matches background-position up to a / character, after that is Z - new property transform-origin-z which separates the Z value - leave the properties inconsistent and define syntax only for transform origin Z
Discussion: http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0112.html
(In reply to comment #11) > Discussion: http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0112.html The CSS WG decided to go the way current implementation support "transform-origin", means just one argument per dimension. That means transform-origin will have 1 to 3 arguments. First two are translation-values, the last one length. The last two arguments will be optional each.
(In reply to comment #12) > (In reply to comment #11) > > Discussion: http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0112.html > > The CSS WG decided to go the way current implementation support > "transform-origin", means just one argument per dimension. That means > transform-origin will have 1 to 3 arguments. First two are translation-values, > the last one length. The last two arguments will be optional each. I've implemented this decision: http://dvcs.w3.org/hg/csswg/rev/16db95fda02f