With a maximized window, I see overlapping floats in: Test 1 of the above URL, right side, image float (orange) on top of text float (gray). This *may* be related to the fix for weird behavior in bug 1605 on http://www.w3.org/Style/CSS/Test/current/sec5525b.htm which is now correct. I put what I am seeing (which is correct!) at: http://www.fas.harvard.edu/~dbaron/tests/nglayout/5525b_correct The difference results from the 4th line of text in the 3rd paragraph within the table. The position of those images is very strange because of the combination of overlap and negative margins, so the behavior should be different at different window sizes, but what is shown there covers the two alternatives. (Note that the difference is that within the table, the *outer* top (with negative margin) of the second float is below the first float, whereas the first time it is not.) You should watch that page for regressions if you work on this bug, I think.

With current builds (at least with my current tree), the floaters do not overlap each other. However, the text in many of the test cases do overlap the floaters. I assume that this is bad and needs to be fixed.

Assumtion correct. However, I'm still seeing the overlap too.

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

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

Fixing this bug is too dangerous to fix in the beta; moving to just past the beta.

I think this is mostly fixed, except for one really minor problem: the text "This is short" is incorrectly indented within the table.

Updating to default Layout Assignee...kipp no longer with us :-(

Why are you re-reassing layout bugs? Do NOT touch layout bugs. The bugs are assigned to Kipp so they can stay neatly organized until we have a new owner for the block/inline code.

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

Is this bug still a problem? I can't see any using the 1/21 build.

mine! mine mine mine! all mine! whoo-hoo!

I think this bug is fixed too...

Important to fix, but low priority for beta2. Moving to M17.

Nominating nsbeta2,nsbeta3,rtm. Recc. nsbeta2+, falling through to nsbeta3+ and rtm+ if necessary. This is a W3C CSS1 Official Test Suite compliance bug.

Sorry, to clarify: this is not an nsbeta2 stopper, but I'd permit checking in prior to nsbeta2 if we have a fix. Recc. nsbeta2+[some lenient date-], falling through to nsbeta3+ hard stop if not fixed during nsbeta2. This is a W3C CSS1 Official Test Suite compliance bug.

Putting on [nsbeta2-] radar. Not critical to beta2.

As per meeting with ChrisD today, taking QA.

Denying for beta3: bigger problems to solve in very limited time - sorry.

David: I'm having difficulty working out what the problem is here. Could you clarify your bug report? It doesn't help that the W3C test suite is triggering quirks mode...

(...I just realised that I must have understood this bug at some point, since I thought I had run into it. Ahem.)

This URL in this bug was the old version of sec414. URL changed accordingly. I still don't see the bug. Ian, if you agree, please mark FIXED.

Marking WORKSFORME. The only bug I see is the float after "This is short." is too low, but that seems difficult to me (doing it right requires a reflow of previously flowed content). And that problem is definitely [nsbeta3-]. And its another bug anyway. I'm rather confused about why I marked this bug 'hit during nsbeta2 standards compliance testing'. I must have been under the influence of the XBL team's, ah, stimulants or something.

Ian...did you mean to mark this worksforme? Setting to [rtm-]

Er, yes. Geez, what is wrong with me on this bug!