Re: review comments for SVG-related parts of css3-transforms from Dirk Schulze on 2012-03-14 (www-svg@w3.org from March 2012)

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 13 Mar 2012 23:01:02 -0700
To: Cameron McCormack <cam@mcc.id.au>
CC: SVG public list <www-svg@w3.org>
Message-ID: <B6F636DD-ECE9-41F8-8ED4-C8AF5ED3E2E1@adobe.com>

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:

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

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

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/

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:

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:

s/in the/in/

Received on Wednesday, 14 March 2012 06:01:48 UTC