Last Comment Bug 81710 - Empty floats don't take up room [FLOAT] (zero height)
: Empty floats don't take up room [FLOAT] (zero height)
Status: NEW
[Hixie-P4][CSS1-5.5.25] WG (py8ieh:ch...
: css1, testcase
Product: Core
Classification: Components
Component: Layout: Floats (show other bugs)
: Trunk
: All All
: P4 trivial with 6 votes (vote)
: ---
Assigned To: Simon Montagu :smontagu
:
Mentors:
http://www.hixie.ch/tests/adhoc/css/b...
: 225503 (view as bug list)
Depends on:
Blocks: float css2.1-tests
  Show dependency treegraph
 
Reported: 2001-05-18 16:01 PDT by Hixie (not reading bugmail)
Modified: 2014-10-02 12:24 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Don't ignore floats unless both dimensions are zero (2.55 KB, patch)
2014-10-02 10:56 PDT, Simon Montagu :smontagu
smontagu: review? (dbaron)
Details | Diff | Splinter Review

Description Hixie (not reading bugmail) 2001-05-18 16:01:36 PDT
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...
Comment 1 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2001-07-16 22:51:34 PDT
One reason the testcase doesn't work right (at least on Linux) is that
-moz-opacity is broken.
Comment 2 Hixie (not reading bugmail) 2001-07-18 10:33:39 PDT
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...
Comment 3 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2001-07-18 11:03:21 PDT
-moz-opacity seems to be causing some of the things in the testcase to disappear
entirely
Comment 4 Hixie (not reading bugmail) 2001-07-18 15:29:28 PDT
That seems unfortunate.
Comment 5 Kevin McCluskey (gone) 2002-02-27 13:56:53 PST
Reassigning to Alex.
Comment 6 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-03-30 14:15:33 PST
->Layout:Floats
Comment 7 Hixie (not reading bugmail) 2003-11-12 16:31:39 PST
*** Bug 225503 has been marked as a duplicate of this bug. ***
Comment 8 Eli Friedman 2007-05-22 22:19:31 PDT
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.
Comment 9 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2007-05-22 22:49:06 PDT
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.
Comment 10 Eli Friedman 2007-05-22 23:49:54 PDT
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.
Comment 11 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2010-01-29 13:53:13 PST
This was fixed by bug 191448 (on the basis that it got fixed on the 1.9.1 branch between nightlies 2009-02-12-01-mozilla-1.9.1 and 2009-02-12-01-mozilla-1.9.1, i.e., in http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=1af81db46cc5&tochange=110384dabb87
Comment 12 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2010-01-29 13:54:21 PST
Er, sorry, I made that comment on the wrong bug!
Comment 13 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2010-10-15 13:34:50 PDT
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 .
Comment 15 Simon Montagu :smontagu 2014-10-02 10:56:41 PDT
Created attachment 8499021 [details] [diff] [review]
Don't ignore floats unless both dimensions are zero

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)
Comment 17 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-10-02 12:00:26 PDT
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?
Comment 18 Simon Montagu :smontagu 2014-10-02 12:24:01 PDT
(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?

Note You need to log in before you can comment on or make changes to this bug.