Compare with 4.xx. Look at "Graphics Guide".

Yep, that first attachment looks pretty bad. However, the bug is less severe than it first appears. The second attachment above shows a simplified form of what happens. The is a fixed-width DIV which contains two fixed-width tables, the first floated right, the second floated left, and some other flow elements including a UL block. The widths of the two floats are such that (plus m/b/p) they are wider than the containing DIV. They fit in Nav4.x, but perhaps they really shouldn't. (Note: the original HTML used a containing TABLE instead of a containing DIV, but the behaviour is identical). So this means that the two floats are vertically offset (instead of side by side as the author intended). Some of the flow goes above the left float, and the rest starts to the right of the left float. *But* the part that goes to the right is the UL block, and it really is too wide to fit, thus popping outside the DIV, leaving a big white blank space below the left float, and generally looking "bad". Passing to troy/Layout (likely one the way to 'kipp').

We're doing what the CSS2 spec says which is to move a floater down when it doesn't fit in the available space. Obviously that's not what Navigator did, and so there's a compatibility issue. Re-assigning to Kipp's bug list

(Just for future reference, whenever buster comes by): I don't have a particular issue with the vertical stacking of the floats. What I really think is wrong is the the UL (display: block) is being placed into the flow where it's min-width is greater than the available space. [Although side note -- I don't understand why td[align="left"] and td[align="right"] have margin-right: 4px; and margin-left: 4px; respectively but perhaps that is a compatibility thing too).

We are not guaranteed to be bug-compatible with Nav 4.x, and Nav is not standards compliant with regards to this page. So it's unlikely we'll fix it any time soon, if at all. Changed summary to reflect the real problem. In response to 3jrgm@qlink.queensu.ca, I'll take a look at the UL issue as time allows.

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

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

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

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

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

eric, could you ask the nice folks at tomshardware to fix their html? The error is they have floats inside a container that is narrower than the sum of the floats, so the floats get vertically stacked as per CSS1 spec. This is Nav behavior that would be painful to emulate in quirks mode.

setting to M18 to look at how bullets and floats interact.

Marking compat and WONTFIX, because: - we are supporting the standard, and - emulating that Nav4.x bug would require significant eng time that would be better spent on fixing standards-compliance bugs, and - I don't see evidence that this layout is widespread on the Internet, and - if we're going to make beta2 and FCS, we need to start making tough calls. Have emailed tomshardware.com. Steve--if you really want to, you're free to reopen, but I'd say wait to do that until you're less doomed with standards-compliance bugs. Sound good? Others--if you think this should in fact be fixed, you need to provide evidence that this kind of layout is widespread on popular Internet sites in order to justify allocating the resources necessary for emulating a 4.x bug in quirks mode. Thanks!

Oops, just realized that your intent may have been to keep this bug open to deal solely with the FLOAT/bullets question as opposed to the FLOAT stacking issue. Apologies if I too-hastily closed. If you decide to reopen for tracking that question, let's just make sure we're all (including me ;-> ) on the same page about what this bug is tracking and what we might/won't fix.

Leave this as WONTFIX. I've split off the bullet problem into bug 35666.

*spam* changing qa contact from nobody@mozilla.org to me (BlakeR1234@aol.com) on 121 open or resolved (but not verified) bugs. sorry for the spam everybody, but most of these bugs would just remain dormant and not checked by QA otherwise. I'm not sure how so many bugs have nobody as their QA contact, but I suspect this is the fault of some sort of bugzilla corruption that happened at some point (most of these bugs are in the 20000-26000 range, and I don't see where in the activity log that QA contact explicitly changed to nobody@mozilla.org) Anyways, sorry again for spam. If you really get annoyed, I'm usually available in #mozilla on IRC for torture.

vrfy wontfix