23322 - [FLOAT] overlapping elements

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[Ben Woodard]

I believe this is a table issue but I might be wrong. Basically if you go to the
web page mentioned above almost everything is fine except there is a problem
where the main text overlaps an inset table element. One interesting thing is
that the browser initially draws it correctly but then decides to reuse the
space allocated to the inset table.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 2

[Mats Palmgren (inactive)]

Bug also occurs with build 2000010608 on Windows NT 4.0 sp6.
The bug seems to be caused by a <SPAN STYLE="float: left"> enclosing the table,
see the testcase.

Comment 3

[ekrock's old account (dead)]

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

Comment 4

[karnaze (gone)]

Troy, I'm not sure if this should go to you or Kipp's bug list.

Comment 5

[troy]

I'll add it Kipp's bug list

Comment 6

[buster]

would be really nice to look at this for beta1

Comment 7

[buster]

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

Comment 8

[buster]

this is mostly a WipeContainingBlock issue, I'll bet, since a block element (the
table) is enclosed in an inline (the span).  As Nisheeth makes progress on that
problem, I'll track this one and see if it just gets fixed as a byproduct of his
work.  Until he is done, it's not a good use of time to look at this yet.

Comment 9

[rickg]

moving all buster m15 bugs to m16.

Comment 10

[buster]

moved to M17, since I won't look at this until after Nisheeth gets the {ib} work 
done.

Comment 11

[buster]

Chris, Marc:  This is a case of a SPAN being given a "float" style attribute.  
So, either it's a duplicate of a bug that Marc already is looking at to force 
display:block on all "float" elements, or it's dependent on that bug as a 
separate {ib} issue.  

Marc, I'm going to assign it to you for now, and when that fix is checked in we 
can re-evaluate.

Comment 12

[Marc Attinasi]

Unfortunately the change to make floaters into block does not fix this one...

I'll take it and investigate.

Comment 13

[Marc Attinasi]

Removing the ALIGN=LEFT from the table in the testcase makes it work fine. 
Karnaze tells me that ALIGN=LEFT makes the table a floater so I tried another 
test case that puts a floated DIV inside of the floated SPAN and the same 
problem shows up. It looks like a general problem with a floated element inside 
of a floated element...

Workaround for the testcase is to not put ALIGN=left on the table in the floated 
SPAN. The URL looks fine - maybe the content changed?

I'll attach another testcase showing the more general problem. 

Comment 14

[Marc Attinasi]

Attachment: Testcase showing the more general problem of floats inside of floats (no tables)

Comment 15

[Marc Attinasi]

Milestone and Component changed.

Comment 16

[Marc Attinasi]

This is probably the same bug as 22563, but I'm marking it dependent for now 
until buster can confirm...

Comment 17

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

The CSS spec says that floats without a 'auto' width should have (or tend
toward, due to min-width rules) a width of 0.  So I think the issue here is
basically the same as the one for which bug 12272 was reopened -- whether an
inner float that overfloats an outer float should affect the flow outside the
outer float.  I tend to think it should, but it needs to be discussed in the CSS
WG or on www-style.  (I've been thinking about that CSS needs a better way of
describing its formatting model by more clearly defining block formatting
context and inline formatting context, and perhaps float formatting context too...)

Comment 18

[Marc Attinasi]

Moving all non-nsbeta3 bugs to future milestone: these will be worked on after 
beta3/rtm.

Comment 19

[Hixie (not reading bugmail)]

Per the last CSS WG face-to-face, floats inside floats should not affect what is
outside the floating ancestor. INVALID.

In the second testcase the SPAN is shrink-wrapping around the float, which the
WG said was not needed, but that is another issue.

Comment 20

[Hixie (not reading bugmail)]

Reassigning to chrisd for verification.

Comment 21

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 22

[Hixie (not reading bugmail)]

reassigning to petersen for verification (I resolved it)