Re: Fwd: Re: [css3-transforms] 7.2. Syntax of the SVG ‘transform’ attribute

Dirk Schulze:

...
>
> > Obviously this matters for SVG1.1 viewers, old or new.
> > In general this sections seems to be more related to CSS compatibility,
> > not to backwards compatibility to SVG 1.1, because it introduces new
> > syntax, not really needed for the SVG attribute.
>
> To be honest, I don't understand your arguments. Or maybe you didn't
> understand the sense of CSS Transforms? CSS Transforms is a joined
> specification between CSS 2D Transforms, CSS 3D Transforms and SVG
> Transforms. Of course SVG will be "compatible" to CSS Transforms, since
> transforms are specified within the CSS Transforms specification. And this
> joined specification brings a lot of benefits to SVG as well. But later
> more. It of course means that viewers need to update their support for
> transforms to support new features.
>
> > Why not so skip units completely for the attribute as it applies already
> > now? For example (X)HTML has no such unit letters 'px' as well - why to
> > care about it in SVG and not in (X)HTML, where it would be much more
> > useful than in SVG to have units like em, ex availlable, not just % and
> > implied px?
>
> X(HTML) transformed nearly all attributes to CSS properties. 

No not for tables for example, and units like em, ex could be useful of
course for (X)HTML without CSS, because the tables could render
faster together with elements colgroup and col - but without meanigful
units available in (X)HTML without CSS, of course, such elements are
not often used to improve the rendering. If you just have the improvement
with an external decorative stylesheet, this means not necessarily a fast
and optimised first rendering.

> That means it 
> is more X(HTML) which uses 'px', 'em', '%' and so on. 

No, it is the CSS decoration of (X)HTML, that might be available, if
authors provide it, nothing directly relevant for the primary presentation
of the content - for the already mentioned tables this difference may matter -
or if authors use no CSS at all.
Typically indeed for (X)HTML it does not matter much, that one cannot
size content effectively, without CSS viewers typically manage the
display/presentation pretty well.

> To be honest I don't 
> understand why you compare the remaining attributes with SVG? 

Because the remaining (X)HTML attributes matter for content, as these
do in SVG, therefore SVG has a lot of presentation attributes. Those
can be considered to be relevant to understand the content and are
not just decoration.

> If you want 
> to compare attributes with transforms, please use SVG attributes like 'x',
> 'y', 'width' and 'height' (just to name some). All these attributes use
> 'px', 'em', '%', even if the values are relative to the local coordinate
> space. So why shouldn't we support these units in 'transform'?

It depends on the version/flavour.
For SVG tiny only width and height of the root svg element may have
units, all other attributes not.
If a tiny viewer implementor wants to extent the viewer with this 
transform extension, this results in the problem, that he has to
implement all this units issues just for this attribute transform -
basically for nothing, because authors interested in creating
content for this viewer will presumably not use units anyway,
but the draft requires this and advises the authors to do so just
for this attribute. Those authors may come to the conclusion,
that this advice is not very clever and draw further conclusions
about the quality of the complete draft ;o)

For a full viewer indeed it should be no problem to add this unit
feature for this attribute as well, ok.
But an author might still follow the tiny idea to use no units for
the basic content and may add for example with an 
xml-stylesheet instruction alternatively styled variants for
advanced viewers.
Why to recommend/advise those authors to use units just for this
attribute?

Here the draft should be at least more neutral and should not
recommend to use units just for this attribute. Finally if the attribute
is extented with units as the property, it should be the free choice
of the author, without sugesstive or contraproductive hints within
the draft. If the author decides to use no units in the complete document,
this should be ok. If the author decides, that he has another solution
of the units problem for different viewers or knows, that it does not
matter, it is ok of course to use units, if this matters for the author.

The main thing, I do not like is, that currently the draft suggests,
that it is always a good or even recommended thing to use the
units, but typically we know of course, that often it is not a good
idea to use units at all within the content of SVG documents
apart from width and height of the root svg element.

By the way, I think already others indicated, that in case of
unit use, some matrix items need units as well, these are
e, f from matrix and the corresponding three items in matrix3d.
Else these items are not very helpful for authors, that decide
to use the units approach with other units than px/local unit. 

>
> > The syntax for the transform property in this draft  is not compatible
> > anyway with the SVG1.1 transform attribute and units not useful for the
> > attribute. Why to care, why to change this - just to please the CSS
> > working group with superflous unit-letters and to annoy authors and the
> > audience with failing documents, just because this new draft contains
> > misleading and manipulative hints for authors of SVG documents, far away
> > from best practice?
>
> Sadly you miss the greater scope of this. The SVG part is not only about
> supporting units in the 'transform' attribute. This is just a single part
> of this section. The 'transform' attribute turns into a presentation
> attribute!

I don't miss this, but as mentioned in the text, currently the syntax is not
completely the same. Obviously the CSS part obviously does not like
an additional white space and needs always a comma. Because the
CSS transform draft is much newer than the SVG recommendations,
this could have been avoided of course, independently from the units
question. But if there is a decision, to deviate from the SVG syntax,
there are incompatibilities between the attribute and the property
anyway introduced by this draft. The question whether units are
necessary for the attribute or not, is just another flavour.
Even with units the compatibility could have been much better
with a draft following more strictly the SVG recommendations.
If this is not going to happen, I think the question is ok as well,
why to try to introduce some degree of compatibility at all?
And why to do it in such a way, that the advice for authors 
causes problems for current SVG viewers?


>
> The benefits for authors:
> - Authors can set the transform with CSS as well.

Nice, in case they really want to provide alternative views
of the document - how often will this happen?
How often does this happen today with the option of SVG full
to provide additional style sheets for other properties?
But ok, if this is available for more features, it might become
more interesting for authors to provide alternative views of the
content. For (X)HTML content I do it for a long time ...

> - Authors can share transformation code across a document. You can use the
> same transform on HTML elements as well as SVG elements. - Authors can use
> 3D transforms on SVG as well.

This applies as well, if one allows unitless values as well and if one adjusts
the remaining restrictions of the draft to the current syntax of SVG, maybe
with an addition of optional units, because this is more useful for
(X)HTML+CSS than for SVG.

> - Authors don't need to learn two syntaxes for SVG and HTML.

They already have to learn different layout mechanisms.
Because there are still differences, obviously attribute and property
do not really share the same syntax in the current draft. 
And a huge amount of published SVG content uses already 
the SVG syntax - therefore one can assume, that many authors 
have to learn the new CSS syntax addtionally, if they want to 
apply transforms with CSS instead of reusing their SVG experience.
There is no way to avoid this, because the syntax of CSS documents
differs in general completely from XML element and attribute notations.

And of course, if authors need the tranformations for relevant SVG content,
they have to use the attribute notation anyway.

And I think, finally it is not a big issue to learn the CSS approach and the
SVG approach - typically you need already both types of similar syntax
anyway, if you write (X)HTML decorated with CSS.


> - Authors can use CSS Animations and CSS Transitions on SVG transforms.

Even this is simpler with better compatibility.
And due to the experience in different viewer of SMIL/SVG animation with
units, I assume animation is much simpler without units ;o)
And CSS animation has of course different use cases. 
CSS is not part of the primary content, therefore if it matters for 
understanding the content, authors of course have to use 
SMIL/SVG animation. CSS animation can be added of course for 
decoration or alternative views of the document. 
Already SMIL/SVG animations have this decorative
aspect for some features with attributeType="CSS" - of course
to have it for transforms as well in the future can be interesting -
but resulting in increasing complexity for rendering - and
typically current viewers do not even manage the complexity
of SVG with attributes, CSS styling properties, SMIL/SVG animation of
attributeType="CSS" and attributeType="XML" - adding
CSS animation will result in even more fun ;o)
Already only the combination of animateTransform and
animateMotion for one element turned out to become a
nightmare of inconsistencies and funny discussions ;o)

>
> The benefits for the WGs:
> - It allows the working groups to join forces and come up with a common
> transform spec, instead of developing two separate specifications.

Well, the SVG recommendations already exist for a long time,
could have saved a lot of time to align here the CSS attempts 
right from the start ;o)

>
> The benefits for UAs:
> - It allows implementations to reuse code internally.

This basically means, that you apply the currently mentioned exceptions
for the attribute to the property as well - the additional whitespace, no
comma separation, no units - then why to require these restrictions at all 
for the new property, if the code is intended to be reused anyway?
And the code for SVG typically already exists ...

> - Optimizations on CSS Transforms can be reused on SVG.
>
The other way around it applies as well ...


> > And of course, it is possible with advanced fallback mechanisms to
> > introduce new features in a backwards compatible way.
> > But if such a draft forces authors to use more complicated
> > new syntax for features, they can be already realised with simpler
> > old syntax, this undermines such a possible fallback mechanism -
>
> I disagree. The syntax difference on the 'transform' attribute is to make
> it possible to use the old SVG syntax as well as the new CSS syntax. So if
> you don't want to learn the CSS syntax, and if you don't need the
> capabilities of a presentation attribute, just don't use it. This section
> gives you the ability to make your own choices.

But it recommends to use new syntax.
Again, if the author has the choice, remove the suggestive parts of the
section, be neutral on this.
It is ok to extent the attribute to be able to use units, if the author wants
this, but do not force them to do so, because this can cause problems as well.

...
>
> I don't plan to add a comment that you should not use content that is newly
> specified. Why should I? 

Then remove the comment as well, that it is 'Authors are advised to follow the 
rules of CSS Values and Units Module.' - If the author has the free choice, 
the draft should/must/need not to advise anything of course. And 
[Therefore an author should write ‘transform="translate(200px, 200px)"’ 
instead of ‘transform="translate (200 200)"’ because the second example with 
the spaces before the ‘(’, the missing comma between the arguments and the 
values without the explicit unit notation would be valid for the attribute 
only.] 
is incomplete as well, because as already discussed, there are other issues to 
consider as well. In many cases it is much better to write in SVG documents 
transform="translate(200, 200)", why to conceal this, why to promote
only specific aspects of the problems, that may occur, why to be so biased
to one variant, if the use of the old or unitless syntax has arguments as
well? Either all aspects are mentioned or the draft should be calm about
the question, what authors should do or prefer, as long as they use
correct syntax for the attribute.

Olaf

Received on Monday, 23 April 2012 15:45:49 UTC