Re: 2D Transforms Update - 14 Oct 2010

Anthony Grasso:
> Hi FX-TF,

Meanwhile - can you add a date to such an editor draft
and if it exists a link to the previous one?
(There are already empty lines with 'This version:  Latest version: ')
This might help to compare and to indicate readers
on the mailing list, about which version an email is about,
even in the future ;o)
...

>- [SMFR_1] Added value of "none" to transform functions. Changed initial 
>value of transform from "identity" to "none".

I think, in current CSS drafts the value 'inherit' is not explictly mentioned
anymore, in SVG recommendations it is for properties.
Because transform in SVG was only an attribute, 'inherit' would
be a new value for the property as well. To note or not to note,
could be a question here ...

>
> - [DOH_1] Added wording to address backwards incompatibilities (rotate,
> origin on which transform is applied). Dr. Hoffmann to review (if he has
> time).

Hmm, the previous version as well as the CSS 2D draft has no cx, cy,
therefore it is more a question to the CSS experts, whether these
addtional values are ok or not and how they influence for example
the decomposition/animation variant of CSS.

I think, my issues concerning this are still on the to-do-list below ;o)

From the SVG point of view identity, translateX, translateY, scaleX and scaleY
are new as well, but for backwards compatibility for authors it is
simple to handle them - simply do not use them at all.
Currently missing are the constrained transformations from SVGT1.2,
if it is the intention, that this FX draft should be the superset of all
SVG and CSS transforms - should it?

...

>
> One thing I think that is fixed now is:
> - [DOH_1] Address if 'transform-origin' property has any influence on old
> SVG transform attribute. 

Because the relation between the property and the attribute is on the
to-do-list, obviously this is not the case here...


> If I can get a response specifically on this point 
> from Dr. Hoffmann that would be great. Any suggested wording for this would
> also be a big help.

(It is contained in the section 'The 'transform-origin' property' - right?
Or did I miss something?)

At least I think I understand, what influence the transform-origin property
has on transforms resulting from a transform property with the description.
I think, I got this before, but anyway this is good for understandability for
any reader.

If we assume that as I proposed the transform property results in an
additional transformation to that of the attribute, my assumption is, that
the transform-origin property effect has only influence on the additional
property transformation effect and not on the attribute transformation
effect. If there is alternatively only a (non-additive?) cascade of 
priorities of attribute and property transformation (the attributes are
always treated as presentation attributes with low CSS priority), 
my assumption is, that a possible presentation attribute transform-origin 
has influence on a possible presentation attribute transformation as well 
as on the property transformation. But if transform-origin is noted as 
property, it does  not apply to attribute transformations, only on the
property transformation. But other definitions are possible as well.
All depends on the related open issues of the to-do-list.
This can be a construct with good backwards compatibilities, but
much more complex or more simple and 'disburdened' form history and
current use of the attribute.

By the way - is 'Inherited:	no' really the behaviour, authors will
typically need for transform-origin? They still can write 
'transform-origin: inherit' for all elements they need with this
behaviour or adding a class with this value. What is less 
annoying for the majority of authors a) in CSS+(X)HTML and
b) in SVG? 

>
>
> On my TODO list (still) is:
> - IDL. We need to discuss the interface at the next telcon. CSS defines
> CSSMatrix and SVG defines SVGMatrix. Should they be merged into... Matrix?
> This may have backwards compatibility problems then. Could CSSMatrix and
> SVGMatrix be aliases to the same thing?
>
> - Fix syntax in SVG examples to match actual output result
>
> - [DOH_1] Address if the properties are independent of transform attribute
> used in SVG (1.1, 1.2)
>
> - [DOH_1] Address if the transform properties are available as presentation
> attributes
>
> - [DOH_1] Address how to determine the difference between original SVG
> attribute and new presentation attribute (example)
>
> - [SMFR_1] Add "How to read" section to say whether this, or the CSS 2D
> transforms spec is the canonical reference for CSS Transforms. The role of
> the two specs is not really clear.

- Example X - I think the CSS community insists on having unit identifiers
within the property notation for the CSS+(X)HTML case, fix
style="transform:translate(100,100)"
and 
style="transform:rotate(45)"

And fix the SVG sample related to the new default value of transform-origin -
respectively take into account, that this has no effect on already
existing SVG transform attribute - or whatever applies.

And for an example for 'rotation clockwise about the Z axis' it is obviously
better to use an object without symmetry axis beeing related to the used
rotation value ;o) 
Better would be for example some not completely trivial text or two not
centered rectangles or something without symmetry.
(The same applies for example VII)

- related: note together with the attribute/property/backwards compatibility
issues something about the differences about the requirement of unit
identifiers in CSS and SVG notation or link to related sections of 
recommendations.

Olaf

Received on Thursday, 14 October 2010 11:17:24 UTC