1920634 - Firefox and Chrome disagree on how to size `stretch` (-moz-available / -webkit-fill-available) alongside float

Status: NEW

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Load attached testcase.

FIREFOX AND WEBKIT RESULTS:
Cyan area goes below the float.

CHROME RESULTS:
Cyan area goes to the right of the float.

Filing this to track a known behavior-difference at least -- though I think Firefox/WebKit are probably correct in terms of how stretch is supposed to behave (and the prefixed equivalents which ideally should match it). The spec text for stretch here...
https://drafts.csswg.org/css-sizing-4/#valdef-width-stretch
https://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing
...essentially says the used size is "he length necessary to make its outer size as close to filling the containing block as possible while still respecting the constraints imposed by min-height/min-width/max-height/max-width." It goes into additional detail but doesn't have any special cases regarding floats or clearance. So, in this case, it should behave equivalent to width:100% which matches the Firefox/WebKit behavior.

Hence: probably not a bug on our side, though potentially worth tracking in case Chrome doesn't fix it and there ends up being interop impact.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reference case 1

Here's a reference case where I'm just using width:100% to demonstrate what I think the spec calls for here.

Firefox/WebKit render the testcase in a way that matches this reference case. Chrome does not.

Comment 3

[Daniel Holbert [:dholbert]]

(thanks to yisibl for calling this to my attention on dev-platform.)

Comment 4

[Oriol Brufau [:Oriol]]

https://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing

Formally, its behavior is the same as specifying an automatic size together with a self-alignment property value of stretch (in the relevant axis)

So how should justify-self work in the presence of floats? See https://github.com/w3c/csswg-drafts/issues/9963
Blink and WebKit are broken, Firefox is reasonable: it aligns within the intersection of:

• the containing block shrunken to avoid floats
• the containing block shrunken by the margins

So I think it follows that the stretched element should be able to fit beside the float.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Oriol Brufau [:Oriol] from comment #4)

So how should justify-self work in the presence of floats? See https://github.com/w3c/csswg-drafts/issues/9963

I haven't thought deeply yet about justify-self plays into this.

So I think it follows that the stretched element should be able to fit beside the float.

Assuming you're talking about testcase 1 here - I think that means you prefer Blink's behavior on that testcase, correct?

I also now prefer their behavior, I think - IanK convinced me here:
https://github.com/w3c/csswg-drafts/issues/4028#issuecomment-2372348130

(That means we do in fact have a behavior-change to make here.)

Comment 6

[Oriol Brufau [:Oriol]]

Yes, I do agree with Ian that width: auto for a non-replaced block is like width: stretch.

Comment 7

[Daniel Holbert [:dholbert]]

Note, this bug is the reason why Firefox fails this WPT when you enable layout.css.stretch-size-keyword.enabled:
https://wpt.live/css/css-sizing/stretch/bfc-next-to-float-1.html
(wpt.fyi)

Note, if you don't toggle that pref, we appear to pass the test (and wpt.fyi currently shows us passing), but that's only because stretch isn't enabled by default yet, and the test spuriously passes in browsers that lack stretch support.

Comment 8

[Daniel Holbert [:dholbert]]

(But also, to be clear, our WPT test failure with-that-pref-enabled doesn't actually indicate a new bug being introduced here as part of stretch. The test just happens to rely on width:stretch, which means it only does-the-interesting-stuff if you have stretch enabled. But the same issue reproduces in current and older Firefox versions if you use devtools to replace stretch with its vendor-prefixed inline-specific sort-of-equivalent -moz-available, as in testcase 1 here.)

Comment 9

[一丝]

In reference case 1, I believe we should remove width: 100% from .stretched to achieve the expected result.

As Chrome has shipped the stretch keyword, testing in Chrome 140 shows that the stretch effect does not behave identically to 100%, but rather behaves identically to auto.