Intent to Ship: Align transform-style: preserve-3d and perspective property with the spec

228 views
Skip to first unread message

David Baron

unread,
Jul 26, 2021, 5:40:59 PM7/26/21
to blink-dev

Contact emails

dba...@chromium.org

Specification

https://drafts.csswg.org/css-transforms-2/

Summary

Align the behavior of transform-style: preserve-3d (which allows child elements to participate in the same 3D scene) and the perspective property (which applies a perspective transform to child elements) with the specification by making them apply only to child elements. Before this change, Chromium applies both of these effects based on the containing block hierarchy rather than the DOM tree, and also allows them to extend through elements without transform-related properties on them (where the definition of having transform-related properties exposes Chromium internal concepts and is likely confusing to developers).


Also, align the rules for when transform-style: preserve-3d establishes a containing block for absolute and fixed-position elements with the specification.


For substantially more detail about what's changing, see this description of the TransformInterop feature.


Blink component

Blink>Paint

TAG review

None

TAG review status

Not applicable

Risks


Since this is changing existing behavior that's exposed to Web content, there's some risk that sites might break.  If I break the feature down into five parts, the riskiest seems likely to be the one of those five parts that's not currently shipping behavior in Firefox.  I have added a use counter that aims to detect this case (although it hasn't reached stable yet), and also used cluster telemetry to find top sites that hit the use counter.  That did surface two sites that have visual effects that are broken by the change, although those effects are also broken by a change that is shipping in Firefox and thus don't work in Firefox.  (This perhaps calls into question the assumption about which is the riskiest change.)  The description of the TransformInterop feature goes into considerably more detail.

Interoperability and Compatibility


Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1716904) Most of these changes are making Chromium compatible with the behavior Firefox has already shipped. For the piece where that's not the case, Mozilla bug 1716904 recently landed, implementing that change.

WebKit: No signal

Web developers: No signals


Debuggability

Currently 3D transforms are only debuggable by inspection of specified and computed values of CSS properties.  Given that, this doesn't really influence debuggability other than moving towards a behavior that is hopefully somewhat easier to understand, since dependencies of the Web-exposed behavior on Chromium internals are being removed in favor of a more clearly-defined behavior.

Having better ability to debug 3D transforms is certainly something that could be discussed, but I think it's largely separate from this relatively narrowly-scoped change.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

TransformInterop

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1008483

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5640541339385856

This intent message was generated by Chrome Platform Status and then edited substantially.

Yoav Weiss

unread,
Jul 31, 2021, 1:10:26 PM7/31/21
to David Baron, blink-dev
LGTM1

Aligning with Firefox' behavior here makes sense. 

On Mon, Jul 26, 2021 at 11:40 PM David Baron <dba...@chromium.org> wrote:

Contact emails

dba...@chromium.org

Specification

https://drafts.csswg.org/css-transforms-2/

Summary

Align the behavior of transform-style: preserve-3d (which allows child elements to participate in the same 3D scene) and the perspective property (which applies a perspective transform to child elements) with the specification by making them apply only to child elements. Before this change, Chromium applies both of these effects based on the containing block hierarchy rather than the DOM tree, and also allows them to extend through elements without transform-related properties on them (where the definition of having transform-related properties exposes Chromium internal concepts and is likely confusing to developers).


Also, align the rules for when transform-style: preserve-3d establishes a containing block for absolute and fixed-position elements with the specification.


For substantially more detail about what's changing, see this description of the TransformInterop feature.


Blink component

Blink>Paint

TAG review

None

TAG review status

Not applicable

Risks


Since this is changing existing behavior that's exposed to Web content, there's some risk that sites might break.  If I break the feature down into five parts, the riskiest seems likely to be the one of those five parts that's not currently shipping behavior in Firefox.  I have added a use counter that aims to detect this case (although it hasn't reached stable yet), and also used cluster telemetry to find top sites that hit the use counter.  That did surface two sites that have visual effects that are broken by the change, although those effects are also broken by a change that is shipping in Firefox and thus don't work in Firefox.  (This perhaps calls into question the assumption about which is the riskiest change.)  The description of the TransformInterop feature goes into considerably more detail.

Interoperability and Compatibility


Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1716904) Most of these changes are making Chromium compatible with the behavior Firefox has already shipped. For the piece where that's not the case, Mozilla bug 1716904 recently landed, implementing that change.

WebKit: No signal

Is there a webkit bug filed? I think this is not necessarily big enough of a change to ask for an explicit signal, but would be good to let them know they need to align their behavior.
 

Web developers: No signals


Debuggability

Currently 3D transforms are only debuggable by inspection of specified and computed values of CSS properties.  Given that, this doesn't really influence debuggability other than moving towards a behavior that is hopefully somewhat easier to understand, since dependencies of the Web-exposed behavior on Chromium internals are being removed in favor of a more clearly-defined behavior.

Having better ability to debug 3D transforms is certainly something that could be discussed, but I think it's largely separate from this relatively narrowly-scoped change.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

TransformInterop

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1008483

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5640541339385856

This intent message was generated by Chrome Platform Status and then edited substantially.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gY8u5jLCees7V_m6QBj_Na%3D-7idCoRgFS_GfO0siS1eA%40mail.gmail.com.

Alex Russell

unread,
Aug 5, 2021, 3:07:21 PM8/5/21
to blink-dev, Yoav Weiss, blink-dev, David Baron
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Rick Byers

unread,
Aug 6, 2021, 8:00:30 PM8/6/21
to Alex Russell, blink-dev, Yoav Weiss, David Baron
I'm a little nervous about the compat risk, but reading your excellent cluster telemetry analysis along with the current state of incompatibility between engines I think I'm convinced that this passes our bar. Here's my thinking on the most relevant part of our compat principles:
  • Page views impacted: the UseCounter data suggests this could be quite high, even a whopping 1%. But your partial cluster telemetry analysis shows that in almost every case the counter is hit, there's no visual difference. So this is rather difficult to evaluate, but I'd say somewhere around medium risk. We really only have a guess here since you haven't studied the hits for all of the different changes, but there's good reason to believe it's roughly representative.
  • Severity of breakage: generally going to be just cosmetic - a significant mitigation.
  • Ease of adaptation: may require some fiddling with CSS, but seems like it generally shouldn't be too hard for authors to fix.
  • Interoperability: it sounds like when this does break sites, it tends to break them in favor of matching Firefox. Given the existing poor state of interop here, this effort overall seems clearly interop positive (although some signal from WebKit about intentions to follow would help significantly).
  • Standards conformance: this area has been underspecified and undertested for ages, I really appreciate the effort to clean it up and add WPTs. That makes it worth accepting some non-trivial risk to me.
  • Chrome's release process: there's good reason to believe issues will be noticed and regression bugs filed which can be easily bisected back to this change. 3D transforms seem more likely to target typical consumer sites than, say, enterprise sites where we have less dev/beta coverage. 
  • Outreach: I don't think there's any simple way to explain this to developers and have them check for issues. Really we're fixing bugs around rendering edge cases and I think keeping a close eye on bug reports is the most helpful way to go here.
So LGTM3. But if any of the above reasoning becomes significantly invalidated (eg. we get report of some major non-cosmetic breakage we can't fix, or we find multiple real sites which work in Gecko and WebKit but are now broken in chromium), then we should probably err on the side of caution and delay pending some additional research such as more targeted use counters and/or a UKM use counter analysis.

Thanks,
   Rick

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eac8ef10-e7f1-40bd-bea0-5834292ac9c9n%40chromium.org.

Philip Jägenstedt

unread,
Aug 9, 2021, 12:29:36 PM8/9/21
to Rick Byers, Alex Russell, blink-dev, Yoav Weiss, David Baron
This intent already has 3xLGTM, but I also want to lend my support to it.

Transforms and transform animations have had interoperable between browsers for a long time, and that's why it's included as one of the areas in Compat 2021, and is currently the area with the lowest pass rates overall. (Note that compat 2021 is about improving interoperability, we've used the terminology more familiar to web developers.)

This is about more than increasing test pass rates, but I hope it works out well.

David, would you happen to have an estimate of the impact this will have on the targeted tests, if any?

Best regards,
Philip

Žanetta Berķe

unread,
Aug 13, 2021, 5:49:08 PM8/13/21
to Yoav Weiss, David Baron, blink-dev

bupe chandika

unread,
Aug 13, 2021, 5:53:54 PM8/13/21
to Philip Jägenstedt, Rick Byers, Alex Russell, blink-dev, Yoav Weiss, David Baron
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/4LWMf_tZwtw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdR4cw8ZfZRQv5nndiO3%3Dju0j%3DjdSLNu%2BVEzHpfok9A4Q%40mail.gmail.com.

David Baron

unread,
Aug 16, 2021, 11:32:20 AM8/16/21
to Yoav Weiss, blink-dev
Sorry for the delayed replies here -- in hindsight, sending an intent with less than a week before I left for 2 weeks of PTO might not have been the best choice.

On Sat, Jul 31, 2021 at 1:10 PM Yoav Weiss <yoav...@chromium.org> wrote:

Interoperability and Compatibility


Gecko: In development (https://bugzilla.mozilla.org/show_bug.cgi?id=1716904) Most of these changes are making Chromium compatible with the behavior Firefox has already shipped. For the piece where that's not the case, Mozilla bug 1716904 recently landed, implementing that change.

WebKit: No signal

Is there a webkit bug filed? I think this is not necessarily big enough of a change to ask for an explicit signal, but would be good to let them know they need to align their behavior.

I've filed bug 229141. That said, WebKit folks, particularly Simon Fraser, are aware of the Working Group discussions of these topics, but I agree that filing a bug is a good idea.  I also have some existing feedback from Simon about some related differences in WebKit that I need to understand better (as part of improving other aspects of transform interoperability).  WebKit's handling of transform-style is a good bit different (it has an additional value 'flat' that's not in the spec, and it has different meanings for the other values as a result), but I'm not aware of a specification-level description of what it actually does.

-David

David Baron

unread,
Aug 16, 2021, 11:47:12 AM8/16/21
to Philip Jägenstedt, Rick Byers, Alex Russell, blink-dev, Yoav Weiss
On Mon, Aug 9, 2021 at 12:29 PM Philip Jägenstedt <foo...@chromium.org> wrote:
David, would you happen to have an estimate of the impact this will have on the targeted tests, if any?

The tests that I listed in the doc describing the feature were (at least at the time I wrote that doc) the complete list of tests that would be changed to passing by enabling TransformInterop.  In other words, the newly passing tests in WPT will be the following:

6 tests that I added during TransformInterop work:

css/css-transforms/3d-rendering-context-and-abspos.html

css/css-transforms/3d-rendering-context-and-fixpos.html

css/css-transforms/3d-rendering-context-and-inline.html

css/css-transforms/perspective-children-only-abspos.html

css/css-transforms/perspective-children-only-fixpos.html

css/css-transforms/perspective-children-only-inline.html


2 tests that chrishtr added during TransformInterop work:

css/css-transforms/3d-rendering-context-behavior.html

css/css-transforms/preserve-3d-flat-grouping-properties-containing-block.html


5 tests that were in WPT before TransformInterop:

css/css-transforms/transform-table-006.html

css/css-transforms/transform-table-007.html

css/css-transforms/transform3d-perspective-003.html

css/css-transforms/transform3d-perspective-004.html

css/css-transforms/transform3d-sorting-004.html


My read of the relevant Compat 2021 test list is that the last 5 listed do count for the compat 2021 score, the first six do not, and I'm not sure about the two in the middle (which are the ones that Chris added, but which I renamed to not have tentative in the filenames, which means they're no longer in the test list, but perhaps that should be fixed).

-David

Philip Jägenstedt

unread,
Sep 7, 2021, 11:10:15 AM9/7/21
to David Baron, Rick Byers, Alex Russell, blink-dev, Yoav Weiss
Thanks for this breakdown, David! This prompted me to go have a look at the test list and look for more renamed, and I fixed the ones in transforms and a few others:

If the tests are now passing in Chromium, this is going to appear like a score improvement at the time of the rename. But with over 700 transforms tests included in Compat 2021, the effect shouldn't be dramatic.

Best regards,
Philip
Reply all
Reply to author
Forward
0 new messages