Re: Apple's Proposal for CSS Transformations

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.

Received on Tuesday, 6 November 2007 22:17:52 UTC