[css-transforms] Named rotation axis

[Crissov]

https://drafts.csswg.org/css-transforms-2/#individual-transforms

rotate: none | <number>{3}? <angle>

The default values for the numbers are 0 0 1 to get a planar 2D transform. I believe it would be cleaner and perhaps more readable if the axes had keywords: either x, y and z or horizontal, vertical and ?.

I’m less sure whether translate should also support positional keywords like top, right, bottom, left, center, start, end. That would make this property even more similar to position: relative etc.

I understand that the three properties are named to match the functions in transform inherited. Consistency with those is probably more important than keeping with the general nomenclature used in CSS which prefers nouns over verbs for property names (i.e. rotation etc.).

[Nadya678]

Is it not intuitive the three numbers are x y z?

rotation istead rotate - yes. Here shall be noun (property name). Also (probably) translation instead translate etc.

[AmeliaBR]

I agree that named axes would be preferable to the vector format for most simple cases. I would recommend using the x/y/z naming, because it is short and because it is consistent with the rotateX, rotateY, and rotateZ functions.

I think it would also be helpful to distinguish between a 3D rotation around the Z axis and a 2D rotation in the plane. If you're already in 3D transformation mode, the effects are identical, but 2D versus 3D transformations have different effects in browser/GPU implementations, and in the parts of the spec that relate to SVG.

In other words, my ideal syntax would be something like:

rotate: none | [ 2d | x | y | z | <number>{3} ]? <angle> 

with 2d as the default if an axis is not specified.

(Also, I'm not sure on how to write the grammar, but the order of angle and axis parameters should be interchangeable, assuming we aren't allowing unitless 0 for angles.)

[ewilligers]

To make the order interchangeable, use &&. Amelia's suggestion becomes

rotate: none | [ 2d | x | y | z | <number>{3} ]? && <angle> 

[Crissov]

2d would be parsed as a value with unknown unit, no? Perhaps xy instead, or planar.

[dbaron]

I think if we're not happy with the suggestions for the syntax of the 2d vs z distinction that @AmeliaBR proposes, I think it's reasonable to not make that distinction -- and just say that if the author wants to force the transform to be 3-D rather than 2-D, they're going to have to do it some other way. (And given the proposals so far, that would be my inclination, but I'm open to seeing something better.

I don't like 2d since it's a dimension rather than a keyword (does 2.0d or 2e0d also work?), xy since it's the opposite of the other meanings (the plane rather than the axis perpendicular to it) and doesn't indicate at all which would be the 2-D or the 3-D version, and I also don't think planar is particularly clear about what the distinction between the values is.

Though another option is for the 2-D version to be what you get if you omit the axis/vector, and the 3-D version to be what you get if you include it.)

[AmeliaBR]

@Crissov Ugh, good point. 2d is out.

I like the idea to make it that a specified axis means 3d mode, while the default (no axis specified) is 2d mode.

If people want a keyword for 2d mode, flat might work. Or two-d. But from an authoring perspective, I think that if you're only working with 2d transformations, you'd probably want to leave it out altogether, and just do rotate: 90deg.

[tabatkins]

Though another option is for the 2-D version to be what you get if you omit the axis/vector, and the 3-D version to be what you get if you include it.

That's what happens today, so yeah. I do generally like the omitted value to default to some specific value (not be a distinct behavior in its own right), but if we can't come up with a good answer for what to call it, I'm fine with just leaving it out for now. We can always add a keyword for it later.

(I agree that 2d is the best value, and also that it's impossible to use due to parsing concerns. Clearly the right answer is to use d2 ^_^)

[css-meeting-bot]

The Working Group just discussed [css-transforms] Named rotation axis.

The full IRC log of that discussion

<dael> Topic: [css-transforms] Named rotation axis
<dael> github: https://github.com//issues/2130
<ericwilligers> https://github.com//issues/2130 https://github.com//issues/1269 Current spec: rotate: none | <number>{3}? <angle> https://drafts.csswg.org/css-transforms-2/#individual-transforms Suggestion by Amelia: rotate: none | [ 2d | x | y | z | <number>{3} ]? && <angle> Suggestion by Eric in #1269: none | <angle> && [ axis(<number>{3}) ]?
<dael> ericwilligers: The first two issues [missed]

[css-meeting-bot]

The Working Group just discussed [css-transforms] Named rotation axis, and agreed to the following resolutions:

• RESOLVED: grammar is rotate: none | [ x | y | z | <number>{3} ]? && <angle>
• RESOLVED: specifying just an angle gives 2d, specifying any axis gives 3d

The full IRC log of that discussion

<dael> Topic: [css-transforms] Named rotation axis
<dbaron> fremy, btw, if you want to retract something you wrote in a github issue, using the "Edit" feature to do something like https://github.com/w3ctag/design-reviews/issues/186#issuecomment-362025614 is helpful. (It's good to leave the original there for context, though, like annevk did there.)
<ericwilligers> https://github.com//issues/2130
<dael> github: https://github.com//issues/2130
<ericwilligers> Current spec: rotate: none | <number>{3}? <angle>
<dael> ericwilligers: Current spec and suggestions
<ericwilligers> Suggestion by Amelia: rotate: none | [ 2d | x | y | z | <number>{3} ]? && <angle>
<dael> (in IRC)
<ericwilligers> Suggestion by Eric in #1269: none | <angle> && [ axis(<number>{3}) ]?
<fremy> dbaron: good idea
<dbaron> s/dbaron:/dbaron,/
<dael> AmeliaBR: For most people the vector notation is more complicated and all the shorthands have rotate-x,y,z. We do have discussed in the issue my suggested keyword of 2d doesn't parse as a keyword which is an issue.
<dael> AmeliaBR: Reason we have a sep. keyword is we need to distinguish between 2d and 3d transforma round z axis which is sim math, but different in impl
<dael> ericwilligers: The difference could be if you spec the axes.
<dael> AmeliaBR: Yeah, that was one suggestion. We dont' worry about a keyword for 2d and if you don't spec axis it's 2d.
<fantasai> +1 to Amelia's suggestion
<dael> TabAtkins: I hadn't thought about the roate functions having -x,y,z and I support allowing you to set those instead of remembering the correct set up.
<TabAtkins> rotate: <angle> && [ x | y | z | <number>{3} ]?
<dael> AmeliaBR: Question is if we have those keywords is the unwrapped 3 numbers still acceptable or do people like function notation?
<dbaron> s/-x,y,z/rotateX,rotateY,rotateZ/
<dael> fantasai: I'm opposed to it since we haven't used it in similar situations like backgrounds. If we want longhands at some point that makes it more difficult. Syntax as is is fine. I don't know why peoplewould want angle in the middle.
<dael> TabAtkins: And rotate 3d takes an angle and 3 numebrs so it's the same syntax.
<dael> Rossen_: We have a couple of people opposed to functional notation.
<dael> Rossen_: Does that mean we want to go with first proposal?
<dbaron> s/opposed to it/opposed to function/
<ericwilligers> rotate: none | <angle> && [ x | y | z | <number>{3} ]?
<AmeliaBR> rotate: none | [ x | y | z | <number>{3} ]? && <angle>
<dael> ericwilligers: You can use x y z, have 3 numbers, or leave them out. And angle before or after axes.
<dael> TabAtkins: Yeah. I'm not sure why grammar has 3 numbers before, but that was probably an accident.
<dael> smfr: Are unitless 0s allowed?
<dael> ericwilligers: Not allowed.
<dbaron> s/0s allowed/0s allowed for the angle/
<dael> TabAtkins: Right. They're legacy feature you have to opt into and we don't allow in new.
<dael> AmeliaBR: Final question. Even though we're allowing botht o spec in either order do we want to stick with angle and then axis to match transform?
<dael> dbaron: I think in rotate 3d the angle is at end.
<dael> TabAtkins: Oh. I think the order in the grammar matches order serialized so we should have axis first to match rotate 3d.
<dael> Rossen_: Current proposal is match rotate 3d syntax?
<AmeliaBR> https://drafts.csswg.org/css-transforms-2/#funcdef-rotate3d
<dael> TabAtkins: No. We should have the axis come first.
<dael> AmeliaBR: It's this one rotate: none | [ x | y | z | <number>{3} ]? && <angle>
<dael> Rossen_: Any objections?
<dbaron> AmeliaBR: ... for the serialization order
<dael> Rossen_: fantasai you're confused.
<dael> fantasai: We're deciding to not match tranform ordering?
<dael> TabAtkins: The roate 3d takes axis first.
<dael> fantasai: Okay, sure. As long as trying to match.
<dbaron> s/roate 3d/rotate3d()/
<ericwilligers> We can close https://github.com//issues/1269
<dael> ericwilligers: I think we can also close this issue ^
<dael> RESOLVED: grammar is rotate: none | [ x | y | z | <number>{3} ]? && <angle>
<dael> smfr: Which combo of axis numbers trigger 3d behavior?
<dael> TabAtkins: All
<dael> AmeliaBR: Any axis triggers 3d
<dael> smfr: Okay.
<dael> TabAtkins: If you do jsut an angle it's 2d.
<dael> smfr: That's fine as long as it's in the spec.
<dbaron> RESOLVED: specifying just an angle gives 2d, specifying any axis gives 3d

[Crissov]

Do people want to rotate around a 2D coordinate other than 0 0 1? New issue?

[AmeliaBR]

@Crissov The rotation is always around the transform-origin point.