Apple's Proposal for CSS Transformations

[David Hyatt]

Some parts of this message have been removed. Learn more about Nabble's security policy.

CSS Transforms

6 Nov 2007

Authors:

Dave Hyatt (hyatt@...), Apple

Dean Jackson (dean.jackson@...), Apple

Chris Marrin (cmarrin@...), Apple

The CSS visual formatting model describes a coordinate system within which each element is positioned. Positions and sizes in this coordinate space can be thought of as being expressed in pixels, starting in the upper left corner of the parent with positive values proceeding to the right and down.

This coordinate space can be modified with the 'transform' property. Using transform, elements can be translated, rotated and scaled in two or three dimensional space. A perspective transform can also be applied to give a sense of depth to the way elements are displayed. In two dimensions, the coordinate space behaves as described in the coordinate system transformations section of the SVG 1.1 specification. This is a coordinate system with two axes: the X axis increases horizontally to the right; the Y axis increases vertically downwards. In three dimensions, a Z axis is added, with positive z values conceptually rising perpendicularly out of the window toward the user and negative z values falling into the window away from the user.

Specifying a value other than 'none' for the 'transform' property establishes a new local coordinate system at the element that it is applied to. Transformations are cumulative. That is, elements establish their local coordinate system within the coordinate system of their parent. In this way, a 'transform' property effectively accumulates all the 'transform' properties of its ancestors. The accumulation of these transforms defines a current transformation matrix (CTM) for the element.

The transform property does not affect the flow of the content surrounding the transformed element. However, the value of the overflow area takes into account transformed elements. This behavior is similar to what happens when elements are translated via relative positioning. Therefore, if the value of the 'overflow' property is 'scroll' or 'auto', scrollbars will appear as needed to see content that is transformed outside the visible area.

Any value other than 'none' for the transform results in the creation of both a stacking context and a containing block. The object acts as though position: relative has been specified, but also acts a containing block for fixed positioned descendants. The z position of a transformed element does not affect the order within a stacking context. With elements at the same z-index, objects are drawn in order of increasing z position.

Need to go into more detail here about why fixed positioned objects should do this, i.e., that it's much harder to implement otherwise.

Transforms should perhaps be allowed to affect layout. Using the position property to do this seems to be the logical choice, but there are lots of questions about how this would work.

What do fixed backgrounds do in transforms? They should probably ignore the transform completely, since - even transformed - the object should be acting as "porthole" through which the fixed background can be viewed in its original form.

Note that while 'transform' uses a three-dimensional coordinate system, the elements themselves are not three-dimensional objects. Instead, they exist on a two-dimensional plane (a flat surface) and have no depth. Furthermore, elements do not intersect with each other in the manner of real-world objects: an element always appears completely in front of or behind another element. In other words, even though the z axis may not be perpendicular to an element's surface, an element always has a single z position, calculated at the center of the element.

This property should also be applicable to SVG elements, but since SVG doesn't have stacking contexts we'd have to describe how the painters' model is changed by z position.

We also need to specify that SVG transforms *do* combine with this transform, e.g., if a <foreignObject> is inside transformed SVG and then defines a transform of its own. This means we may potentially have to examine the current SVG transform and combine with it to set the correct transform.

The 'transform' Property

A 2D or 3D transformation is applied to an element through the 'transform' property. This property contains a list of transform functions. The final transformation value for an element is obtained by performing a matrix concatenation of each entry in the list. The set of transform functions is similar to those allowed by SVG. There are also additional functions to support 3D transformations.

Name:	transform
Value:	none | [ <transform-function> ]* <transform-function>
Initial:	none
Applies to:	block-level and inline-level elements
Inherited:	no
Percentages:	refer to the size of the element's box
Media:	visual
Computed value:	Same as specified value.

The 'transform-origin' Property

The 'transform-origin' property establishes the origin of transformation for an element. This property is applied by first translating the element by the negated value of the property, then applying the element's transform, then translating by the property value. This effectively moves the desired transformation origin of the element to (0,0) in the local coordinate system, then applies the element's transform, then moves the element back to its original position. Since the transform origin only describes X and Y values, moving the origin along the Z axis must be done in the transformation (using the translate3d() transform function).

Name:	transform-origin
Value:	[ [ <percentage> | <length>]{1,2} | [top | center | bottom] || [left | center | right] ] ]
Initial:	50% 50%
Applies to:	block-level and inline-level elements
Inherited:	no
Percentages:	refer to the size of the element's box
Media:	visual
Computed value:	Same as specified value.

This needs to be extended to 3d.

The 'transform-style' Property

The 'transform-style' property defines how nested elements are rendered in 3D space. If the 'transform-style' is 'flat', all children of this element are rendered flattened into the 2D plane of the element. Therefore, rotating the element about the X or Y axes will cause children positioned at positive or negative Z positions to appear on the element's plane, rather than in front of or behind it. If the 'transform-style' is 'perspective', this flattening is not performed, so children maintain their position in 3D space.

This flattening takes place at each element, so preserving a hierarchy of elements in 3D space requires that each ancestor in the hierarchy have the value 'perspective' for 'transform-style'. But since the 'transform-style' affects only an element's children, the leaf nodes in a hierarchy do not require the perspective style.

Name:	transform-style
Value:	flat | perspective
Initial:	flat
Applies to:	block-level and inline-level elements
Inherited:	no
Percentages:	N/A
Media:	visual
Computed value:	Same as specified value.

Does transform-style:perspective need to establish a stacking context and containing block like transform does?

The 'perspective' Property

The 'perspective' property applies the same transform as the perspective(<number>) transform function, except that it applies only to the children of the element, not to the transform on the element itself. If the value is 'none' no perspective transform is applied.

The use of this property with any value other than 'none' establishes a stacking context. It also establishes a containing block (somewhat similar to position:relative), just like the 'transform' property does.

Name:	perspective
Value:	none | <number>
Initial:	none
Applies to:	block-level and inline-level elements
Inherited:	no
Percentages:	N/A
Media:	visual
Computed value:	Same as specified value.

The 'perspective-origin' Property

The 'perspective-origin' property establishes the origin for the perspective property. It effectively sets the X and Y position at which the viewer appears to be looking at the children of the element.

Name:	perspective-origin
Value:	[ [ <percentage> | <length>]{1,2} | [top | center | bottom] || [left | center | right] ] ] | inherit
Initial:	50% 50%
Applies to:	block-level and inline-level elements
Inherited:	no
Percentages:	refer to the size of the box itself
Media:	visual
Computed value:	Same as specified value.

The Transformation Functions

The value of the transform property is a <transform-list>, which is defined as a list of transform functions, applied in the order provided. The individual transform functions are separated by whitespace. The following is a list of allowed transform functions.

matrix(<number>, <number>, <number>, <number>, <number>, <number>)

specifies a 2D transformation in the form of a transformation matrix of six values. matrix(a,b,c,d,e,f) is equivalent to applying the transformation matrix [a b c d e f].

matrix3d(<number>, <number>, <number>, <number>,
                <number>, <number>, <number>, <number>,
                <number>, <number>, <number>, <number>,
                <number>, <number>, <number>, <number>)

specifies a 3D transformation as a 4x4 homogeneous matrix of 16 values in column-major order.

translate(<translation-value>[, <translation-value>])

specifies a 2D translation by the vector [tx, ty], where tx is the first translation-value parameter and ty is the optional second translation-value parameter. If <ty> is not provided, ty has zero as a value.

translate3d(<translation-value>, <translation-value>, <translation-value>)

specifies a 3D translation by the vector [tx,ty,tz], with tx, ty and tz being the first, second and third translation-value parameters respectively.

translateX(<translation-value>)

specifies a translation by the given amount in the X direction.

translateY(<translation-value>)

specifies a translation by the given amount in the Y direction.

translateZ(<translation-value>)

specifies a translation by the given amount in the Z direction.

scale(<number>[, <number>])

specifies a 2D scale operation by the [sx,sy] scaling vector described by the 2 parameters. If the second parameter is not provided, it is takes a value equal to the first.

scale3d(<number>, <number>, <number>)

specifies a 3D scale operation by the [sx,sy,sz] scaling vector described by the 3 parameters.

scaleX(<number>)

specifies a scale operation using the [sx,1,1] scaling vector, where sx is given as the parameter.

scaleY(<number>)

specifies a scale operation using the [1,sy,1] scaling vector, where sy is given as the parameter.

scaleZ(<number>)

specifies a scale operation using the [1,1,sz] scaling vector, where sz is given as the parameter.

rotate(<angle>)

specifies a 2D rotation by the angle specified in the parameter about the origin of the element, as defined by the transform-origin property. The operation corresponds to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0].

rotate3d(<angle>, <number>, <number>, <number>)

specifies a clockwise 3D rotation by the angle specified in first parameter about the [x,y,z] direction vector described by the last 3 parameters. This vector should be normalized (have a length of 1), otherwise the results are typically non-intuitive.

rotateX(<angle>)

specifies a clockwise rotation by the given angle about the X axis.

rotateY(<angle>)

specifies a clockwise rotation by the given angle about the Y axis.

rotateZ(<angle>)

specifies a clockwise rotation by the given angle about the Z axis.

skewX(<angle>)

specifies a skew transformation along the X axis by the given angle.

skewY(<angle>)

specifies a skew transformation along the Y axis by the given angle.

skewZ(<angle>)

specifies a skew transformation along the Z axis by the given angle.

perspective(<number>)

specifies a perspective projection matrix. This matrix maps the viewing cube (the region bounded by the 4 edges of the viewport plus the nearest and furthest visible z values) onto a truncated pyramid whose base represents the furthest visible z value and whose peak represents the viewer's position. The depth, given as the parameter to the function, represents the height of this pyramid. Lower values give a more flattened pyramid and therefore a more pronounced perspective effect. The value is given in pixels, so a value of 1000 gives a moderate amount of foreshortening and a value of 200 gives an extreme amount. The matrix is computed by starting with an identity matrix and replacing the value at row 3, column 4 with the value -1/depth.

The 3d versions could be folded into the 2d primitives using extra optional arguments. It's really just a question of how user agents that can't do 3d should be handled.

Transform Values and Lists

The <translation-value> values are defined as [<percentage> | <length>]. All other value types are described as CSS types. If a list of transforms is provided, then the net effect is as if each transform had been specified separately in the order provided. For example,

is functionally equivalent to:

div {
    transform: translate(100px, 100px);
}

Move the element by 100 pixels in both the X and Y directions.

div {
    transform: translate(50px, 50px) scale(1.40, 1.4) rotate(30deg);
}

Move the element by 50 pixels in both the X and Y directions, then scale the element by 140%, then rotate it 30 degrees clockwise about the Z axis.

[David Woolley (E.L)]

David Hyatt wrote:

>   CSS Transforms

What is the case for using this feature as against using SVG?

> system within which each element is positioned. Positions and sizes in
> this coordinate space can be thought of as being expressed in pixels,

The use of pixel measurements is generally discouraged.  In any case,
there isn't a unique mapping between pixels and cm or pt.  In
particular, could the examples be formulated using more appropriate units.

> <http://www.w3.org/TR/SVG/coords.html#EstablishingANewUserSpace> section
> of the SVG 1.1 specification. This is a coordinate system with two axes:

I guess if it is the SVG one there is a precedent, but it isn't the
standard coordinate geometry space, where y is positive upwards, and I
would have though z positive into the paper was more intuitive.

> The 'perspective-origin' property establishes the origin for the
> /perspective/ property. It effectively sets the X and Y position at
> which the viewer appears to be looking at the children of the element.
>
> /Name:/ perspective-origin
> /Value:/ [ [ <percentage> | <length>]{1,2} | [top | center | bottom] ||

It seems to me that you need z-axis information, as well, to define a
viewing point that allows sensible perspective transformations.

>     transformation matrix *[a b c d e f]*.

That's a vector.  Do you mean 3 x 2 or 2 x 3.

> perspective(<number>)
>     specifies a perspective projection matrix. This matrix maps the
>     /viewing cube/ (the region bounded by the 4 edges of the viewport
>     plus the nearest and furthest visible z values) onto a /truncated

What counts as visible (e.g. are points masked by foreground objects
still visible)?

>     pyramid/ whose base represents the furthest visible z value and
>     whose peak represents the viewer's position. The depth, given as the

Is this the untruncated peak?  Actually, I'm having real trouble
understanding this.  What is the height of the truncated/untruncated
pyramid, depending on the answer to the previous question?

>     parameter to the function, represents the height of this pyramid.
>     Lower values give a more flattened pyramid and therefore a more
>     pronounced perspective effect. The value is given in pixels, so a
>     value of 1000 gives a moderate amount of foreshortening and a value

Note previous reservations about pixels.

>     of 200 gives an extreme amount. The matrix is computed by starting
>     with an identity matrix and replacing the value at row 3, column 4
>     with the value -1/depth.

That may sufficiently define it, although I think there is an assumption
about viewpoint.  It's a while since I used homogenous coordinates, so I
can't check quickly.

>
> The 3d versions could be folded into the 2d primitives using extra
> optional arguments. It's really just a question of how user agents that
> can't do 3d should be handled.

Definitely need more work!
>
> transforms is provided, then the net effect is as if each transform had
> been specified separately in the order provided. For example,

Something missing here!  At a guess some combination of position, top
and left.
>
>     transform: translate(50px, 50px) scale(1.40, 1.4) rotate(30deg);

How does scale interact with min-width, etc?  What stops transforms
making text unreadable, by, for example, rotating it side on to the
paper?  Will this mechanism survive the user overrides necessary to
defeat this sort of behaviour?  Is it possible to define such overrides
as !important rules within this model?

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[David Hyatt]

On Nov 6, 2007, at 4:17 PM, David Woolley wrote:

>
> David Hyatt wrote:
>
>>   CSS Transforms
>
> What is the case for using this feature as against using SVG?
>

This feature is generically applicable to all markup and works with  
both HTML and SVG.  It allows for the creation of presentational  
effects without having to convert a Web site from HTML to a compound  
document.  (SVG should not be required for simple use cases like  
rotating an image slightly.)  CSS today already has a basic  
translation transformation primitive with relative positioning and  
left/top.

>> system within which each element is positioned. Positions and  
>> sizes in this coordinate space can be thought of as being  
>> expressed in pixels,
>
> The use of pixel measurements is generally discouraged.  In any  
> case, there isn't a unique mapping between pixels and cm or pt.  In  
> particular, could the examples be formulated using more appropriate  
> units.
>

I don't really understand this criticism.  The best way to think of  
the resolved transformation matrix (CTM) is in terms of CSS pixels.  
This has nothing to do with what units might be used in the  
primitives themselves (which do support em or pt or in or whatever).

>> <http://www.w3.org/TR/SVG/coords.html#EstablishingANewUserSpace>  
>> section of the SVG 1.1 specification. This is a coordinate system  
>> with two axes:
>
> I guess if it is the SVG one there is a precedent, but it isn't the  
> standard coordinate geometry space, where y is positive upwards,  
> and I would have though z positive into the paper was more intuitive.
>

y is downwards in all the existing DOM functions in browsers for  
accessing coordinate information (scrollTop, offsetTop, etc).  
Positive offset values of 'top' also result in a downward positioning  
of an object.  I don't see any reason to reverse this.

>
> Something missing here!  At a guess some combination of position,  
> top and left.

Yeah my mailer ate that example.  :)

>>     transform: translate(50px, 50px) scale(1.40, 1.4) rotate(30deg);
>
> How does scale interact with min-width, etc?  What stops transforms  
> making text unreadable, by, for example, rotating it side on to the  
> paper?  Will this mechanism survive the user overrides necessary to  
> defeat this sort of behaviour?  Is it possible to define such  
> overrides as !important rules within this model?
>

Yes, you can say transform: none !important; to kill all transforms  
if desired.  Nothing stops transforms from making something  
unreadable, just as nothing stops opacity from making something  
unreadable, or relative positioning from shoving an object out of  
view to the top or left of the viewport.

dave
(hyatt@...)

[Andrew Fedoniouk]

Some parts of this message have been removed. Learn more about Nabble's security policy.

David Hyatt wrote:

CSS Transforms

6 Nov 2007

Authors:

Dave Hyatt (hyatt@...), Apple

Dean Jackson (dean.jackson@...), Apple

Chris Marrin (cmarrin@...), Apple

The CSS visual formatting model describes a coordinate system within which each element is positioned. Positions and sizes in this coordinate space can be thought of as being expressed in pixels, starting in the upper left corner of the parent with positive values proceeding to the right and down.

This coordinate space can be modified with the 'transform' property. Using transform, elements can be translated, rotated and scaled in two or three dimensional space. A perspective transform can also be applied to give a sense of depth to the way elements are displayed. In two dimensions, the coordinate space behaves as described in the coordinate system transformations section of the SVG 1.1 specification. This is a coordinate system with two axes: the X axis increases horizontally to the right; the Y axis increases vertically downwards. In three dimensions, a Z axis is added, with positive z values conceptually rising perpendicularly out of the window toward the user and negative z values falling into the window away from the user.

Rotation and other transformations makes sense mostly for dynamic effects as far as I understand the intention.
Isn't it better to add method Graphics.draw(Element) so element could be drawn on Canvas or on Image with desired
transformations before and after rendering? That would be more universal solution I guess.

Andrew Fedoniouk.
http://terrainformatica.com

[David Woolley (E.L)]

David Hyatt wrote:

> This feature is generically applicable to all markup and works with both
> HTML and SVG.  It allows for the creation of presentational effects

I see it as further blurring the distinction between the different
technologies.

>> The use of pixel measurements is generally discouraged.  In any case,
>> there isn't a unique mapping between pixels and cm or pt.  In
>> particular, could the examples be formulated using more appropriate
>> units.
>>
>
> I don't really understand this criticism.  The best way to think of the
> resolved transformation matrix (CTM) is in terms of CSS pixels.  This
> has nothing to do with what units might be used in the primitives
> themselves (which do support em or pt or in or whatever).

Your perspective function is explicitly specified in pixels.

The problem with pixels is that, for typical visual browsers, they
behave like absolute units, which is bad because it means that users
cannot scale the text, in particular, to meet their eyesight needs.
Moreover, even allowing for very high resolution media, they vary over
more than about 2:1 in their angular range, so they are not well
defined.  Generally, the use of pixels tends to be associated with
designers who only design for their own display hardware configuration
and want page description like rendering accuracy.

>
> Yes, you can say transform: none !important; to kill all transforms if
> desired.  Nothing stops transforms from making something unreadable,
> just as nothing stops opacity from making something unreadable, or
> relative positioning from shoving an object out of view to the top or
> left of the viewport.

My concern is that accessibility has not been considered here and that
people using this technology will not think about accessibility when
they use it.


--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[Lachlan Hunt]

David Woolley wrote:
> The problem with pixels is that, for typical visual browsers, they
> behave like absolute units, which is bad because it means that users
> cannot scale the text, in particular, to meet their eyesight needs.

That's an old IE6 bug which has been resolved in IE7 and, AFAIK, is not
present in any other major browser.  There is no inherent accessibility
problem with using px units as far as scaling is concerned.

--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

[Alastair Campbell-5]

On 11/7/07, Lachlan Hunt <lachlan.hunt@...> wrote:
> That's an old IE6 bug which has been resolved in IE7

Not really, IE7 will still not adjust fonts that are sized with pixels
(with the view > text size menu).

It has implemented an overall zoom feature which seems intended to
replace the text zoom. However, in the context of sizing things with
pixels vs EMs / percentage, this bug/feature could become apparent
again.

Kind regards,

-Alastair

[James Elmore]

This is an interesting start, but seems to be missing some things.

First: it is possible to scale, rotate, and skew, only if you use transform functions; I find no CSS style parameters to do any of these unless you use transform functions. So, I would like to see style properties for all of the transform functions: transform-origin (I prefer the SVG 'translate'), scale, rotate, skew, and perspective (I prefer 'viewpoint' as it seems clearer to me than perspective and perspective-origin). Define the CSS styles and parameters first, then explain the transform functions, it will be simpler to write and to understand. The concept of transform functions, to simplify the definition of complex transformations is not bad, but for simple changes, they should be possible with simple CSS styles.

Second: why not make all of the styles/functions 3D? With the default being 0 for unused parameters, the 2D and 3D styles/functions would work identically without the need for a second style/function (scale/scale3d, rotate/rotate3D). If this works, the extras (e.g., scaleX, scaleY, and scaleZ) might also be unnecessary -- I can see where they would be useful, but if a user can do the same thing just by adding one or two zero parameters, it might simplify the CSS, reducing the need for extra styles. (I can't be sure how this would work with the 'matrix' functions, since it is not clearly stated what the numerous values mean.)

Third: how does this relate to current CSS styles? Is a translate/transform-origin equivalent to 'position: relative;' or is it more like a float, or does the containing block just grow? How is the layout changed or not changed if the element is rotated (and therefore takes less/more space in the layout)? Do the adjacent elements get moved or are they placed behind/in front of the translated element? What about wrapping elements and text around the transformed blocks? Can they be wrapped tightly, or must there be extra margins or even right angle margins? Does a scale operation get communicated so that the larger/smaller element size is fit into the layout and the adjacent elements move, or does the original block size remain and the margins become larger/smaller/negative? Does a skew change the containing block so it is no longer rectangular, implying a different form of wrapping as well?

Finally: where is the explanation of 'skew'? From reading SVG, I think I know what this proposal means, but there is neither confirmation nor denial and I can't be sure.

On Nov 6, 2007, at 12:29 PM, David Hyatt wrote:

CSS Transforms

This is a good start on some interesting ideas. Can we improve it?

James Elmore