Bug 15432 - 3D syntax for transform-origin conflicts with background-position-like syntax, causing ambiguity
3D syntax for transform-origin conflicts with background-position-like syntax...
Status: RESOLVED FIXED
Product: CSS
Classification: Unclassified
Component: Transforms
unspecified
All All
: P2 normal
: ---
Assigned To: Simon Fraser
:
: 14647 15631 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-05 20:10 UTC by Aryeh Gregor
Modified: 2012-03-07 21:58 UTC (History)
6 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-05 20:10:41 UTC
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".
Comment 1 Simon Fraser 2012-01-05 20:46:55 UTC
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.
Comment 2 Aryeh Gregor 2012-01-06 17:59:44 UTC
Do browsers plan to try implementing transform-origin as the spec says, though?  AFAICT, none currently do.
Comment 3 Simon Fraser 2012-01-06 18:20:06 UTC
I think WebKit's version matches background-position.
Comment 4 Aryeh Gregor 2012-01-08 19:24:36 UTC
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?
Comment 5 Simon Fraser 2012-01-08 20:38:49 UTC
The transforms spec matches the backgrounds & border spec:
http://www.w3.org/TR/css3-background/#the-background-position
Comment 6 Aryeh Gregor 2012-01-08 21:06:36 UTC
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.
Comment 7 Aryeh Gregor 2012-01-12 19:12:12 UTC
This is the same as bug 14647.
Comment 8 Simon Fraser 2012-01-24 16:35:40 UTC
*** Bug 14647 has been marked as a duplicate of this bug. ***
Comment 9 Simon Fraser 2012-01-25 18:38:02 UTC
*** Bug 15631 has been marked as a duplicate of this bug. ***
Comment 10 Dean Jackson 2012-02-21 19:54:14 UTC
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
Comment 11 Aryeh Gregor 2012-02-22 16:27:14 UTC
Discussion: http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0112.html
Comment 12 Dirk Schulze 2012-03-07 18:46:01 UTC
(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.
Comment 13 Aryeh Gregor 2012-03-07 21:58:29 UTC
(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