[css-transforms-2] The readiness of shipping individual transform properties - translate, rotate, scale

[BorisChiou]

Gecko is ready to ship individual transform properties - translate, rotate, scale. However, css-transforms-2 is still a working draft right now, so it'd be safer to make sure the CSS WG agrees to ship these 3 transform properties.

[1] Intend-to-ship mail for Gecko: https://groups.google.com/forum/#!topic/mozilla.dev.platform/4oyeCHOqt4I

[BorisChiou]

cc @heycam

[BorisChiou]

cc @ericwilligers

[ewilligers]

The spec is well understood, so I have no concerns about Gecko shipping. It would be excellent to have computed value serialization WPTs.

I don't think we need to wait until we have two or more browsers supporting all five values for transform-box - the CSS Transforms 1 feature that isn't fully supported by browsers yet.

For Blink, I would like to ship offset-anchor at the same time as the individual transform properties. (I suspect Blink currently uses 0,0 as the effective offset-anchor.)

[Crissov]

Does Gecko already support percentage scaling? #3399

[BorisChiou]

Does Gecko already support percentage scaling? #3399

Not yet. I just filed Bug 1597642, and can fix it soon or later.

[css-meeting-bot]

The CSS Working Group just discussed The readiness of shipping individual transform properties - translate, rotate, scale, and agreed to the following:

• RESOLVED: Working group is fine with translate, rotate and scale shipping
• RESOLVED: Move the 3D transforms to a level 3of Transforms

The full IRC log of that discussion

<dael> Topic: The readiness of shipping individual transform properties - translate, rotate, scale
<dael> github: https://github.com/w3c/csswg-drafts/issues/4515
<dael> astearns: Gecko is ready to ship. Any concerns about that?
<fantasai> I would like us to get the spec to CR soonish
<fantasai> would it make sense to drop the 3D Transforms section to L3
<fantasai> ?
<fantasai> and then make L2 be 2D transforms + this feature?
<dael> astearns: [reads fantasai IRC] should we drap 3d transforms for that?
<dael> s/drap/drop
<fantasai> Just push to level three
<dael> smfr: Tranforms 1.5 which is 1+individual functions
<fantasai> then L3 is about 3D, even :)
<dael> TabAtkins: I'm fine with punting items to L3
<fantasai> super better
<fantasai> than L1.5
<fantasai> :)
<dael> astearns: Anothor impl of individual functions soon?
<fantasai> we're not in CR yet, so it's about the spec, not impl status
<dael> fremy: I think they were behind a flag in old Edge
<fantasai> if spec for individual functions is done, let's push it to CR and defer the rest to L3
<dael> astearns: I wouldn't mind moving the 3D transforms. Wondering what other small things will drop to L3.
<dael> fremy: Old Edge has a flag to enable individual transforms. So we have impl to move the spec forward
<fantasai> Propose several resolutions
<fantasai> First resolution, clear these to ship
<dael> smfr: Interaction with motion path I'm forgetting about?
<fantasai> 2nd resolution, push everything other than these features (unless someone thinks there's something else close to CR) to L3
<dael> astearns: Can anyone answer that yes or no?
<fantasai> I don't think so
<dael> emilio: Motion path adds transform-ish stuff but the order is well defined.
<dael> myles: There's an order. Apply transform properties and then motion path. Might have it flipped, but it's well defined. No interaction
<dael> astearns: First proposed resolution is clear these to ship
<dael> astearns: Not hearing concerns. Objections to Working group is fine with translate, rotate and scale shipping?
<dael> RESOLVED: Working group is fine with translate, rotate and scale shipping
<myles> emilio
<dael> astearns: 2nd is move the 3d transforms out to a new level. ANy concerns?
<TabAtkins> Yeah, the total effective transform is <motion-path> <translate> <rotate> <scale> <transform>
<emilio> myles: np! :)
<TabAtkins> (with perspective/transform-origin bodged into the <transform> bit there)
<dael> RESOLVED: Move the 3D transforms to a level 3of Transforms
<dael> astearns: I think we should take it up in a call soon about taking L2 Transforms to CR
<TabAtkins> Or wait, dbaron's right, transform-origin goes before <translate> and after <transform>
<dael> astearns: I don't think that's something for 4 minutes
<fantasai> probably need to wait for edits :)
<fantasai> also maybe republish both as WD/FPWD
<dael> astearns: IRC question about transform-origin?
<dbaron> also perspective is a little bit fun
<dael> TabAtkins: No, just chatting about effect, but it's well understood

[ewilligers]

Are we saying that the individual transform properties would be in L2 but 3D transforms would be in L3. So individual transform properties would be 2D in L2 and 3D in L3? I don't see any reason to ship the individual transform properties as 2D instead of 3D.

[astearns]

To be clear, the two resolutions here are separate. We resolved that the CSSWG is OK with implementations shipping the individual transform properties. Separately, we are looking whether we can accelerate getting transforms level 2 to CR (the normal way of encouraging things to ship). Whether or not we can get the spec to CR does not affect the decision that it's OK to ship now.

[BorisChiou]

Does Gecko already support percentage scaling? #3399

Gecko supports percentage scaling for scale property and scale function now because Bug 1597642 has been fixed.

[TheSonOfThomp]

Is there any discussion about long-hand properties like scale-x, scale-y, etc?

[dbaron]

If this doesn't ship in a CR of transforms soon enough, it should probably go in the relevant section of the next snapshot.

[fantasai]

Added to the 2021 Snapshot. Still need someone to split out Transforms L3 and push L2 to CR.

[andyearnshaw]

Is there any discussion about long-hand properties like scale-x, scale-y, etc?

I'm also interested in this. I'm currently looking at refactoring a virtual grid component that specifies top through a .row-n class name and left through a .col-n class name. The CSS ends up looking something like this (obviously simplified):

.row-0 { top: 0px; }
.row-1 { top: 24px; }
.row-2 { top: 48px; }

.col-0 { left: 0px; }
.col-1 { left: 80px; }
.col-2 { left: 160px; }

Each cell is then assigned the row or column class according to its position in the grid. Refactoring this isn't as straightforward as I'd hoped, because I can't use translate-x and translate-y. I can use a CSS custom properties, but I've found that the resolution process for those offsets the performance gain that updating transform provides and, in the case of pages with a large number of elements, sometimes makes performance significantly worse. That's possibly something that browser engines could mitigate but it would be nice if I didn't have to worry about using custom properties at all.

[bramus]

Individual Transform Properties have shipped in every browser by now. Are the spec edits still needed? @fantasai @tabatkins

[Crissov]

@andyearnshaw @TheSonOfThomp The longhands were discussed and greenlighted but then halted in #7646.