1763431 - Zero-width `div` with `display: flow-root` Still Intersects Outer Floats

Status: RESOLVED DUPLICATE of bug 1739260

(Core :: Layout: Floats, defect)

Description

[David Shin[:dshin]]

STR: Visit https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10195, check "Rendered View"
Expected: Purple div at the bottom right should extend 100px below the blue div
Actual: Purple div does not extend below the blue div

The zero-width div with display: flow-root set (Which contains the purple div) intersects the top blue div. Because display: flow-root establishes a new block formatting context, there should be no intersection.

Comment 1

[Daniel Holbert [:dholbert]]

Hmm, I'm not entirely sure about this... The zero-width div "fits" in the space to the side of the float (since it's zero-width); so it's not clear to me that it should get pushed down.

Note that if you increase the sizes of the divs to be 400px, Chrome still places the purple div alongside the second float, i.e. they agree that the zero-width block formatting context is fine to fit in the zero space that's left behind by that float.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 [Sort of unrelated to the actual bug here, per comment 6] (mix of float combinations with zero available space after floats)

Comment 3

[Daniel Holbert [:dholbert]]

I've attached a variant of your original external testcase, with:

• zero space alongside the floats
• a mix of float directions (left/left, left/right, right/right, right/left)
• partial-opacity so that it's easier to see the purple div when it gets covered up by a float.

This shows that Firefox consistently places the zero-width BFC alongside the first float, whereas Chrome seems to decline-to-do-that when the float direction changes (in which case Chrome places it alongside the lower-down float, where there is also 0 space available).

Interestingly, WebKit (epiphany) matches Firefox on your original testcase, and they almost-match Firefox on my attached testcase 1 as well, except for the very last line where they do their own thing (they place the 0-width BFC at the top-right of the "outer" div, just before the first float, rather than the top-left just-after the first float).

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 [Sort of unrelated to the actual bug here, per comment 6] (like testcase 1, with zero available space after floats, but with `direction:rtl`)

For symmetry, here's a version of testcase 1, but now with direction: rtl.

All browsers essentially show the same behavior as in testcase 1 (except with the purple div's placement shifting leftwards by 10px, since it overflows its zero-width container and the polarity of that container has changed).

As in testcase 1, WebKit mostly-agrees with us, except for the second part (where they again place the zero-width thing on the opposite side from where we place it). In general, it seems they disagree with us when the float directions are mismatched, and the first float is floating to the "line-end" side).

Comment 5

[Daniel Holbert [:dholbert]]

The spec text here is not especially thorough. This is the relevant text, I think:

The border box of a [...] an element in the normal flow that establishes a new block formatting context [...] must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space.

https://www.w3.org/TR/CSS21/visuren.html#floats

The disagreements between browsers here are simply different choices under the spec's allowance that we "may place it...if there is sufficient space". It seems everyone is in agreement that 0px to the side of a float is sometimes sufficient space for a 0px-wide formatting context; we are just extra-thorough/consistent about that, whereas it seems Chrome and WebKit are a little bit (in my opinion) less consistent about that.

So: I think this is probably "invalid" from a spec-compliance perspective. If there are WPT tests that rely on Chrome's behavior here, we should probably fix those WPT tests (or file bugs on them in their authors' bug trackers).

Comment 6

[Daniel Holbert [:dholbert]]

Aha, per discussion with dshin, there may actually be a bug / spec-violation here. In his original testcase, the 0-width formatting context does indeed "overlap" the upper div (it's positioned inside the bounds of the upper div, though I initially thought it was positioned just-outside the upper div).

Based on code inspection, this might go back to bug 476372 or thereabouts.

Comment 7

[David Shin[:dshin]]

Attachment: test case for zero-width block formatting context div intersecting with an outer div

Comment 8

[David Shin[:dshin]]

New test case attachment 9271117 [details] to clarify - we aren't trying to fit a zero width div into a zero width space; there is "negative" amount of width to fit the now outlined zero-width div. As a result, the zero-width div, despite establishing a block formatting context, intersects the top div.

Comment 9

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

It seems the testcases in comment 0 and comment 7 render differently after Boris fixed bug 1739260. Could any of you confirm this is a dup of bug 1739260?

Comment 10

[Daniel Holbert [:dholbert]]

Yeah, it looks like bug 1739260 fixed dshin's testscases here.

My testcases ("testcase 1" / "testcase 2") haven't changed, but I think that's because they were testing something that's a bit different from what David was actually getting at with this bug (per comment 6 through comment 8).

David: I think you had filed this as an offshoot of your contain:inline-size work for some WPT tests that were still failing -- was that just contain-inline-size-bfc-floats-001.html? (whose failure-annotation boris was able to remove in bug 1739260)

Comment 11

[Daniel Holbert [:dholbert]]

It would perhaps also be worth turning one or both of comment 0 / comment 7 into WPT tests.

The existing WPT testing here (from contain-inline-size-bfc-floats-001.html and from boris's added test) all use some variety of bespoke modern CSS features (either contain:inline-size or aspect-ratio), whereas David's tests here are nicely generalized such that they don't rely on those features, which makes them worth adding to WPT I think (i.e. I wouldn't consider them redundant/duplicative).

David, would you mind doing that? (That could happen as a tests-only patch on this bug here. It's fine that this bug is closed; you should still be able to post a phabricator patch here just as you usually would -- just adding tests, in this case.

Comment 12

[David Shin[:dshin]]

Yep! Looks to be fixed now. I'll add a quick test.

Comment 13

[David Shin[:dshin]]

Attachment: Bug 1763431 - Add test case for div of zero width with `display: flow-root` not intersecting outer floats.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9979516cd462
Add test case for div of zero width with `display: flow-root` not intersecting outer floats. r=dholbert DONTBUILD

Comment 16

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34833 for changes under testing/web-platform/tests

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #14)

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party.

(FWIW, I filed https://github.com/mozilla/relman-auto-nag/issues/1538 to avoid these nags for this sort of patch in the future.)

Comment 18

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/9979516cd462

Comment 19

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot