W3C home > Mailing lists > Public > www-style@w3.org > November 2011

RE: 2d vs 3d transform-origin

From: Brian Manthos <brianman@microsoft.com>
Date: Tue, 1 Nov 2011 00:50:20 +0000
To: Brian Manthos <brianman@microsoft.com>, Simon Fraser <smfr@me.com>, Jennifer Yu <Jennifer.Yu@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D170440DF2D@TK5EX14MBXC264.redmond.corp.microsoft.com>
Quick addendum:

I think I like "in" and "out" better here.  They define a direction rather than an endpoint.  "Offset from front" suggests a distance from positive infinity in the direction of the user which is a little odd, which is not how I was intending to use the keyword below.

Also the inclusion of percentage doesn't make much sense in light of the above.

As such...

Option C (Revised)

CSS4 (Consider)
<transform-origin-3d> = <transform-origin-2d>     [ center   |   [ in | out ] <length> ]?

CSS3 (Simplified)
<transform-origin-3d> = <transform-origin-2d>     [ out <length> ]?

I've included "center" in the Consider grammar because it allows for "center center center" and "right bottom center" which I think are useful.

Hopefully Simon finds this useful to get unblocked.


From: Brian Manthos [mailto:brianman@microsoft.com]
Sent: Monday, October 31, 2011 5:38 PM
To: Simon Fraser; Jennifer Yu
Cc: www-style@w3.org
Subject: RE: 2d vs 3d transform-origin

I'm a little fuzzy on the expected user experience here, but I think simplifying is probably your best bet.

Some options...

Option A

Add a fixed string or character (such as 'z') before the z parameter.

<transform-origin-3d> = <transform-origin-2d> [z <length>]?

Option B

Restrict the 3 dimensional grammar to exclude ambiguity by disallowing the problematic 4 parameter cases.  In my grammar below, I also require {x,y,z} ordering for simplicity.

<transform-origin-3d> =

/* x-param y-param z-param */
<transform-origin-3d-3> =
                [ <percentage> | <length> | left | center | right ]   [ <percentage> | <length> | top | center | bottom ]   <length>

/* center yanchor yoffset zoffset */
/* xanchor xoffset center zoffset */
<transform-origin-3d-4> =
center   [ [ top | bottom ] [ <percentage> | <length> ] ]   <length>
[ [ left | right ] [ <percentage> | <length> ] ]   center   <length>

/* xanchor xoffset yanchor yoffset zoffset */
<transform-origin-3d-5> =
                [ left | right ] [ <percentage> | <length> ]   [ top | bottom ] [ <percentage> | <length> ]   <length>

As I looked back at Option B, specifically the <transform-origin-3d-5> something struck me - Z needs anchor keywords.

Perhaps the Z anchor should use { in, center, out } or { back, center, front }.  That leads to...

Option C

CSS4 (Consider)
<transform-origin-3d> = <transform-origin-2d>     [ center   |   [ back | front ] [<percentage> | <length>]? ]?

CSS3 (Simplified)
<transform-origin-3d> = <transform-origin-2d>     [ front [<percentage> | <length>]? ]?

In short, the CSS3 recommendation is to use the same approach as Option A but use a future-looking keyword.

From: Simon Fraser [mailto:smfr@me.com]
Sent: Monday, October 31, 2011 4:09 PM
To: Jennifer Yu
Cc: www-style@w3.org
Subject: Re: 2d vs 3d transform-origin

On Oct 31, 2011, at 2:30 PM, Jennifer Yu wrote:

Hi guys,

It looks like the ED version of the 2D Transforms spec was updated in March 2010 to align transform-origin with background-position. This is great, except that the 3D Transforms ED had no accommodating update and now clashes with the 2D Transforms spec. For instance, is 'transform-origin: left bottom 20px' specifying a 2D (left, bottom 20px) or 3D (left, bottom, 20px) transform origin?

Good point. I filed <http://www.w3.org/Bugs/Public/show_bug.cgi?id=14647>

I'm not sure how to resolve this, other than invent a new syntax for transform-origin, or to break out transform-origin-z into a separate property.

Received on Tuesday, 1 November 2011 00:57:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:06 UTC