Formatting context root with negative margin

[jgraham]

Description
Chromium thinks that a formatting context root stops fitting in a tiny space, when you give it a negative margin

Bug reports
https://bugs.chromium.org/p/chromium/issues/detail?id=1141209
webcompat/web-bugs#60099
webcompat/web-bugs#92024
webcompat/web-bugs#90988
webcompat/web-bugs#77403

Specification
(Something in CSS)

Tests
https://jsfiddle.net/dholbert/ujphfkqz/ (not sure if there's a wpt for this)

This is a bug to include in #9

[foolip]

I've asked @bfgeek who points out that https://bugs.chromium.org/p/chromium/issues/detail?id=1141209 is blocked on twbs/bootstrap#35277 and changing the behavior without that fix is likely to break many sites.

I'm not sure if the situation is symmetrical, if all the same sites are now broken in Firefox?

[jensimmons]

WebKit behaves as Chromium does. Could ya'll file a WebKit ticket as well?

Do we have a sense as to how much this is impacting everyday websites?

[dholbert]

WebKit behaves as Chromium does. Could ya'll file a WebKit ticket as well?

Sure, I'll file a WebKit ticket in a bit.

Do we have a sense as to how much this is impacting everyday websites?

We've gotten many (on the order of ~tens, I think) webcompat.com bug reports that boil down to websites depending on this bug.

I coincidentally just triaged a bug that turned out to be this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1742272

[dholbert]

WebKit bug report: https://bugs.webkit.org/show_bug.cgi?id=233956

[dholbert]

I've asked @bfgeek who points out that https://bugs.chromium.org/p/chromium/issues/detail?id=1141209 is blocked on twbs/bootstrap#35277 and changing the behavior without that fix is likely to break many sites.

I think that Bootstrap issue would be more-likely to get traction if some non-mozilla folks would be willing to chime in over there. So far, the response that we've gotten there seems to have been hesitance to switch away from a hack that they've been using for ages which they perceive as working. I suspect it'd be useful for them to know that other browsers would like to fix this bug, and that they're largely blocked on this bootstrap issue.

(@wisniewskit conveyed something to this effect in twbs/bootstrap#35277 (comment) , but it might be helpful to have other browser vendors back him up on that.)

[karlcow]

Yet another case!
webcompat/web-bugs#95687

to note that adding width: fit-content in the right context fixes the issue.
So at least we could emit site interventions for these sites.

[dholbert]

When starting to write a WPT test with some expectations for this issue, I realized it's more subtle and less-well-defined than I thought, and I found a possible rationalization for the Chromium/WebKit behavior (despite the Chromium/WebKit behavior having initially struck me as bizarre).

So: it may be worth standardizing on & matching their behavior after all, in which case it wouldn't make sense to include this in the #9 bucket after all (at least, not in the form that we were originally thinking).

I've posted some notes on https://bugzilla.mozilla.org/show_bug.cgi?id=1745310#c9 (sorry for verbosity there). I plan to do a bit more investigation and will post an update here if I discover anything that changes my mind further.

[jgraham]

I think it would be an equally successful outcome if we decide that the WebKit/Blink behaviour is the correct one, tighten up the spec if necessary, and change gecko to match. That's still improving interop/compat for users and it seems totally reasonable to measure that progress, even if it's not the implementation change we originally expected.

[karlcow]

Agreed with @jgraham
Yes and given how popular is the Bootstrap library, the chances that we get fixed both the initial library and the websites are low. So we would need to rely on site interventions.

[bfgeek]

@dholbert - I left a reply at https://bugzilla.mozilla.org/show_bug.cgi?id=1745310#c11 but yeah we were writing our LayoutNG implementation for this we basically found that everything was unspecified. We actually ended up following FF in a lot of subtle ways here (see differences between Blink and WebKit now).

[gsnedders]

I think it would be an equally successful outcome if we decide that the WebKit/Blink behaviour is the correct one, tighten up the spec if necessary, and change gecko to match. That's still improving interop/compat for users and it seems totally reasonable to measure that progress, even if it's not the implementation change we originally expected.

Yes; as I think got mentioned in some meeting, the general consensus is that the important thing (especially for the web compat issues) is to gain interop, not what the interop behaviour is. There's clearly a lack of interop here, regardless of what direction we move in.

Filing bugs on the relevant specs, adding tests where there's spec clarity and/or some tentative buy-in to interop behaviour, seems absolutely like a reasonable thing to do here.

[gsnedders]

The tests ended up as /css/CSS2/floats/floats-wrap-bfc-with-margin.

@dholbert did you ever end up filing a csswg-drafts issue for the various vaguely spec'd parts of this? I can't find one looking quickly

[dholbert]

The tests ended up as /css/CSS2/floats/floats-wrap-bfc-with-margin.

My intent was that only the "-001" test (the one where there was preexisting WebKit/Blink interop) would make sense to include in Interop 2022, since it covers the cases that are de-facto required by webcompat (and some related cases that happen to also have interop).

I included .tentative tests 001a, 002, and 003 for completeness to test additional cases that are logical extensions of 001, but I'm not aware of any web content that actually depends on them. They do uncover an area where WebKit and Blink differ, where I think Blink's behavior makes more sense (which is why we largely matched Blink on this), though of course this is currently unspecified.

So IMO it's fine to consider those .tentative tests as being out-of-scope for Interop2022, though if we end up getting interop on them, that's great too. :)

(I do also see tests numbered -004 and -005; those aren't from me. They seem to have been added by Blink folks as part of fixing some inconsistencies that my .tentative tests surfaced for them. They might just be special cases of my .tentative tests, possibly? I think it's fine to consider those ones similarly-tentative, pending-spec-text.)

@dholbert did you ever end up filing a csswg-drafts issue for the various vaguely spec'd parts of this? I can't find one looking quickly

I don't think I did, no; I can take an action to do that.

[gsnedders]

My intent was that only the "-001" test (the one where there was preexisting WebKit/Blink interop) would make sense to include in Interop 2022, since it covers the cases that are de-facto required by webcompat (and some related cases that happen to also have interop).

Per the labelling only -001 is in interop-2022, just wanted to link everything together for anyone trying to find out what happened without following many different links!

[dholbert]

Filed w3c/csswg-drafts#8142 to get the spec updated. (Sorry for the delay on that.)