Are css/css-contain/contain-layout-baseline-005.html css/css-contain/contain-layout-button-001.html correct? about wpt

[bfgeek]

https://wpt.live/css/css-contain/contain-layout-baseline-005.html
https://wpt.live/css/css-contain/contain-layout-button-001.html

[bfgeek]

https://chromium-review.googlesource.com/c/chromium/src/+/5479489 - if anyone is curious about the baseline patch.

[dholbert]

I'm not yet entirely sure what makes the most sense here, but one other situation that's worth comparing is what happens when these elements have an orthogonal writing-mode. In Firefox, that makes us synthesize a baseline using their border-edge, it seems.

Same WM as parent: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/12648
Same WM as parent, plus contain:layout: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/12649
(Firefox uses the bottom content-edge of in the first case, vs. bottom margin-edge in the second case, as IanK noted)

Orthogonal WM to parent: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/12647
Orthogonal WM to parent, plus contain:layout: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/12650
(Firefox renders these two^ identically, using the bottom border-edge to synthesize the baseline)

[dholbert]

Chrome (v126 dev) seems to synthesize a baseline from the bottom margin-edge, for all of the cases in my previous comment, except for the first one where it uses the content-box bottom for the button and input type="color" vs. the margin-box for the others (I think that inconsistency is the thing @bfgeek mentioned as being not correct)

[bfgeek]

See also whatwg/html#5065

I'm not yet entirely sure what makes the most sense here, but one other situation that's worth comparing is what happens when these elements have an orthogonal writing-mode. In Firefox, that makes us synthesize a baseline using their border-edge, it seems.

(Ignoring <input type=color> for reasons) My current patch will synthesize based off the content edges in all of the above cases. (Which seems reasonable?)

[bfgeek]

cc/ @zcorpan

[dholbert]

At a high level, I think the following makes sense based on current specs:

• contain:layout makes a box be treated as having no baseline per https://drafts.csswg.org/css-contain-1/#containment-layout
• The lack-of-a-baseline forces one to be synthesized per https://drafts.csswg.org/css-align/#generate-baselines ("If a box that participates in baseline alignment has no baseline set, then its alignment baseline is synthesized according to the rules of the formatting context in which it participates" -- technically this is for align-self:baseline but it seems reasonable that it's applicable to vertical-align:baseline as well.)

I'm not entirely sure if how-that-baseline-is-synthesized is well-defined for buttons in an inline context, but it seems worth ensuring it's well-defined & consistent.

[bfgeek]

Yeah - that's the same logic I followed as well - as such I believe that:

<button></button> <button style="contain:layout"></button>

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=12662

Should be aligned (ignoring the issue of how to synthesize baselines for button elements). No browser does this today (likely because of the tests).

I'm going to remove the <button> from one of the tests, and mark the other test as .tentative