Re: [CSS-transforms] rotate(<angle>[, <translation-value>, <translation-value>])

On Wed, Feb 15, 2012 at 2:43 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2012-02-15 12:27 -0800, Dirk Schulze wrote:
> > I tried to describe the benefits for CSS[2] but more necessary the
> > requirements for SVG [3]. This is the last blocking issue for
> > compliance between CSS Transforms and SVG Transforms for
> > transformation functions. That is the reason why I think it is
> > necessary to leave it in. Like I wrote before, it doesn't break
> > existing content. These are just two more optional arguments, and
> > it is easy to implement. It is already done for the SVG
> > implementation on all browser anyway. So SVG authors would expect
> > that it works on CSS as well, beside that if it is not supported
> > we would break existing SVG content. And for SVG a rotate with
> > three arguments is used a lot!
>
> My main concern here is that adding additional requirements on
> implementations might add additional barriers to unprefixing.
>
> In particular, the working group this morning did not achieve
> consensus on the idea that we might make any exceptions to the rules
> on dropping prefixes.  This means that we have to follow the rules
> stated in http://www.w3.org/TR/2011/NOTE-css-2010-20110512/#testing
> (that's the current version of http://www.w3.org/TR/CSS/#testing ):
>
>  # To establish and maintain the interoperability of CSS across
>  # implementations, the CSS Working Group requests that
>  # non-experimental CSS renderers submit an implementation report
>  # (and, if necessary, the testcases used for that implementation
>  # report) to the W3C before releasing an unprefixed implementation
>  # of any CSS features. Testcases submitted to W3C are subject to
>  # review and correction by the CSS Working Group.
>
> While this doesn't explicitly say anything about whether the
> implementation is required to *pass* the tests per that
> implementation report, I suspect it might be interpreted that way.
> (It's a new requirement since the last unprefixing has happened.)
>
> So from a spec advancement perspective I'd be ok with this change
> only if either (1) the spec explicitly says that implementations are
> not required to support the additional 2 arguments in order to
> unprefix their implementations of the transform property (though
> they'd still be required to do so to fully conform to the
> specification) or (2) /TR/CSS/ is clarified in such a way that this
> isn't an issue.
>

You almost need a lawyer to parse that quote :-)
I read it that you can implement part of the spec that you consider to be
stable:

implementors should release an unprefixed implementation of *any* CR-level
feature they can demonstrate to be correctly implemented according to spec

So, you can unprefix your current implementation (with the fix that removes
units for the matrix operator) when the spec goes CR.
Your report for the CSS group could cover the features that are not
implemented yet. You don't have to do everything.

The good thing is that this isn't going to break anyone since there is no
prefixed code that is using Dirk's proposed additions yet.

Rik


>
> That said, I also find the additional parameters confusing, but I
> suppose if SVG has them we're probably stuck with them, and I don't
> plan to object on those grounds since I'm not particularly an expert
> in the area.  (I'd note, however, that they're not at all analogous
> to the extra parameters to rotate3d(), which describe what axis to
> rotate about, not where the center of the rotation is.)
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>