12272 - [FLOAT] clear not clearing previous floating siblings of ancestors

Status: VERIFIED WORKSFORME

(Core :: Layout, defect, P2)

Description

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

DESCRIPTION:  The CSS clear property doesn't work when the floats to be cleared
are children of previous siblings rather than previous siblings.  I think clear
should increase margin-top to clear past any floats in the same flow - i.e., the
flow of the body, a float, or an absolutely positioned element.  (CSS is a
little unclear on these exceptions, but I think they should be kept to a
minimum.)

STEPS TO REPRODUCE:  Load attached test case.

ACTUAL RESULTS: "This second div should clear the float" appears right under the
first div and underneath (z-wise) the float.

EXPECTED RESULTS:  The second div should clear the float.

DOES NOT WORK CORRECTLY ON:
 * Linux, viewer, 1999-08-20-13-M10

ADDITIONAL INFORMATION:
Info on 'clear': http://www.w3.org/TR/REC-CSS2/visuren.html#flow-control

Comment 1

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

Attachment: testcase described in bug.

Comment 2

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

This problem seems only to happen some of the time.  Attaching a test case where
it does work, except it flashes an incorrect position on initial load...

Comment 3

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

Attachment: testcase that almost works...

Comment 4

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

Actually, the problem was that I switched to a debug build that was a few days
older so I could use visual debugging.

Now, comparing two optimized builds:
 * In 1999-08-16-08-M9, the elements flash an incorrect position initially, but
then go to the right place.
 * In 1999-08-20-13-M10, the elements stay in the incorrect position until the
window is resized.

The incorrect position is that one element and its children ignore floaters that
are descendants of previous children (in both cases).  However, in the first
testcase, its the element itself that is shown to be ignoring the floaters that
are descendants of its previous sibling.  In the second testcase, it's both that
element *and* the floating children of that element (labeled four, five, and
six) that ignore the existence of the prior floats.

So this is, to some degree, a regression in the last for days, but you really
shouldn't flash the incorrect positioning to start with, so...

Comment 5

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

s/previous children/previous siblings/

Comment 6

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

ALSO DOES NOT WORK CORRECTLY ON:
 * Windows, apprunner, 1999-08-24-09-M10

Marking All/All

Comment 7

[kipp]

It's just an incremental reflow bug; I haven't touched that logic since before
june, so you are just witnessing timing bugs. Since a resize fixes the problem,
I've removed the "{css}" marker and left the "{inc}" marker in place.

Comment 8

[kipp]

With a current build, both attached test cases layout properly the first time
and subsquently.

Comment 9

[Chris Petersen]

This problem appears to be fixed in the Sept 16th build. Marking as verified
fixed.

Comment 10

[Hixie (not reading bugmail)]

I just ran into a case where this is still failing:
   http://www.bath.ac.uk/%7Epy8ieh/m/clear-sibling-child.html
Reopening. Note, this is not an incremental bug, since resizing the window
does not affect the rendering. Adjusting markers appropriately.

Comment 11

[leger]

M11 out the door...moving to M12.

Comment 12

[leger]

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

Comment 13

[troy]

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.

Comment 14

[buster]

mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.

Comment 15

[Hixie (not reading bugmail)]

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...

Comment 16

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 17

[buster]

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

Comment 18

[Hixie (not reading bugmail)]

I just ran into this again. See the second test of this page:
   http://www.bath.ac.uk/%7Epy8ieh/m/clear-list-item.html

Comment 19

[buster]

the simple test cases work with a new fix in my tree, but the two in the URL 
field do not

Comment 20

[buster]

with a fix I have in my tree, the attached test cases work but the main URL is 
still broken.  When I check in my fixes late next week, we'll need a new 
testcase.

Comment 21

[rickg]

moving all buster m15 bugs to m16.

Comment 22

[buster]

this won't make M16, moving to M17

Comment 23

[timeless]

Buster, did you check in that fix? Does this still need a new testcase? the 
urls listed still don't render according to the text descriptions.

Comment 24

[ekrock's old account (dead)]

correctness. dbaron, what would be the impact of not fixing this? Are we aware
of actual web pages that depend on this? If not, what kinds of things would this
bug block content developers from doing?

Comment 25

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

If the problem is still as originally described, then clear is broken in all but
the most simple cases, and it would probably affect real world pages
significantly.  However, it probably should be retested considering the bug is
11 months old...

Comment 26

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

The problem for which Ian reopened this bug is really a separate issue from the
original one.  In fact, our current behavior may even be correct (I'm not sure).
 It's not clear to me whether a float should establish a totally new float
formatting context (my term -- I want this formalized in CSS3), and the only
thing that should matter outside of the float is the bounds of the float, or
whether floats within that float should have to be considered in outer float
formatting contexts?  If the interior floats were blocks, they clearly wouldn't
matter.  But if they're floats?  Ian??  (Note that this issue could be more
dangerous for authors unintentionally causing overlap in its horizontal
implications.)

Comment 27

[Hixie (not reading bugmail)]

Good question. Who is Netscape's W3C contact? This needs an answer from the CSS
working group.

Comment 28

[Hixie (not reading bugmail)]

As per meeting with ChrisD today, taking QA.

I will investigate the issue with the WG shortly.

Comment 29

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

See bug 23322 and bug 27997 for similar issues (though horizontal).

Comment 30

[Marc Attinasi]

Denying approval for beta3: too many bugs, too little time, so this one has to 
be handled in the future.

Comment 31

[Hixie (not reading bugmail)]

http://www.bath.ac.uk/%7Epy8ieh/m/clear-sibling-child.html is INVALID, per WG
meeting. Floats create new formatting contexts, nested floats should not in any 
way affect content outside their floated ancestor.

http://www.bath.ac.uk/%7Epy8ieh/m/clear-list-item.html IS valid, though, and 
we still fail it. EVEN INTERNET EXPLORER 5 GETS THIS CORRECT. Not fixing this
will basically prevent the use of 'clear' (a CSS1 property) in all but the
simplest of cases. Not only will the WaSP have a field day with this, but real
world websites will have to use silly hacks to get around the issues.

(Note that there is another bug shown by that page, which is that floated 
list-items should still have their bullet/number, per the last CSS WG face-to-
face. That is a separate bug though, and much less important.)

Comment 32

[Hixie (not reading bugmail)]

I know we still do not have enough resources to get this fixed. However:

Removing [nsbeta3-] to put this floater bug (and 3 others) back onto the 
developer radar, as per suggestion by Gerardo.

Comment 33

[Henrik Lynggaard Hansen]

nominateing for rtm since this is a compliance issue

Comment 34

[buster]

changed (beta3 minus per triaging) to [nsbeta3-] so searches work correctly

Comment 35

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

Ian - could you explain the issue for which this bug is currently open?  I don't
see a CSS1 compliance issue here -- or, for that matter, anything.

Comment 36

[karnaze (gone)]

Marking rtm-.

Comment 37

[Gervase Markham [:gerv]]

Hixie:

It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note. If anyone feels it does, can they please draft one and then 
nominate with the relnote-user or relnote-rtm strings in the Status Whiteboard.

Thanks :-)

Gerv

Comment 38

[Hixie (not reading bugmail)]

Oops, missed David's comments. The only remaining issue I see now is just the 
float numbering problem, we'll deal with that later.

Comment 39

[Hixie (not reading bugmail)]

Reassigning to chrisd for verification.

Comment 40

[Christine Hoffman]

Using 1/22 trunk build and 1/24 MTEST build, with 'valid' testcase from 8/25 
comments, verified bug fixed.