[css3-2d-transforms] Comments on 2d transforms

Hello www-style,

Here's an initial review of the FPWD of CSS 2D transforms, http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/.


== Abstract ==

[[ CSS 2D Transforms allows elements rendered by CSS to be transformed in two-dimensional space. ]]

Rendered by CSS isn't fully accurate in the SVG case.


== 1 Introduction ==

[[ This section is not normative. ]]

Could it be labelled "This section is informative" instead? It's easy to miss the negation while reading.

Some of the text here should probably be made normative.


== 2 The ‘transform’ Property ==

The 'transform' and 'transform-origin' properties should apply to svg elements that have @transform as well as to block-level and inline-level elements. A question would be how to deal with @gradientTransform, @patternTransform, should they use the 'transform' property or should they use new properties?

[[ Percentages: refer to the size of the element's box ]]

For 'transform' and 'transform-origin' please add to the above sentence: ", in SVG refers to the size of the element's <a href="http://www.w3.org/TR/SVGTiny12/intro.html#TermBoundingBox">boundingbox</a>"

The spec should say in normative text how/if 'transform' affects the element's box [size, position].


== 3 The ‘transform-origin’ Property ==

[[ 
Value:  [ [ <percentage> | <length> | left | center | right ] [ <percentage> | <length> | top | center | bottom ]? ] | [ [ left | center | right ] || [ top | center | bottom ] ] 
]]

The values 'left', 'right', 'top', 'bottom' and 'center' should all list what percentages they compute to. This would clarify cases where 'top' might mean 'bottom' (or not) e.g if you had mirrored an element by using another transform.

A note: the default value (50%,50%) is different from the default used in SVG currently (0,0). I agree that (50%,50%) is a nicer default, but it may cause some confusion and I'd like to see an informative note about that in the transforms spec.


== 4 The Transformation Functions ==

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

What's the reason for not using <translation-value> (which allows percentages and values with units) instead of <number>?

[[ rotate(<angle>) ]]

The svg definition allows an optional rotation point, "rotate(<rotate-angle> [<cx> <cy>])". What's the reason to diverge from that syntax? One problem with the 'transform-origin' property is that you then need to use several levels of elements with different 'transform-origin' values if you want to have different rotation points.

[[ skew(<angle> [, <angle>]) ]]

This is not in svg syntax, but seems nice to have. This should be added to the svg syntax as well.

The <transform-functions> syntax in CSS doesn't allow the <transform-ref>[1] syntax from SVGT12, what's the reason for that?


== 7.1 Point ==

The 'Point' interface is very similar to 'SVGPoint'[2] defined in SVG. Since it would be nice if all worked fine together in the DOM, why not have 'Point' inherit from 'SVGPoint', if the idea was to give it a more appropriate name (otherwise why not simply use the existing SVG interface?).

Perhaps it should be named 'CSSPoint' to be consistent with 'CSSMatrix' etc?


== 7.2 Window ==

[[ They provide conversions between the page and node coordinate spaces. ]]

Define 'page'. Then define both node and page coordinate space. How would this work in an all-svg document? I'm wondering if 'page' is the most appropriate name here.


== 7.3 CSSMatrix ==

[[ The CSSMatrix interface represents a 4x4 homogeneous matrix. ]]

It's not 4x4 in this spec.

The CSSMatrix interface is very similar to the SVGMatrix interface, what's the reason for going with CSSMatrix?


== 7.4 CSSTransformValue ==

Why 'CSSTransformValue' instead of 'CSSTransform'?

Why 'operationType' instead of 'type', like on SVGTransform?

The CSSTransformValue type constants differ from the ones used in SVGTransform, could they be aligned?


== 8 References ==

References to the SVG11 and SVGT12 specifcations would seem appropriate.


Cheers
/Erik

[1] http://www.w3.org/TR/SVGTiny12/coords.html#transform-ref
[2] http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGPoint and http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGPoint
[3] http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGMatrix and http://www.w3.org/TR/SVGMobile12/svgudom.html#svg__SVGMatrix
[4] http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGTransform

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 23 March 2009 10:14:03 UTC