review comments for SVG-related parts of css3-transforms

Hi Dirk,

here are my comments on 
http://dev.w3.org/csswg/css3-transforms/#svg-transform for ACTION-3244.


Substantive
-----------

In 7. The SVG 'transform' attribute:

   This specification will also introduce the new presentation
   attributes ‘transform-origin’, ‘perspective’, ‘perspective-origin’,
   ‘transform-style’ and ‘backface-visibility’ in the SVG namespace. All
   new introduced presentation attributes are animateable.

These attributes are not in the SVG namespace; rather they're in no 
namespace (or in the "null" namespace, not sure what's the preferred 
terminology).  I think you can just drop "in the SVG namespace".


In 7.2.1. Transform List:

   The value for the ‘transform’ attribute consists of a transform list
   with zero or more transform functions in the functional notation. If
   the transform list consists of more than one transform function,
   these functions are separated by either a comma (‘,’) with optional
   whitespace before and after the comma or one or more whitespaces. The
   transform list can have optional whitespaces before and after the
   list.

So does this mean it's not allowed to have no white space between the 
transform functions?  For example

   style="transform: scale(1)translate(10px,10px)"

?  Just testing in Firefox, that kind of syntax seems to be acceptable.


In 7.3. The SVG ‘gradientTransform’ and ‘patternTransform’ attributes:

If we go ahead with the proposal to make the gradient mesh element be 
renderable as well as being a paint server, does that mean there is a 
conflict here between the gradient transform and the transform of that 
rendering?  Or does it not matter that there would only be a single 
transform property that acts as the target for both the 
gradientTransform and transform presentation attributes?


In 7.4. SVG transformation functions:

   User agents are just required to support the two optional arguments
   for translation on elements in the SVG namespace.

It's unclear to me what this means.  Does it mean that the three 
argument rotate() transform function is only supported in the transform, 
gradientTransform and patternTransform presentation attributes?  If you 
are meaning to allow it in properties too then I don't think it makes 
sense to restrict it to SVG elements.  You would at least need to parse 
it everywhere -- but would you want the behaviour to be different 
depending on which element it applied to?

For example with:

   <!DOCTYPE html>
   <style>
     span, rect { transform: rotate(15deg, 100px, 100px) }
   </style>
   <p><span>hello
   <p><svg><rect width="100" height="100"/></svg>

would the span be rotated around its centre point (due to its 
transform-origin) and would the rect be rotated around its bottom-right 
corner?


In 7.5. SVG and 3D transformation functions:

   Transformable elements that are contained by one of these elements
   can have three-dimensional transform functions.

<mask> is one of the elements on which 3D transform functions are 
ignored.  But <mask> is also a transformable element, so the sentence 
above almost sounds contradictory for cases like:

   <mask>
     <mask/>
   </mask>


In 7.7. SVG DOM interface for the ‘transform’ attribute:

   The ‘transform’ property contributes to the CSS cascade. According to
   SVG 1.1 user agents conceptually insert a new author style sheet for
   presentation attributes, which is the first in the author style sheet
   collection.

What happens when you call getComputedStyle for the transform property 
where its value was determined by one of the SVG transform presentation 
attributes that uses syntax that is not allowed in properties?  For 
example if you have

   <g transform="translate(100) rotate(1 2 3)">

then what does getComputedStyle return?  I think the document needs to 
define exactly how the presentation attributes get mapped into the 
author style sheet.


   It might still be possible to get the ‘SVGMatrix’ by the attribute
   ‘matrix’.

We should define exactly in which circumstances it is not possible to, 
and what the attribute should return in those cases.


In 7.8.2. The SVG ‘attributeName’ attribute:

   For the presentation attributes ‘gradientTransform’ and
   ‘patternTransform’ it will also be possible to use the value
   ‘transform’. The same presentation attribute style will get animated.

Why?  I don't think there's really much need for this.  Is there 
anything wrong with letting

   <linearGradient>
     <animate attributeName="transform" .../>
   </linearGradient>

animate the transform property instead of making it animate the 
gradientTransform presentation attribute?


In 7.8.3. The SVG ‘attributeType’ attribute:

   However, in the combination with the ‘transform’, ‘patternTransform’
   and ‘gradientTransform’ presentation attributes, ‘attributeType’ can
   just be used to indicate the syntax rules used for the transform
   attribute values.

Do you mean that attributeType for these three attributes now does not 
select between animating the presentation attribute and the property? 
If so, why?  I'm not sure why we need to make this restriction.

I think I would prefer it if the SVG transform syntax were allowed in 
SVG animation elements, regardless of whether it is targetting the 
attribute or the property.  If it is targetting the property (which 
would be the default for auto) then we can use the same rules for 
converting that transform list into one suitable for the property that 
we do for the mapping of presentation attribute values into the author 
style sheet.


In 7.8.4. The SVG ‘animateTransform’ element:

   The SVG ‘type’ attribute gets extended by all transform functions
   listed in 2D Transformation Functions, 3D Transformation Functions
   and SVG Transformation Functions.

For all the new types that animateTransform supports, is the syntax for 
values just a comma-or-whitespace separated list of the values that 
appear within the parentheses of the functional notation?  This should 
be defined.



Editorial
---------

In 7. The SVG 'transform' attribute:

   In order to improve the integration of SVG and HTML, this
   specification makes these SVG attributes to ‘presentation attributes’
   and makes the ‘transform’ property one that applies to transformable
   elements in the SVG namespace.

s/attributes to/attributes/

   This specification will also introduce the new presentation
   attributes ‘transform-origin’, ‘perspective’, ‘perspective-origin’,
   ‘transform-style’ and ‘backface-visibility’ in the SVG namespace. All
   new introduced presentation attributes are animateable.

s/animateable/animatable/


In 7.1. SVG ‘transform’ attribute specificity:

   Since the previously named SVG attributes become presentation
   attributes, their participation to the CSS cascade is determined by
   the specificity of presentation attributes, as explained in the SVG
   specification.

s/participation to/participation in/

I'd get rid of those two spaces in "translate  (200 200)" in the 
example.  [Although later in the document you explicitly call that out 
-- I guess it's an example of syntax that you can use in the 
presentation attribute but which is not valid as the property?]

The example markup feels a bit naked with <svg> at the root.  Maybe you 
can change it to <svg xmlns="http://www.w3.org/2000/svg"> so it feels 
self contained.

   Because of the participation to the CSS cascade, the ‘transform’
   style property overrides the ‘transform’ presentation attribute.
   Therefore the container gets translated by ‘100px’ in horizontal and
   vertical direction, instead of ‘200px’.

s/participation to/participation in/
s/in horizontal and vertical direction/in both the horizontal and 
vertical directions/


In 7.2. Syntax of the SVG ‘transform’ attribute:

   To provide backward compatibility, the syntax of the ‘transform’
   presentation attribute differs from the syntax of the ‘transform’
   style property like shown in the example above.

s/backward/backwards/
s/like/as/


In 7.2.1. Transform List:

   The value for the ‘transform’ attribute consists of a transform list
   with zero or more transform functions in the functional notation. If
   the transform list consists of more than one transform function,
   these functions are separated by either a comma (‘,’) with optional
   whitespace before and after the comma or one or more whitespaces. The
   transform list can have optional whitespaces before and after the
   list.

s/in the functional notation/using functional notation/
s/whitespaces/whitespace characters/
s/optional whitespaces/optional whitespace/

(Whitespace can be an adjective or an uncountable noun, but not a 
countable noun.)

The second sentence sounds a bit unclear.  Maybe wording it like the 
following would help:

   If the transform list consists of more than one transform function,
   these functions are separated by either a comma (‘,’) with optional
   whitespace before and after the comma, or by one or more whitespace
   characters.


In 7.2.2. Functional Notations:

s/Notations/Notation/

   The syntax starts with the name of the function followed by optional
   whitespaces followed by a left parenthesis followed by optional
   whitespace followed by the argument(s) to the notation followed by
   optional whitespace followed by a right parenthesis.  If a function
   takes more than one argument, the arguments are either separated by a
   comma (‘,’) with optional whitespace before and after the comma or
   one or more whitespaces.

s/optional whitespaces/optional whitespace/
s/one or more whitespaces/one or more whitespace characters/
s/comma or/comma, or by/


In 7.2.3. SVG Data Types:

   Arguments of transform functions consists of data types in the sense
   of CSS Values and Units Module. The definitions of data types in CSS
   Values and Units Module gets enhanced as follows:

s/consists/consist/
s/gets/are/


In 7.2.3.1. The <translation-value> and <length> type:

   A translation-value or length can be a <number> without an unit
   identifier. In this case the number gets interpreted as "user unit".
   A user unit in the the initial coordinate system is equivalenced to
   the parent environment's notion of a pixel unit.

s/equivalenced/equivalent/


In 7.2.3.3. The <number> type:

   SVG supports scientific notations for numbers.  Therefore a number
   gets parsed like described in SVG Basic data types for SVG attributes.


In 7.3. The SVG ‘gradientTransform’ and ‘patternTransform’ attributes:

   SVG specifies the attributes ‘gradientTransform’ and
   ‘patternTransform’. This specification makes both attributes to
   presentation attributes. Both attributes use the same syntax as the
   SVG ‘transform’ attribute. This specification won't introduce
   corresponding CSS style properties. Instead the style can be set by
   the ‘transform’ style property.

s/to presentation attributes/presentation attributes/
s/won't/does not/

I think the last sentence could more directly state that 
gradientTransform and patternTransform are presentation attributes for 
the transform property.


In 7.4. SVG transformation functions:

   For backward compatibility to existing SVG content, this
   specification must support all transform functions defined by The
   ‘transform’ attribute in SVG 1.1. Therefore the two-dimensional
   transform function ‘rotate(<angle>)’ gets extended as follows:

s/backward compatibility to/backwards compatibility with/
s/must support/supports/ (otherwise it sounds like a conformance 
requirement)
s/gets/is/


In 7.5. SVG and 3D transformation functions

   This specification explicitly allows to apply three-dimensional
   transform functions to the container elements: ‘a’, ‘g’, ‘svg’, all
   graphics elements, all graphics referencing elements and the SVG
   ‘foreignObject’ element.

s/allows to apply three-dimensional transform functions/requires 
three-dimensional transform functions to apply/

The way the colon is used in the sentence makes it seem like graphics 
elements are container elements.


In 7.6. Object bounding box units

   Percentage or fractional values in SVG are either relative to the
   elements viewport units or to the elements object bounding box units
   like specified in SVG 1.1.

s/elements/element's/g
s/like/as/

   If an SVG element does not provide an object bounding box (like for
   the ‘pattern’, ‘mask’ or ‘clipPath’ elements), the bounding box is
   the same like if the position x, y and the dimensions width and
   height are zero. Percentage values or keywords won't affect the
   rendering and are treated as if zero was specified.

s/the same like/treated as/

   A SVG ‘pattern’ element doesn't have an object bounding box.

s/A/An/

I think the terminology here is slightly off -- elements can have 
bounding boxes or not.  "Object bounding box" is the name of the mode 
for which percentages and unitless values are resolved against the 
bounding box of the referencing element.

   The translation on the ‘transform’ property is in absolute
   coordinates and translate the coordinate system by 50 pixel in each
   direction.

s/pixel/pixels/


In 7.7. SVG DOM interface for the ‘transform’ attribute:

   The SVG specification defines the ‘SVGAnimatedTransformList’
   interface in SVG DOM to access the animated and the base value of the
   SVG transform attribute.

s/in SVG DOM/in the SVG DOM/
s/access/provide access to/
s/transform attribute/transform, gradientTransform and patternTransform 
attributes/

   To provide the necessary backward compatibility to SVG DOM, ‘baseVal’
   must reflect the values of this author style sheet. All
   modifications to SVG DOM objects of ‘baseVal’ must affect this author
   style sheet immediately.

s/backward compatibility to SVG DOM/backwards compatibility to the SVG DOM/


In 7.8. SVG Animation:

   The SVG 1.1 specification did not define animations of the
   ‘transform’ attribute for the SVG ‘animate’ element or the SVG ‘set’
   element.

s/define/allow/
s/for/using/


In 7.8.3. The SVG ‘attributeType’ attribute:

   However, in the combination with the ‘transform’, ‘patternTransform’
   and ‘gradientTransform’ presentation attributes, ‘attributeType’ can
   just be used to indicate the syntax rules used for the transform
   attribute values.

s/in the/in/

Received on Wednesday, 14 March 2012 00:02:05 UTC