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

On Apr 25, 2012, at 5:21 AM, Dr. Olaf Hoffmann wrote:

> 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?
Well, the specification says:

"User agents are just required to support the two optional arguments for translation on elements in the SVG namespace."

That means it is not restricted to SVG. In fact, once a implementation supports rotate with 3 arguments, I don't see a reason not to support it for HTML as well. And it is also quite difficult to differ between an HTML element and SVG element for a style declaration.

The concerns on rotate with 3 arguments were that it a) might be confusing because of 3d (I don't agree) b) are not implemented by any browsers. Most people didn't want to introduce a new function that is not supported by any browser at this point of time.

Dirk


> 
> 
> 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 13:16:16 UTC