W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-transforms] Making 'transform' match author expectations better with specialized 'rotate'/etc shorthands

From: Sylvain Galineau <galineau@adobe.com>
Date: Mon, 14 Jul 2014 00:16:17 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: "<www-style@w3.org>" <www-style@w3.org>
Message-ID: <DDD2A390-33E5-4AE4-A54B-0F0CC15EDBE4@adobe.com>

On Jul 12, 2014, at 8:13 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Jul 11, 2014 at 11:42 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> Earlier today I saw a Twitter thread started by Lea
>> <https://twitter.com/LeaVerou/status/487350702386479105> about how she
>> commonly accidentally types the name of the transform she wants as the
>> property (like "rotate: 45deg;") and then has to go back and correct
>> it afterwards.  Several other devs chimed in that they do this as
>> well, and I know that I've done it a few times (especially when using
>> SVG - I use "transform='translate(...)'" so often that I commonly try
>> to name the attribute "translate" first).
>> Since this is something that devs trip over so much, it might be worth
>> accommodating it in the syntax.  I think we can do this compatibly
>> with the current syntax.  Here's a proposal:
> And, to hopefully make the details of the proposal clearer, here is
> the full proposal for new properties, with shorthands all explicitly
> defined as well.
> Core Properties:
> * perspective: none | <length>
> * translateX: none | <length>
> * translateY: none | <length>
> * translateZ: none | <length>
> * rotateX: none | <angle>
> * rotateY: none | <angle>
> * rotateZ: none | <angle>
> * rotate3d: none | <number> <number> <number> <angle>
> * scaleX: none | <number>
> * scaleY: none | <number>
> * scaleZ: none | <number>
> * skewX: none | <angle>
> * skewY: none | <angle>
> * skew: none | <angle> <angle>?
> * transform-list: none | <transform-function>+

> Shorthand properties:
> * translate3d: none | <length> <length> <length>
>  - expands to translateX, translateY, and translateZ
> * translate: none | <length> <length>
>  - expands to translateX and translateY, setting translateZ to "none"
> * rotate: none | <angle>
>  - expands to rotateZ
> * scale3d: none | <number> <number> <number>
>  - expands to scaleX, scaleY, and scaleZ
> * scale: none | <number> <number>?
>  - expands to scaleX and scaleY (setting both to the first number if
> the second is omitted), setting scaleZ to 1
> * transform: none | <transform-function>+
>  - expands to transform-list, setting all of the other core
> properties to "none" (except 'perspective', which is untouched)

Besides providing a straight mapping from the existing functions, any reason you'd want both translate and translate3d properties? Could we have one translate shorthand with an optional Z value defaulting to 'none' if 2D is the most common case? 

Same question for scale. It just feels weird for properties like scaleX/scaleY to be set by two distinct but conceptually largely overlapping shorthands.

rotate is more interesting in that the 3d version specifies a vector while the 2d only sets an angle around transform-origin. But given that rotations often involve setting a transform-origin anyway, could be have a single rotate shorthand that combines an angle with an optional coordinate? If 2D, the latter sets the origin of the transform. If 3d, the coordinate would define the rotate3d vector.

I would note that SVG rotations follow this exact pattern i.e. you specify the angle and an optional rotation origin. This allows each rotate to define its own origin, something the current CSS model does not support.
Received on Monday, 14 July 2014 00:17:08 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:42 UTC