Intent to Implement and Ship: make <tr> with transform be a containing block

[Vladimir Levin]

Contact emails

vmp...@chromium.org

Explainer

crbug.com/804952

Spec

https://www.w3.org/TR/css-transforms-1/#transformable-element

https://www.w3.org/TR/css-transforms-1/#transform-rendering

Summary

According to https://www.w3.org/TR/css-transforms-1/#transformable-element:

“an element whose layout is governed by the CSS box model which is either a block-level or atomic inline-level element, or whose display property computes to table-row, table-row-group, table-header-group, table-footer-group, table-cell, or table-caption”

Additionally according to https://www.w3.org/TR/css-transforms-1/#transform-rendering:

“For elements whose layout is governed by the CSS box model, any value other than none for the transform also causes the element to become a containing block, and the object acts as a containing block for fixed positioned descendants.”

This means that table-row, table-row-group, table-header-group, table-footer-group, table-cell, and table-caption that have a transform property should be containing blocks for fixed position elements. This intent proposes that these changes be made in Blink. Specifically, Blink currently does not make <tr>, <tbody>, <tfoot>, and <thead> with a transform be a containing block for fixed position elements, which we propose to change.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

http://output.jsbin.com/cemigih

Risks

Interoperability and Compatibility

Edge: Does not seem to support transforms on tr

Firefox: Shipped

Safari: No signals

This seems to be a rarely used feature (see crbug.com/804952), so the risk of changing the behavior should be low.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Tests are landing in:

https://github.com/w3c/web-platform-tests/pull/9200

via

https://chromium-review.googlesource.com/c/chromium/src/+/887364

Entry on the feature dashboard

https://www.chromestatus.com/feature/5514792538210304

Thanks,

Vlad

[Chris Harrelson]

LGTM1

I expect that there is a very small amount of content that could be broken by this. It would require an

out-of-flow positioned element underneath a <tr> or similar that had a transform, which is quite an

exotic thing to do.

By way of context, I'd also like to add:

The primary motivation for making this change, in my view, is actually that it rationalizes our

implementation to reduce the special-ness of table parts and reduce complexity.

A second motivation is that transforms are supposed to contain all children, so this change

enforces that invariant across the whole renderer. An upcoming intent will also make filter a

containing block for all children, which is another reason to first simplify the code.

Matching Mozilla is a good third motivation.

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NhTzw5C-11iwruJ6b67Hx-YX--pN4Rq%2BYWKFO8hhykkA%40mail.gmail.com.

[Vladimir Levin]

Update: web platform tests were merged:

https://github.com/w3c/web-platform-tests/tree/master/css/css-transforms

[Rick Byers]

LGTM2 - sounds great, thanks!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8UkfVALcKuG5ftwHqBG1R2FauUVvqtwGNBWYOK-UHwsg%40mail.gmail.com.

[Mike West]

LGTM3. Aligning with Firefox in this narrow way makes a lot of sense, and simplifying our implementation at the same time seems like a win all around.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8O3L7te%2B-ZUe1F2Sobi453Cf669oBB9d4Q0SU9kdnthw%40mail.gmail.com.