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

Dirk Schulze:

...
>
> Well, the specification says:
>
> "User agents are just required to support the two optional arguments for
> translation on elements in the SVG namespace."
>
Indeed, this is what I cited as well - if you have some browsers, that
interprete this and some not, of course you will have the consequence
for authors, that the complete feature is not reliable and some will
start to discriminate users with specific browsers, that have not
the capability they expect - we know this from other issues, not
only in CSS ;o) It is useless to explain them, that it is an optional
feature for other formats than SVG, their conclusion will be, that
the browser is useless/annoying due to bugs, whatever is noted
somewhere in a specification - what can authors do with 
optional features? - nothing!
Therefore one has to write simply:
'User agents are required to support all three arguments.'
to prevent such discussions and discriminations - at least, if a browser
ignores it, competent people can sent a bug report.


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

rotate3d has 4 arguments with a completely different meaning, rotate 1, 
respectively 3 - skip it, because it is still not the same?
Is the difference between 
<number>, <number>, <number>, <angle> on the one hand
and <angle> on the other less confusing than <angle>, <number>, <number>
or <angle>, <translation-value>, <translation-value>?
This looks like an pretextual argument that there is more confusion with
one variant than with the other - could be more clever to
define rotated3d(<angle>, <number>, <number>, <number>)
anyway for better consistency ...
The current variant for rotated3d looks like another attempt of intended
unnecessary complications for authors - rotate starts with an angle but
rotate3d with a direction - why? 
If there is anything confusing here at all, this is the most obvious issue 
here, not the number or meaning of arguments ;o)

matrix3d has more arguments as matrix as well - skip it for the same reason?
I think, this would be the same idea, but not a good one.

translate3d has 3 arguments, translate only 2 - skip this as well?
translateX, translateY, translateZ have only 1 argument, but sound very
similar - skip it!?

scale3d has 3 arguments, scale has 2 - skip it as well?
scaleX, scaleY, scaleZ have only one argument - confusing as well?

As we can see, with the same argument we can remove almost everything
either from 2D transform or 3D transform, if we assume any confusion
here resulting from similar names but different number or meaning of
arguments ;o)
Of course the different number and meaning of the parameters result
from different functionality, therefore '3d' is already added to clarify this.
Different name, different functionality. I think, everybody understands
this. If this is not the case, I think there is a low chance anyway that
such a person will manage to do anything useful with CSS transforms,
because it is far too complex for such a person. 

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

Concerning CSS transforms all of this is new - only the
SVG attribute can be considered as widely implemented
and recommended - everything else is discussable, because
it is new and not recommended and compared to the
SVG attribute not tested or used in normal documents
of authors.

And even on the experimental stage, already due to my
few tests, the complete 3D transform is not supported in
most browsers currently.
Due to my tests, the units to be usable according to
this draft are not completey usable in several browsers as well,
therefore we cannot assume, that any browser has implemented
this draft in a way, that authors can really use this as noted, maybe
a few parts of it in a very limited way - but no chance with
the complete set of features introduced here and with 
a larger amount of different browsers.

That things here do not really work for authors apart from
the SVG attribute yet, is surely no surprise and no problem 
as well, because this is only a few month old draft and no 
recommendation yet - there is no reason for any implementation 
at all for the CSS part of it - and nobody can expect, that there
are no changes anymore - it is the purpose of such draft
to discuss the usefulness of these things - and as it turns 
out already here, several things are not really thought through
and need improvements and additions - this draft is far from
usable now, but it is just an early draft, therefore no problem -
one simply can improve, what does not fit - not matter what
is already testable with specific experimental implementations -
it is the only purpose of such experimental implementations,
to see, what needs to be improved - and many things to
be improved can already be found without looking on any
implementation at all ;o)

Therefore still this applies:
>
> > 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 16:26:40 UTC