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

On Apr 21, 2012, at 8:37 AM, Dr. Olaf Hoffmann wrote:

> Dirk Schulze:
> 
>> 
>> This specification wants to provide backwards compatibility to SVG 1.1, not
>> to older viewers. If we consider that new content must work on older
>> Viewers, we can't include any new feature at all.
>> 
> 
> It is backwards compatibility to SVG 1.1, because this does only allow
> numbers without units, what is in general a good idea for SVG.
I don't disagree.

> 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. That means it is more X(HTML) which uses 'px', 'em', '%' and so on. To be honest I don't understand why you compare the remaining attributes with SVG? 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'?


> 
> 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!

The benefits for authors:
- Authors can set the transform with CSS as well.
- 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. 
- Authors don't need to learn two syntaxes for SVG and HTML.
- Authors can use CSS Animations and CSS Transitions on SVG transforms. 

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.

The benefits for UAs:
- It allows implementations to reuse code internally.
- Optimizations on CSS Transforms can be reused on SVG.

> 
> 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.

> therefore bad idea, change as suggested or better remove the
> entire unit thing from the section related to the attribute to avoid
> the complete problem.
Like I mentioned above, I don't see a reason why we should't allow units on basic transformation functions. We allow them on all attributes but not on transform. I see it as a great progression that we allow units on SVG. The SVG WG already agreed to this change. And again, it doesn't affect you, if you are not interested in the new features nor does it break old content.

> 
> Another option is of course to allow an incompatible unit extension,
> but to remove any suggestion to authors on the question of units,
> adding only a hint, that in previous SVG versions up to SVG 1.1.1 and
> SVG tiny 1.2 (this means currently all SVG versions) units are disallowed.
I don't plan to add a comment that you should not use content that is newly specified. Why should I? The sense is to support new features and of course you should be able to use them. Like for every specification, it takes some time before it is widely implemented.

Greetings,
Dirk

> 
> 
> Olaf
>

Received on Saturday, 21 April 2012 17:16:29 UTC