An empty float takes up no room for some reason, even if it has an explicit width. See http://www.hixie.ch/tests/adhoc/css/box/float/007.xml for a testcase. dbaron says we should change the spec...

One reason the testcase doesn't work right (at least on Linux) is that -moz-opacity is broken.

Broken in what way? Assuming it doesn't affect _layout_, then the testcase will still work. If it affects layout then yes, that is indeed broken, and I should file a new bug...

-moz-opacity seems to be causing some of the things in the testcase to disappear entirely

That seems unfortunate.

Reassigning to Alex.

->Layout:Floats

*** Bug 225503 has been marked as a duplicate of this bug. ***

I'm pretty sure this is invalid; the highest the float can go is the location of the zero-height float, and then there's nothing stopping the float from sliding all the way to the right.

It's not clearly invalid (except that the test relies on old z-ordering rules). The thing stopping the float from sliding all the way to the side is the zero-height float.

http://www.w3.org/TR/CSS21/visuren.html#floats First off, the use of the terms "lower than" and "to the right of" is a bit confusing; "to the right of" is supposed to mean "not to the left of" and "lower than" is really supposed to mean "not higher than". In other words, rule 2 is specifying that the distances between the edges must be nonnegative, but not necessarily positive. (Requiring it to be positive would be wrong because it would mean two 50px floats in an 100px container couldn't fit next to each other.) It's pretty easy to show both renderings satisfy rules 1-7. Supposing both the current and proposed renderings satisfy rules 1-7, and both renderings have the same top edge for the second float (so there's no rule 8 distinction), the current rendering is better according to rule 9. Therefore, unless the rules are wrong, this bug is invalid.

Er, sorry, I made that comment on the wrong bug!

layout/reftests/floats/zero-height-float.html is a somewhat less debatable testcase; it's also in the CSS 2.1 test suite as html4/floats-zero-height-wrap-002.htm and xhtml1/floats-zero-height-wrap-002.xht .

Test [RC6]: http://test.csswg.org/suites/css2.1/latest/html4/floats-zero-height-wrap-002.htm Correct reference test link [RC6] for such test: http://test.csswg.org/suites/css2.1/latest/html4/floats-zero-height-wrap-001-ref.htm Also, Test [nightly-unstable]: http://test.csswg.org/suites/css2.1/nightly-unstable/html4/floats-zero-height-wrap-002.htm Current reference test link [nightly-unstable]: http://test.csswg.org/suites/css2.1/nightly-unstable/html4/reference/floats-zero-height-wrap-001-ref.htm

I fixed this accidentally while working on bug 1062963. The "fix" there broke other stuff (see bug 1076986) but the effect can be separated out, like so. N.B. This fixes the test from comment 13, but not Hixie's original testcase (which we render the same as Chrome)

Does this improve or worsen compatibility with other browsers? And is the correct behavior to have the test you've changed it to, or to remove the condition entirely?

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #17) > Does this improve or worsen compatibility with other browsers? And is the > correct behavior to have the test you've changed it to, or to remove the > condition entirely? Hmm, I was hoping you would help me with just those questions! Do you remember what cases the "compatibility" in the original comment referred to?

Looking at https://wpt.fyi/css/CSS2/floats/floats-zero-height-wrap-002.xht (which dbaron wrote) Chrome, Edge, and Safari all seem to allow non-zero-width/zero-height floats to take up space, though I don't know how zero-width/zero-height floats are handled in other browsers, which we should test too.

I think there may have been some discussion of zero-height floats in the CSS WG sometime in the past few years.