- From: David Woolley <forums@david-woolley.me.uk>
- Date: Tue, 06 Nov 2007 22:17:15 +0000
- To: www-style@w3.org

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