[css-transforms-2] Syntax of individual transforms should reflect general CSS syntax

[evayde]

For example: Individual translate is only usable like so: translate: 0 0 10px
But translate as an individual property should be a shorthand for
translate-x, translate-y, and translate-z
In my opinion, this would reflect the current CSS syntax with other properties, like overflow, background-position, scroll-snap-type, and so on. Otherwise, it feels kind of inconsistent to me.

Or is there any technical reason that we cannot provide that syntax for individual transforms?

Spec: https://www.w3.org/TR/css-transforms-2/#individual-transforms

[jakearchibald]

@bramus any idea why translate-x isn't a thing?

[tabatkins]

It wasn't part of the initial use-cases that we designed the individual transform properties for.

[jakearchibald]

So it could be added in future?

[bramus]

I think so – Can’t think of a reason why it wouldn’t be possible.

[evayde]

As far as I understand it, the reason for creating individual transform properties was so that we can animate stuff without writing everything again, so:

div {
  transform: translate(0,100px) scale(1.2) rotate(20deg);
}

div:hover {
  transform: translate(10px,200px) scale(1.2) rotate(20deg);
}

Can be written like this:

div {
  transform: translate(0,100px) scale(1.2) rotate(20deg);
}

div:hover {
  translate: 10px 200px;
}

For the same reasons, we could argue that this would be even better (more granular):

div {
  transform: translate(0,100px) scale(1.2) rotate(20deg);
}

div:hover {
  translate-y: 200px;
}

Also it is more consistent with how other CSS properties and their shorthand syntax works.

[bramus]

In addition to translate-x and translate-y, would it also make sense to have translate-inline and translate-block? Same for scale-*/rotate-*, knowing that for the *-z properties there would be no logical counterpart.

[tabatkins]

We don't have corresponding functions for those; I'm uncomfortable adding properties that are genuinely unexpressible in 'transform' itself.

[css-meeting-bot]

The CSS Working Group just discussed [css-transforms-2] Syntax of individual transforms should reflect general CSS syntax, and agreed to the following:

• RESOLVED: add the longhands to these properties as discussed above

The full IRC log of that discussion

<florian> bramus: individual transforms property now exist, and help author with control over their animations
<florian> bramus: now people want more granularity, like translate-x, -y, etc
<florian> TabAtkins: I'm fine with that
<florian> TabAtkins: the other part was the logical transforms (translate-inline, etc)
<SebastianZ> q+
<astearns> ack fantasai
<florian> TabAtkins: that I'm against, because we don't have logical transforms, and thus nothing to map them too cleanly
<florian> bramus: that's ok
<florian> fantasai: do we want to just add those?
<flackr> q+
<astearns> ack SebastianZ
<florian> TabAtkins: that's part of this issue
<florian> SebastianZ: how about scale-x, scale-y, and the same for rorate
<florian> s/rorate/rotate/
<fantasai> s/that's/not/
<florian> TabAtkins: they were deliberately omitted from the transform properties, because there's no obvious correct order
<florian> TabAtkins: sorry, skew was omitted
<florian> flackr: does rotate has a long hand
<florian> TabAtkins: you'd have rotate-axis and rotate-angle
<astearns> ack flackr
<florian> flackr: when you create an animation with these now separate props, it might be surprising to authors:
<florian> flackr: if they set translate-x in the first and last keyframe, and -y in the middle, they'd only get the transition on the -
<florian> TabAtkins: that seems fine
<florian> fantasai: if you want the other behavior, then just put the necessary properties in the relevant keyframes
<florian> flackr: seems fine, never mind
<florian> bramus: the current standalone properties have enabled that, so it would be the same
<florian> TabAtkins: aminating on the separate properties and the joint ones give different results
<florian> astearns: Proposal: translate, rotate and scale have long hands
<flackr> q+
<florian> TabAtkins: translate -x and -y, rotate -angle -axis, scale -x -y -z
<TabAtkins> (and translate-z
<TabAtkins> )
<SebastianZ> q+
<astearns> ack flackr
<florian> flackr: is it well defined how we interpolate from one rotation angle to another
<florian> TabAtkins: I forget what the answer is, but yes, it's in the spec
<astearns> ack SebastianZ
<florian> SebastianZ: why rotate-angle and rotate-axis when we have rotate-x, rotate-y and rotate-z as functions
<florian> TabAtkins: there are multiple results depending on the order when you combine them, so it'd be ambiguous
<TabAtkins> TabAtkins: So if you do want to do independent rotations, use 'transform'
<florian> RESOLVED: add the longhands to these properties as discussed above
<astearns> ack fantasai
<Zakim> fantasai, you wanted to take up this comment as its own issue https://github.com//issues/7646#issuecomment-1545399874 which is filed at
<Zakim> ... https://github.com//issues/1544 already
<florian> dbaron: I'm not sure…
<florian> dbaron: I am concerned about the complexity this adds. Need to think about it.
<florian> astearns: how about you comment on the issue after reviewing that
<florian> fantasai: wanted to comment the logical part of this problem
<florian> astearns: it is a separate issue, and the agenda is already too crowded so no

[tabatkins]

This would be changing the decomposition a little, tho not in a way that's observably different from what we have today.

Currently the three transform properties insert three transform functions into the transform stack. Now they'll insert 7: 3 translates, a rotate, and 3 scales. If you continue to use the (now) shorthands the behavior is identical, since translates and scales are order-independent between themselves.