1371943 - Update transform-box initial & fallback values to match latest CSS WG resolution

Status: RESOLVED DUPLICATE of bug 1819464

(Core :: Layout, defect, P3)

Description

[Amelia Bellamy-Royds]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

In Firefox 55, the transform-box property is implemented according to the spec as it existed a couple months ago.  Implementation shipped as described in issue #1208550



Actual results:

In the process of getting other browsers support, some issues with the current spec were identified.  The CSS WG resolved to change the initial value of the property and the way that the CSS box layout values map to SVG layout values (and vice versa).

See summary here: https://github.com/w3c/csswg-drafts/issues/857#issuecomment-296074806

Blink and WebKit are working on implementations based on the latest resolutions:
- Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=595829
- WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=145783


Expected results:

The following changes affect the Firefox implementation:

- The initial value is now `view-box`
- The used values change when a CSS box keyword is used for an element without CSS layout boxes, or when an SVG box keyword is used for an element without SVG layout.  The correspondences are those defined in the draft Fill & Stroke module for the fill-origin property: https://drafts.fxtf.org/fill-stroke-3/#fill-origin

Comment 1

[Daniel Holbert [:dholbert]]

For reference / searchability: the specific CSSWG resolutions here were:

RESOLVED: Add "auto" as initial value for transform-box, give it the current border-box/view-box dual behavior
RESOLVED: Add stroke/padding/content-box, and set up the proper mappings between them for transform-box.

It looks like padding-box didn't end up making it into the spec (perhaps due to another spec change or resolution), but stroke-box and content-box did:
https://drafts.csswg.org/css-transforms/#transform-box

And Firefox's lack-of-support for those values is what's causing these WPT tests to fail:
https://wpt.fyi/results/css/css-transforms/parsing/transform-box-valid.html
https://wpt.fyi/results/css/css-transforms/parsing/transform-box-computed.html

To a first approximation, this bug is probably responsible for all the failures here as well:
https://wpt.fyi/results/css/css-transforms/transform-box?label=master&label=experimental&aligned&q=firefox%3Afail

Comment 2

[Boris Chiou [:boris]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

For reference / searchability: the specific CSSWG resolutions here were:

RESOLVED: Add "auto" as initial value for transform-box, give it the current border-box/view-box dual behavior
RESOLVED: Add stroke/padding/content-box, and set up the proper mappings between them for transform-box.

I didn't see auto in the current draft version, so I guess there may be some update after this.

Anyway, this is probably duplicated by Bug 1819464 right now.