Re: [css3-transforms] 2D Transform Function rotate

Aryeh Gregor:

>
> It's supported for SVG for backward compatibility.

Basically it is used in SVG, because it is quite useful and simple, 
not just for historical reasons ;o)

> There was 
> opposition to adding support for it to the CSS version of transforms
> on grounds of consistency, and confusion with rotate3d() (which takes
> length parameters that means something totally different).  See
> discussion:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15508
> http://lists.w3.org/Archives/Public/www-style/2012Feb/0647.html

Because 'rotate3d' is clearly another list of characters than 'rotate'
I cannot see much risk of mistake, especially not more than
for rotate with only one parameter.
To increase consistency and to avoid confusion, obviously 
CSS transform for other formats than SVG should have three
parameters as well. Sometimes three and sometimes one mainly 
increases inconsistency and confusion.

Looks more like an attempt to increase the barrier for authors to
use CSS transforms in a way as already known from SVG.
Mainly as for some other features, it is a surprise, why this draft
introduces intentionally these incompatibilities to already existing
and oft used recommendations - just to annoy/frustrate authors and
to force them to learn different things just for no real reason?
The newly introduced incompatibility just increases the implementation
difficulties, because one may distinguish between CSS transforms
for SVG and CSS transforms for other stuff. Even worse, because it
is noted only, that 'User agents are just required to support the two 
optional arguments for translation on elements in the SVG namespace.'
Authors cannot even rely on a behaviour of a specific viewer - for
some, who do not want to distinguish it may work, for others not.
Many/most/all authors don't test their documents with all versions of
all viewers, with the result, that the presentation will fail for those
viewers, that decide to distinguish - if someone informs such authors
about the problem, some will only add notes like 'Best viewed with
browser X! Browser Y is evil, don't use it!' - is this really intended?


I still suggest to add it again, because it is useful and often used, 
authors can reuse code from SVG without a change for other formats
as well.
It is simpler for authors not very familar with matrices and coordinate
system changes.
It is less confusing and results in better compatibility between 
CSS transforms for SVG and CSS transforms for other formats...

If you like, you can register this as an opposition against unnecessary
incompatibilities between SVG and the CSS transform draft,
if you registered other replies already, that like to introduce more 
incompatibilities. If there is a big opposition against compatibility
with SVG, maybe it is better to separate the drafts again?
If it is intended to differentiate, why an attempt to specify it for both
in one draft at all?

Olaf

Received on Wednesday, 25 April 2012 12:21:37 UTC