320610 - list-items (LIs) near floats wrap block around float (i.e., they use -moz-float-edge)

Status: RESOLVED DUPLICATE of bug 143162

(Core :: Layout: Floats, defect)

Description

[SasQ]

User-Agent:       Opera/8.51 (Windows NT 5.0; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; pl; rv:1.8) Gecko/20051111 Firefox/1.5

Suppose we have three list items <li> and apply "float: left;" to first of them. W3C says that floated box is taken out of normal flow, and the rest of the page shifts up to take his place. The float have to be displayed over the other boxes, only the line-boxes don't hide under the floated box.
In the case of that floated LI, the other LI boxes didn't hide, but takes place by the float's side. This looks like unstandard way. The boxes of elements like DIV hides hormally under the flotat, and only their inline content sets on the side of the float.

The code to reproduce this:

XHTML:
<ul id="NaviTop">
  <li class="Prev"><a href="#">Precious</a></li>
  <li class="Next"><a href="#">Next</a></li>
  <li class="Cont"><a href="#">Contents</a></li>
</ul>

CSS:
#NaviTop { list-style: none;  margin: 0px;  padding: 0px; }
#NaviTop .Prev { float: left; }
#NaviTop .Next { background: #080; }
#NaviTop .Cont { background: #00F; }

With this style the backgrounds should be displayed under the floated LI's box, and the inline contents [links] placed on the side. But the backgrounds don't stretch under the floated LI.

Reproducible: Always

Steps to Reproduce:
1. Make a list with some <li>'s
2. Set background colors for the other list items.
3. Float one list item left or right.

Actual Results:  
The other list items' backgrounds don't stretch under the floated LI's box. This is standards uncompliance, because every floated box have to be taken out from the normal flow, and the boxes following it should behave like if that float wasn't there - stretch to the full width, and only their inline content shouldn't hide under the floated box.

Expected Results:  
Only the inline content of the other LI's shouldn't go under the floated LI. The LI boxes containing it should behave like if there wasn't any box, and stretch on the full width, even under the floated LI's box. Just like with other floated boxes!

In other browsers, like Opera 8.5, and EVEN INTERNET EXPLODER 5.0(!!!), this is displayed correctly. Why not in Firefox? :P

Comment 1

[Ryan Flint [:rflint] (ping via IRC for reviews)]

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

Comment 2

[Ryan Flint [:rflint] (ping via IRC for reviews)]

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

Comment 3

[Elmar Ludwig]

Attachment: reporter's testcase

Reporter's testcase as XHTML with inline style.

Comment 4

[Elmar Ludwig]

This looks fine to me, actually.

> Only the inline content of the other LI's shouldn't go under the floated LI.
> The LI boxes containing it should behave like if there wasn't any box, and
> stretch on the full width, even under the floated LI's

Where did you get that impression? LI establishes a new block formatting context, and section 9.4 of the CSS spec states for such a case that:

"unless the box establishes a new block formatting context (in which case the box itself may become narrower due to the floats)"

Comment 5

[Erik Fabert]

Just another symptom of bug 143162, I think.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

No, LI does not establish a new block formatting context.

Comment 7

[Ryan Flint [:rflint] (ping via IRC for reviews)]

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

Comment 8

[SasQ]

(In reply to comment #4)
> Where did you get that impression?

CSS Specs, section 9.5 [Floats]:
"Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist."

That means:

.----------------<li.Next>----------------------.
| .--<float>--.  LI.Next inline content         |
:-| LI.Prev   |---------------------------------:
| | inline    |  LI.Cont inline content         |
'-| content   |---------------------------------'
  '-----------'

[quite unproportial ASCII-Art]. The LI's following the float
should behave like if the float wasn't there, because it is
out of normal flow. Only inline boxes are pushed out from
behind the float. But not:

               .-<li.Next>----------------------.
  .--<float>--.| LI.Next inline content         |
  | LI.Prev   |:--------------------------------:
  | inline    || LI.Cont inline content         |
  | content   |'--------------------------------'
  '-----------'

because in that way the float pushes out the whole
adjacent boxes, like if the float WERE there!
If you still have doubts with this, substitute <ul>
and <li> with simlpe <div>'s and the visual effect
will be different: the right way.

> LI establishes a new block formatting context,

Yes, establishes, but for its inner boxes! :P
Establishes a new containing box for inner boxes, so
the inner boxes stretches max to the boundaries of LI.
But this have nothing to do with OUTER boxes, like
the rest of LI's in UL.

> and section 9.4 of the CSS spec states for such
> a case that:
> "unless the box establishes a new block formatting
> context (in which case the box itself may become
> narrower due to the floats)"

This states about the box height, when it has floats
inside. The floats aren't considered then, when the
containing box's height is computed.

Comment 9

[SasQ]

(In reply to comment #5)
> Just another symptom of bug 143162, I think.

Yes, i think that too. That one is "inversed" - the list items aren't floated. But the problem is the same: list items behaves unconformant with floats. It looks like the list items wasn't floats, but inline or sth. In inline formatting boxes are set side by side, like in those examples. In float formatting, it may overlap [excluding only the inline contents, which can't hide under the float and is set by side of the float].

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It doesn't matter that the float is a list-item.  It matters that the things wrapping around it are.  In this case, both are, but what causes the bug is the latter.

*** This bug has been marked as a duplicate of 143162 ***