This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15508 - Support rotate(<angle>[, <length>, <length>])
Summary: Support rotate(<angle>[, <length>, <length>])
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: Transforms (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dirk Schulze
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-10 19:30 UTC by Dirk Schulze
Modified: 2012-02-26 15:02 UTC (History)
10 users (show)

See Also:


Attachments

Description Dirk Schulze 2012-01-10 19:30:03 UTC
SVG Transforms specifies a rotate with an optional rotate origin. CSS Transforms should do this as well.

Note: SVG specifies it as: rotate(<rotate-angle> [<cx> <cy>]). <rotate-angle>, <cx> and <cy> are unit less. This could be solved by bug 15503. Existing content would still work with the CSS parser.

See also:
http://www.w3.org/TR/SVG/coords.html#TransformAttribute
Comment 1 Aryeh Gregor 2012-01-23 16:53:03 UTC
This seems like it would be confusing, because it would look a lot like rotate3d(), but the meaning of the <length>s would be different.  Also, in CSS Transforms you can do this with transform-origin, which doesn't exist (AFAICT) in SVG Transforms.
Comment 2 Dirk Schulze 2012-01-23 16:56:25 UTC
(In reply to comment #1)
> This seems like it would be confusing, because it would look a lot like
> rotate3d(), but the meaning of the <length>s would be different.  Also, in CSS
> Transforms you can do this with transform-origin, which doesn't exist (AFAICT)
> in SVG Transforms.

Yes, I also recognized this problem. We either would need to change the grammar for rotate3d() or would have to live with the potential of confusion. I would choose the first option.
Comment 3 Aryeh Gregor 2012-01-23 17:03:30 UTC
What would you change rotate3d() to?
Comment 4 Dirk Schulze 2012-02-10 16:29:08 UTC
I didn't changed rotate3d, since it is another use case (vector for aches of rotation to translated origin).

I modified rotate as follows:

"rotate(<angle>[, <translation-value>, <translation-value>])
specifies a 2D rotation by the angle specified in the parameter about the origin of the element, as defined by the transform-origin property, or a given point as to the origin of the element. For example, rotate(90deg) would cause elements to appear rotated one-quarter of a turn in the clockwise direction. With rotate(90deg, 100px, 100px) the element appears rotated after a translation of 100px in the vertical and horizontal direction. The actual origin of the element is not affected."

Changed with commit on 2012/02/10.
Comment 5 Aryeh Gregor 2012-02-10 16:39:38 UTC
This is inconsistent with all other functions in CSS transforms, none of which take an origin argument; and redundant with transform-origin.  It's also confusing because it looks similar to the first three arguments of rotate3d(), but means something totally different -- as evidenced by <http://lists.w3.org/Archives/Public/www-style/2012Feb/0488.html>, which was sent to www-style immediately after the change.

I think it should be removed again.  Internal consistency within CSS is much more important than consistency with SVG.  If you disagree, I suggest we ask implementers what they want to implement.
Comment 6 Dirk Schulze 2012-02-10 16:43:08 UTC
(In reply to comment #5)
> This is inconsistent with all other functions in CSS transforms, none of which
> take an origin argument; and redundant with transform-origin.  It's also
> confusing because it looks similar to the first three arguments of rotate3d(),
> but means something totally different -- as evidenced by
> <http://lists.w3.org/Archives/Public/www-style/2012Feb/0488.html>, which was
> sent to www-style immediately after the change.
> 
> I think it should be removed again.  Internal consistency within CSS is much
> more important than consistency with SVG.  If you disagree, I suggest we ask
> implementers what they want to implement.

Yes, I absolutely disagree. I even believe that this is one of the most important changes to be interoperable with SVG Transforms. And I don't see the conflict if rotate and rotate3d have different use cases.
Comment 7 Aryeh Gregor 2012-02-10 16:48:30 UTC
Are Microsoft, Mozilla, or Apple interested in implemented the proposed extension to rotate() to bring it in line with SVG?
Comment 8 Aryeh Gregor 2012-02-10 16:55:35 UTC
(To clarify: by Apple I mean WebKit.  If you're speaking for WebKit, that's one implementer on board.  If neither Microsoft nor Mozilla is interested, though, I really think it needs to be dropped from the spec regardless of what WebKit wants.)
Comment 9 Dirk Schulze 2012-02-10 16:58:29 UTC
(In reply to comment #8)
> (To clarify: by Apple I mean WebKit.  If you're speaking for WebKit, that's one
> implementer on board.  If neither Microsoft nor Mozilla is interested, though,
> I really think it needs to be dropped from the spec regardless of what WebKit
> wants.)

Hehe, when at all than I am speaking for Adobe, not for Apple, not for Google and definitely not for WebKit as a whole.
Comment 10 Aryeh Gregor 2012-02-10 17:10:36 UTC
Then I'd like to hear from whoever would make such a decision for WebKit.  The spec needs to match implementations.

I think our disagreement here is mostly because you have a strong background in SVG, so you think CSS should change to match SVG.  I have basically no background in SVG (is it <circle> or <circ>?  I always think <circ>, <rect> confuses me), so changing CSS to match SVG doesn't make sense to me.  I think the vast majority of web authors know CSS far better than SVG, and will use CSS rather than SVG, so making CSS more complicated to match SVG is a losing proposition.  If they use SVG at all it will be via Inkscape or such, even the ones who would hand-author HTML and CSS sometimes.

So I really think we shouldn't be making any change to CSS solely to bring it in line with SVG -- only changes that would be reasonable to make even if not for SVG.  I don't think it's contested that this change would not be a good one if not for SVG; I think we only disagree on the value of aligning with SVG.
Comment 11 Dirk Schulze 2012-02-10 17:26:06 UTC
(In reply to comment #10)
> Then I'd like to hear from whoever would make such a decision for WebKit.  The
> spec needs to match implementations.
> 
> I think our disagreement here is mostly because you have a strong background in
> SVG, so you think CSS should change to match SVG.  I have basically no
> background in SVG (is it <circle> or <circ>?  I always think <circ>, <rect>
> confuses me), so changing CSS to match SVG doesn't make sense to me.  I think
> the vast majority of web authors know CSS far better than SVG, and will use CSS
> rather than SVG, so making CSS more complicated to match SVG is a losing
> proposition.  If they use SVG at all it will be via Inkscape or such, even the
> ones who would hand-author HTML and CSS sometimes.
> 
> So I really think we shouldn't be making any change to CSS solely to bring it
> in line with SVG -- only changes that would be reasonable to make even if not
> for SVG.  I don't think it's contested that this change would not be a good one
> if not for SVG; I think we only disagree on the value of aligning with SVG.

This is the merged transformation specification for CSS / HTML as well as CSS / SVG. Of course it makes sense to align some functionality with SVG. I already try to limit changes to CSS 2D Transforms as much as possible, but a SVG author shouldn't have big problems to use CSS Transforms, when he only used SVG Transforms before.

The argument that no one would use SVG, or at least not create them their self is not valid. At first there is a lot more SVG content with transforms out there than webpages with CSS Transforms. Even Wikipedia uses thousands of SVGs. So breaking backward compatibility just because current CSS parser don't support a certain feature is not a possibility at all. Second, you can not make assumptions from your own point of view. A lot of news papers (like the wall street journal) use SVG, now that IE supports it as well.

Also who says that specifications must match current implementations? If so, why do we have HTML5 or CSS3? It is more the case that we do both: specifying current behavior and adding new features to the specification that are not implemented yet. As a reminder: In the past the W3C created the spec first and implementation arrived later. So the current concept is a lot better.

To rotate: adding new arguments won't break existing content! They give authors an easy way to rotate around a certain point without dealing of translations and calculating the translation back to the original origin. I think that this is a great advantage for authors! And that is why it makes sense to implement it beside backward compatibility to SVG.
Comment 12 Aryeh Gregor 2012-02-13 15:06:08 UTC
I'd like to get other people's input on this, since I don't think we're going to agree.  I'll point out, though, that the specification *does* have to match implementations.  It doesn't necessarily have to match *current* implementations, but it has to *eventually* match implementations.  If any major implementers say they're not willing to implement a specific feature, we need to drop it so that the spec remains in sync with implementations in the long term.  This has happened plenty in HTML5 -- e.g., requiring Theora/Vorbis support (nixed by MS/Apple), or WebSQL (nixed by Mozilla).

I filed a Gecko bug to gauge support for the extra arguments: https://bugzilla.mozilla.org/show_bug.cgi?id=726583
Comment 13 Dirk Schulze 2012-02-13 16:43:59 UTC
(In reply to comment #12)
> I'd like to get other people's input on this, since I don't think we're going
> to agree.  I'll point out, though, that the specification *does* have to match
> implementations.  It doesn't necessarily have to match *current*
> implementations, but it has to *eventually* match implementations.  If any
> major implementers say they're not willing to implement a specific feature, we
> need to drop it so that the spec remains in sync with implementations in the
> long term.  This has happened plenty in HTML5 -- e.g., requiring Theora/Vorbis
> support (nixed by MS/Apple), or WebSQL (nixed by Mozilla).
> 
> I filed a Gecko bug to gauge support for the extra arguments:
> https://bugzilla.mozilla.org/show_bug.cgi?id=726583

Ok, so I misunderstood your previous comment and you want to make sure that implementations are willing to support a certain feature, even if they don't support it now. That is absolutely fine for me.
Comment 14 Dirk Schulze 2012-02-18 23:12:03 UTC
"Maybe it should read:
specifies a 2D rotation by the angle specified in the parameter about the origin of the element, as defined by the transform-origin property. If the optional transform is specified, the transform origin is translated by that amount (using the current transformation matrix) for the duration of the rotate operation."

from Rik on www-style
Comment 15 Dirk Schulze 2012-02-26 15:02:31 UTC
Removed it from the general transformation function section and added it to SVG section.