Re: [csswg-drafts] [css-transforms] Named rotation axis

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-transforms] Named rotation axis<br>
&lt;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.)<br>
&lt;ericwilligers> https://github.com/w3c/csswg-drafts/issues/2130<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2130<br>
&lt;ericwilligers> Current spec: rotate: none | &lt;number>{3}? &lt;angle><br>
&lt;dael> ericwilligers: Current spec and suggestions<br>
&lt;ericwilligers> Suggestion by Amelia: rotate: none | [ 2d | x | y | z | &lt;number>{3} ]? &amp;&amp; &lt;angle><br>
&lt;dael> (in IRC)<br>
&lt;ericwilligers> Suggestion by Eric in #1269: none | &lt;angle> &amp;&amp; [ axis(&lt;number>{3}) ]?<br>
&lt;fremy> dbaron: good idea<br>
&lt;dbaron> s/dbaron:/dbaron,/<br>
&lt;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.<br>
&lt;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<br>
&lt;dael> ericwilligers: The difference could be if you spec the axes.<br>
&lt;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.<br>
&lt;fantasai> +1 to Amelia's suggestion<br>
&lt;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.<br>
&lt;TabAtkins> rotate: &lt;angle> &amp;&amp; [ x | y | z | &lt;number>{3} ]?<br>
&lt;dael> AmeliaBR: Question is if we have those keywords is the unwrapped 3 numbers still acceptable or do people like function notation?<br>
&lt;dbaron> s/-x,y,z/rotateX,rotateY,rotateZ/<br>
&lt;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.<br>
&lt;dael> TabAtkins: And rotate 3d takes an angle and 3 numebrs so it's the same syntax.<br>
&lt;dael> Rossen_: We have a couple of people opposed to functional notation.<br>
&lt;dael> Rossen_: Does that mean we want to go with first proposal?<br>
&lt;dbaron> s/opposed to it/opposed to function/<br>
&lt;ericwilligers> rotate: none | &lt;angle> &amp;&amp; [ x | y | z | &lt;number>{3} ]?<br>
&lt;AmeliaBR> rotate: none | [  x | y | z | &lt;number>{3} ]? &amp;&amp; &lt;angle><br>
&lt;dael> ericwilligers: You can use x y z, have 3 numbers, or leave them out. And angle before or after axes.<br>
&lt;dael> TabAtkins: Yeah. I'm not sure why grammar has 3 numbers before, but that was probably an accident.<br>
&lt;dael> smfr: Are unitless 0s allowed?<br>
&lt;dael> ericwilligers: Not allowed.<br>
&lt;dbaron> s/0s allowed/0s allowed for the angle/<br>
&lt;dael> TabAtkins: Right. They're legacy feature you have to opt into and we don't allow in new.<br>
&lt;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?<br>
&lt;dael> dbaron: I think in rotate 3d the angle is at end.<br>
&lt;dael> TabAtkins: Oh. I think the order in the grammar matches order serialized so we should have axis first to match rotate 3d.<br>
&lt;dael> Rossen_: Current proposal is match rotate 3d syntax?<br>
&lt;AmeliaBR> https://drafts.csswg.org/css-transforms-2/#funcdef-rotate3d<br>
&lt;dael> TabAtkins: No. We should have the axis come first.<br>
&lt;dael> AmeliaBR: It's this one rotate: none | [  x | y | z | &lt;number>{3} ]? &amp;&amp; &lt;angle><br>
&lt;dael> Rossen_: Any objections?<br>
&lt;dbaron> AmeliaBR: ... for the serialization order<br>
&lt;dael> Rossen_: fantasai you're confused.<br>
&lt;dael> fantasai: We're deciding to not match tranform ordering?<br>
&lt;dael> TabAtkins: The roate 3d takes axis first.<br>
&lt;dael> fantasai: Okay, sure. As long as trying to match.<br>
&lt;dbaron> s/roate 3d/rotate3d()/<br>
&lt;ericwilligers> We can close https://github.com/w3c/csswg-drafts/issues/1269<br>
&lt;dael> ericwilligers: I think we can also close this issue ^<br>
&lt;dael> RESOLVED: grammar is rotate: none | [  x | y | z | &lt;number>{3} ]? &amp;&amp; &lt;angle><br>
&lt;dael> smfr: Which combo of axis numbers trigger 3d behavior?<br>
&lt;dael> TabAtkins: All<br>
&lt;dael> AmeliaBR: Any axis triggers 3d<br>
&lt;dael> smfr: Okay.<br>
&lt;dael> TabAtkins: If you do jsut an angle it's 2d.<br>
&lt;dael> smfr: That's fine as long as it's in the spec.<br>
&lt;dbaron> RESOLVED: specifying just an angle gives 2d, specifying any axis gives 3d<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2130#issuecomment-363965133 using your GitHub account

Received on Thursday, 8 February 2018 00:53:11 UTC