W3C home > Mailing lists > Public > www-style@w3.org > February 2018

Re: [CSSWG] Minutes Telecon 2018-02-7 [css-typed-om] [css-transforms]

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 8 Feb 2018 08:37:45 +0000
To: Dael Jackson <daelcss@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <25633921-6AAF-49C3-9510-2F269A4F44A9@adobe.com>
Hi all,

Couldn’t attend the meeting because of the time.

I would like to note that there might be a potential mixup for users. The `rotate()` function for CSS Transforms on SVG elements has the following syntax[1]:

rotate()<https://drafts.csswg.org/css-transforms/#funcdef-transform-rotate> = rotate( <angle><https://drafts.csswg.org/css-values-3/#angle-value> [,<https://drafts.csswg.org/css-values-4/#comb-comma> <length><https://drafts.csswg.org/css-values-3/#length-value>,<https://drafts.csswg.org/css-values-4/#comb-comma> <length><https://drafts.csswg.org/css-values-3/#length-value>]?<https://drafts.csswg.org/css-values-4/#mult-opt> )

The confusion could come from the same name of the `rotate` property and the `rotate()` function. Especially since <length> values on SVG presentation attributes may be unitless. At least the length values are comma separated from the angle.


[1] https://drafts.csswg.org/css-transforms/#rotate-three-function

On 8. Feb 2018, at 03:26, Dael Jackson <daelcss@gmail.com<mailto:daelcss@gmail.com>> wrote:

Named rotation axis
 github: https://github.com/w3c/csswg-drafts/issues/2130

 ericwilligers: Current spec and suggestions:
 <ericwilligers> Current spec: rotate: none | <number>{3}? <angle>
 <ericwilligers> Suggestion by Amelia: rotate: none | [ 2d | x | y |
                 z | <number>{3} ]? && <angle>
 <ericwilligers> Suggestion by Eric in #1269: none | <angle> &&
                 [ axis(<number>{3}) ]?

 AmeliaBR: For most people the vector notation is more complicated
           and all the shorthands have rotate-x,y,z. We do have
           discussion in the issue my suggested keyword of 2d doesn't
           parse as a keyword which is an issue.
 AmeliaBR: Reason we have a separate keyword is we need to
           distinguish between 2d and 3d transforms around z axis
           which is simple math, but different in impl
 ericwilligers: The difference could be if you spec the axes.
 AmeliaBR: Yeah, that was one suggestion. We don't worry about a
           keyword for 2d and if you don't spec axis it's 2d.
 <fantasai> +1 to Amelia's suggestion
 TabAtkins: I hadn't thought about the rotate functions having
            rotateX,rotateY,rotateZ and I support allowing you to set
            those instead of remembering the correct set up.
 <TabAtkins> rotate: <angle> && [ x | y | z | <number>{3} ]?

 AmeliaBR: Question is if we have those keywords is the unwrapped 3
           numbers still acceptable or do people like function
 fantasai: I'm opposed to function 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 people would want angle in the
 TabAtkins: And rotate 3d takes an angle and 3 numbers so it's the
            same syntax.
 Rossen: We have a couple of people opposed to functional notation.
 Rossen: Does that mean we want to go with first proposal?

 <ericwilligers> rotate: none | <angle> && [ x | y | z | <number>{3}
 <AmeliaBR> rotate: none | [  x | y | z | <number>{3} ]? && <angle>
 ericwilligers: You can use x y z, have 3 numbers, or leave them out.
                And angle before or after axes.
 TabAtkins: Yeah. I'm not sure why grammar has 3 numbers before, but
            that was probably an accident.

 smfr: Are unitless 0s allowed for the angle?
 ericwilligers: Not allowed.
 TabAtkins: Right. They're legacy feature you have to opt into and we
            don't allow in new.

 AmeliaBR: Final question. Even though we're allowing both to spec in
           either order, do we want to stick with angle and then axis
           to match transform?
 dbaron: I think in rotate 3d the angle is at end.
 TabAtkins: Oh. I think the order in the grammar matches order
            serialized so we should have axis first to match rotate

 Rossen: Current proposal is match rotate 3d syntax?
 <AmeliaBR> https://drafts.csswg.org/css-transforms-2/#funcdef-rotate3d

 TabAtkins: No. We should have the axis come first.
 AmeliaBR: It's this one rotate: none | [  x | y | z | <number>{3} ]?
           && <angle>
 AmeliaBR: ... for the serialization order

 Rossen: Any objections?
 * fantasai is confused
 Rossen: fantasai you're confused.
 fantasai: We're deciding to not match transform ordering?
 TabAtkins: The rotate3d() takes axis first.
 fantasai: Okay, sure. As long as trying to match.

 <ericwilligers> We can close https://github.com/w3c/csswg-drafts/issues/1269

 ericwilligers: I think we can also close this issue ^

 RESOLVED: Grammar is rotate: none | [  x | y | z | <number>{3} ]? &&

Received on Thursday, 8 February 2018 08:38:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 February 2018 08:38:17 UTC