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

Re: Apple's Proposal for CSS Transformations

From: David Hyatt <hyatt@apple.com>
Date: Tue, 06 Nov 2007 16:45:37 -0600
To: David Woolley <forums@david-woolley.me.uk>
Cc: www-style@w3.org
Message-id: <348F6B04-9B4B-4D3F-A3B8-2392E8FEF536@apple.com>

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  

>> 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.

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:31 UTC