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

On Jul 16, 2014, at 7:41 AM, Alan Stearns <stearns@adobe.com> wrote:

> On 7/15/14, 8:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> 
>> On Tue, Jul 15, 2014 at 7:54 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> On 7/15/14, 6:55 PM, "Dean Jackson" <dino@apple.com> wrote:
>>>> 
>>>> whatever {
>>>> rotate: 10deg;
>>>> transform: translate(5px) rotate(20deg) translate(10px);
>>>> translate: 20px;
>>>> }
>>>> 
>>>> Do I override just the first translate? The last? Both of them?
>>>> Everything? None of them?
>>> 
>>> When I try to think of a good answer to this question, all I manage to
>>> come up with seems very arbitrary. I am cautiously against the proposal
>>> so
>>> far. The author convenience seems to me to be outweighed by the
>>> complexity
>>> of getting the ‘legacy’ transform property to work with the proposal.
>> 
>> You override none of them, *because 'transform' is a separate property*.
>> 
>> And as I said, whether or not 'transform' is a shorthand that resets
>> the other transforming properties is something we can discuss.  I
>> think it's probably fine to not do that, and leave 'transform'
>> independent as well.
>> 
>> (That would mean that the rotate isn't overridden either.  You
>> independently translate and rotate, then afterwards apply the
>> transform. Nice and easy.)
> 
> So there are at least two separate proposals.
> 
> Your original proposal had transform as a shorthand, and a bit later you
> said it was important to have a way to reset all the transforming
> properties, reinforcing the notion that the shorthand transform resets
> everything. 
> 
> Then when Dean brought up the notion of using both transform and rotate
> together, your reply assumes that transform does not reset rotate, so
> transform is no longer a shorthand and loses the resetting behavior. This
> second proposal sounds to me like two separate syntaxes for
> transformations, one applied after the other.

I think we are back to my original proposed modification. Just three properties: rotate, translate and scale. No shorthands. If we could reduce the proposal to that, it would already be easier to argue since it is more specific.

This still brings us to the three other problems:

1) Users want to apply an origin.
- In SVG, rotate has 3 arguments because of that: angle[, originX, originY]? The rotate() function actually requires it as well in the spec, but it is just partly implemented today.
- Tab proposes two new properties to modify the origin for scale and rotate. This already makes it more complex IMO.

2) Fixed order of the new properties and the transform-list.

Just take a look at the following examples:
http://jsfiddle.net/B3jPX/
http://jsfiddle.net/B3jPX/1/

- In one example the object rotates around it self (earth around own axis).
- In the other example, the translation is used to define the distance from the origin the object is rotated around (earth around sun).

Both are very commonly used. In my experience, the second one is mainly used in graphical environments like SVG, the first for responsive designs in HTML. Have a fixed order would leaf out one of the use cases. Adding a new property to define the order, as I proposed, might be an overkill as well.

The take away: Even though some stated otherwise: Order matters, as does the understanding what the order means!

3) rotate, scale, translate are verbs and we don’t use verbs as property names. On the other hand, this would be the thing that makes the properties useful for authors right now. Otherwise authors would need to remember more names and also the rules when which name applies. We probably want to have an exception here and use the verbs instead.

IMO, I still don’t accept the sentiment that we want to make the easy cases more easier for authors. As Dean mentions, it could be a simplification with a high price and the confusion would move to other parts.

Greetings,
Dirk

> 
> Does this match your understanding?
> 
> Thanks,
> 
> Alan
>

Received on Wednesday, 16 July 2014 06:27:41 UTC