[css2] css2 spec-text should be updated to clarify how BFC's with negative margins fit alongside floats

[dholbert]

Browser engines have had (and still have to some extent) interop issues around placing BFC's with negative margins alongside floats, with the expectation being unspecified in CSS2.

https://bugzilla.mozilla.org/show_bug.cgi?id=1745310 was filed for a case where Gecko differed from Blink and WebKit, and I've got a lot of notes there. As I discovered when investigating there, Blink and WebKit themselves behave differently in edge cases, like this case:
https://bug1745310.bmoattachments.org/attachment.cgi?id=9255972

(In the second and third black box there, WebKit pushes the teal box down, whereas Blink [and Gecko] keep the teal box on the same line as the fuchsia box.)

After some investigation, I decided the Blink behavior felt the most coherent & explainable, so I ended up fixing Gecko to match Blink (with a few exceptions that turned out to just be Blink bugs which were later fixed). So now Gecko and Blink are interoperable on these tests:
https://wpt.fyi/results/css/CSS2/floats/floats-wrap-bfc-with-margin-001.html
https://wpt.fyi/results/css/CSS2/floats/floats-wrap-bfc-with-margin-002.tentative.html
https://wpt.fyi/results/css/CSS2/floats/floats-wrap-bfc-with-margin-003.tentative.html
https://wpt.fyi/results/css/CSS2/floats/floats-wrap-bfc-with-margin-004.html
https://wpt.fyi/results/css/CSS2/floats/floats-wrap-bfc-with-margin-005.html

WebKit is interoperable on -001 but differs on the rest. As IanK noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1745310#c11 , "WebKit behaves (as far as I can tell) in a way that effectively means that if there are any floats, and any negative margins, they'll always move down to avoid floats."

(In contrast, Gecko and Blink treat negative margins as an inflation of the border-box-size, for this scenario with auto-sized BFCs, which means a negative margin on one side plus a positive margin on the other side may or may not "cancel out".)

We should update the spec to at least require the interoperable behavior that the -001 test expects, and possibly we should spec the expectation for -002 and -003 as well, assuming WebKit folks don't have strong reasons to prefer their behavior or to object to that speccing. (I don't have suggested spec text at this point; mostly filing this bug as a placeholder to request that spec text be written eventually. :) )