Re: review comments for SVG-related parts of css3-transforms

Note: This is the same mail as before. Hopefully the quotes are highlighted now.

Hi Cameron,

Thank you very much for taking the time, the detailed review and all the suggestions. I will comment inline.

For discussions of certain topics, please just comment to the part that needs to be discussed and change the subject of the email. That makes it hopefully easier to follow different discussions.


On Mar 13, 2012, at 5:01 PM, Cameron McCormack wrote:

> 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".
Can you point me to the section in the SVG specification? In general SVG attributes should be in the SVG namespace, no? The question is if presentation attributes do belong to 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.
That is not allowed according to the SVG parsing rules for the transform attribute: http://www.w3.org/TR/SVG/coords.html#TransformAttribute
and it is not allowed for the transform property according to CSS3 Transforms: "The individual transform functions are separated by whitespace"

But I tested it with the SVG attribute:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect transform="translate(100,100)rotate(45)" width="100" height="100"/>
</svg>

And it works for Firefox, WebKit and Opera.

I also tested the CSS property which worked as well. I will open a bug report to address both, Transformation Functions for the property as well as the attribute to fix that.

>
>
> 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?
The pattern and gradient elements don't support the 'transform' attribute yet. I am not aware of any future plans that will allow the transform attribute on these elements (at that with a different functionality).

>
>
> 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?
>
The rotate with 3 arguments is not supported by current implementations. For that reason the HTML part of the spec should not add new functionality or syntax changes at this point of time. This is the though of the CSS WG. However the rotate with three arguments must be supported for SVG elements for backwards compatibility. The compromise was, that the rotate with three arguments must be supported when implementations use CSS Transforms for SVG.

Your conclusion is correct. When viewers support it for SVG elements, they will also support it for HTML elements. The idea is to provide backwards compatibility not only for the syntax, but also for the SVG DOM which supports three arguments. If the style itself wouldn't support it, browsers would be forced to track the rotate with 3 arguments but use translate rotate translate in the background. So viewers would end up with two different transforms, one for SVG DOM with 3 arguments for rotate, and one for CSS where rotate3 gets replaced by three transform functions.

That said: If the rotate with three arguments will be supported for SVG elements, it will also work for HTML elements.

Like you said, it would also be possible to just allow rotate with three arguments on the presentation attribute. But viewers will need to deal with it internally if they want to provide backwards compatibility to the SVG DOM. If that is the preferred desire, I can change it to just support it for the presentation attribute.

>
> 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>
At first, the child would follow the rules again and and can't provide the transform with 3d argument. Second, this would be invalid according to the SVG specification. We have such tests in WebKit trunk. Viewers ignore these child elements for the actual mask. The same for other combinations of pattern, clipPath, mask, filter, linearGradient and radialGradient.

>
>
> 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 is defined by the current SVG spec and I linked to this part. A graphic might help to understand the context, but that is not in the scope of CSS3 Transforms and should be done in the SVG spec. But for now I can give you an unofficial link to a graphic: http://www.w3.org/Graphics/fx/wiki/SVG_attribute_to_presentation_attribute
The new created author style sheet is the presentation attribute style in the graphic.

>
>
>   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.
You are right. We can differ between two types

1) Not supported 2D transformation functions (translateX, translateY, scaleX, scaleY)
  We could easily return a SVGMatrix here. Returning translate or scale as function type would not be correct in my eyes, since it could conflict with the CSSOM objects that will (hopefully) added to CSS4 Transforms (http://www.w3.org/TR/css3-3d-transforms/#csstransformvalue-interface link will not be reachable soon). For these transformation functions we should return UNKNOWN as type.
2) 3D Transformation functions
  Not only that we don't support 3D Transformation functions in SVG DOM, they might also not be transformable to 3x2 matrices. But there are still excuses like rotateZ, translate3d where the third argument is zero and so on. The easiest way would be not to support them at all. Otherwise it needs to get specified what to do for every function.

One problem after reading the SVG spec again: SVG does not specify how SVGMatrix should look like for UNKNOWN transformation functions, correct? Should all values be zero? Should it be the identity matrix?

I'd like to let this part unspecified and recommend that future versions of the SVG spec should specify it.

>
>
> 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?
The wording 'presentation attribute style' is incorrect. It should be transform property.

>
>
> 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.
Reading this section again, it seems to specify more than it should. How 'attributeType' is treated should be described in detail for all presentation attributes and should be done with the new specification for SVG attributes and CSS animations. The current SVG Animation specification is not absolutely clear about that.

I will remove this section completely.

>
>
> 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.
What about:

"The attributes 'from', 'by' and 'to' of the 'animateTransform' element take the argument(s) to the functional notation. 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 whitespace characters.

The ‘values’ attribute for the ‘animateTransform’ element consists of a semicolon-separated list of values, where each individual value is expressed as described above for ‘from’, ‘by’ and ‘to’."


For consistency reasons the section "The SVG ‘animate’ and ‘set’ element" needs to be updated as well:

"The attribute 'to' of the 'animate' and 'set' elements as well as the attributes 'from' and 'by' of the 'animate' element take a list of transform functions.


The 'values' attribute for the 'animate' element consists of a semicolon-separated list of transform function lists."


Thanks you very much for finding the typos. I already created a patch but am waiting for authorization to commit to mercurial.

Greetings,
Dirk

>
>
>
> 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 14:14:14 UTC