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

On Wed, Jul 16, 2014 at 12:49 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Jul 16, 2014, at 8:46 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Jul 15, 2014 at 11:26 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> 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.
>>
>> Yup, basically.  It was a good idea!
>>
>>> 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.
>>
>> Why do you think it's more complex? It's just copying transform-origin
>> for the new properties.
>
> Right, I am saying that the rotate() function already has origin arguments. Why wouldn’t you add them to the rotate property as well and pass on rotate-origin. There have been proposals to add the same support for scale().

Oh, I getcha.  Yeah, sure, makes sense. Might as well match SVG, and
then follow the pattern for scaling.

>> Yes, order matters when you need the transforms to interact.  When you
>> don't (when they're all "local"), there's one specific order that does
>> what you want.
>
> “local” seems to be confusing here. All transformations are local for an element and take affect on rendering into the parents graphics context. I think what you meant to say is (correct me if I am wrong) that authors most likely just will use one of the transform properties: Either rotate, or translate, or scale or transform. And therefore you just want to have a sane fallback if an author uses them in combination.

No, this is not what I mean.  I really mean "local", in an intuitive
way, not a technical one.  When applied in TRS order, the three
transformations don't have an effect on each other - each is applied
as if they were the only one, and composed together in a way that
makes them look like independent effects.  It lets you pretend that
transforms aren't being multiplied together into a matrix, but are
actually separate properties that compose in the normal way that
properties do.

(This wasn't part of my original argument, because I hadn't realized
how useful this aspect was yet, and I was still in the mode of "let's
directly translate everything".  It's something that I came to realize
gradually, and is why I think it's fine to trim the effects down to
just TRS.

>> These cases aren't easy, from author feedback.  That's the point.
>
> It is hard to differ between the cases. I think with this comment you do not refer to the “Ah, I used translate: 20px, 20px instead of transform: translate(20px, 20px)” case, right? Because that is a slip of the pen and can easily be detected and corrected by authors.

Again, it's an *extremely common* slip of the pen, which indicates
that people really want to be able to write that, and accommodating
that would probably be a good idea.

But no, I'm actually referring to the difficulty of (a) composing
different transform actions for different things (like my hover/active
example, or the animation/hover example), and (b) having to understand
the significance of ordering in the common cases where you don't
actually care, because you're not *conceptually* applying transforms
in series (what I said above).

Literally, before this thread, I didn't realize that I just needed to
write my transform list in TRS order to get them to act independently.
It's not obvious, and I'm a smart guy who's read the spec a few times.

~TJ

Received on Wednesday, 16 July 2014 15:19:43 UTC