Bug 3564 – width of nested table not reduced by floating element in same cell if width="100%" parameter set

• Component: Tables
• Status: RESOLVED CONFIGURATION CHANGED

[Michael Croft]

Overview: 
If a table cell has floating elements and a nested table, the inner table is properly offset but the wrong 
width if the width="100%".  It does not seem to be reduced to fit the available space.  If there is no 
width property of the inner table, the table displays as expected

This bug was introduced in Safari 1.1 and did not occur in Safari 1.0.  

Steps to Reproduce:
1: Generate a test page using the following nested table structure (or use the reduction on linked page, 
which w3c's online validator says is valid)

2: display error is in the first case shown in reduction, with different behavior in the second case where 
the inner table width parameter is not set.

table width=600
 tr
  td
   span style=float:left;
    img /
   /span
   span style=float:right;
     img /
   /span
  table width=100%
   tr td some content that is wide enough that it has to wrap (Lorem Ipsum...) /td /tr /table
/td /tr /table

Expected results:
The inner table is both shifted and constrained inside the two floating elements with or without the 
width parameter being set.
Actual results:
The inner table is both shifted and constrained inside the two floating elements without the width 
parameter being set, but is only shifted and not constrained when the width parameter is set.

[Michael Croft]

Created attachment 2387 [details]
source of page showing float nested table error

[Chris Petersen]

I can reproduce this issue using TOT WebKit and Safari 2.0 (v412) under 10.4.1 (8B15).

[Eric Seidel (no email)]

Beth was hacking in this area recently.  It still looks wrong on TOT however.

[Joost de Valk (AlthA)]

Changing component

[Alexey Proskuryakov]

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

[Derk-Jan Hartman]

As a note. I have noticed the same issue on several wikipedia pages. But more importantly, I have also seen the same effect on columned div's I guess the new column options for divs are somehow partly based on tables but they definitely at least share the same problem when it comes to floats

[Derk-Jan Hartman]

Oh, and Firefox has a similar problem. Both FF and Safari do not recalculate the width of the table. However FF repositions it's table horizontally if it is aligned in the centre, whereas Safari keeps it's table centered. So in FF if the table is 80% and the float element is 20px, both do not collide as long as 20% >= 20px, For Safari you need 10% >= 20px.

Opera behaves as if it is applying a clear:both to the table (at least prevents a collision, which can severely affect readability).

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

See more test cases attached to bug 17584. Note that while Firefox 2 sizes the table to fit alongside the float, Firefox 3 and Opera actually size the table at 100% of the containing block and push it down below the float. I think WebKit has a quirk that prevents tables from clearing floats in all but strict mode.

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

[Dirk Pranke]

Created attachment 32100 [details]
another test case indicating the differences between a nested div and a nested table

I'm looking at this bug now ... the "correct" behavior is a bit unclear. From my best reading of the CSS2 specs (in particular section 9.5 on floats, http://www.w3.org/TR/CSS2/visuren.html#floats ), divs a1 and a2 should be aligned on top of each other (hence a partially opaque blue box on top of a purple box), with the text line box inside a2 appearing to the right of a1.

However, b2 should either be completely to the right of b1, or it should clear b1 (and therefore be below it):

"The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower." 

So, it appears that the correct behaviour is undefined, and the UA can choose to either shrink the width of the table, leave the width at 100% and clear the float, or leave the width at 100% and overflow. IE 8 and Opera clear the float, Safari 4, Chrome, and Firefox 3.1 overflow. No one shrinks the width.

[Dirk Pranke]

Taking over the bug from Beth, if that's okay ... 

[Dirk Pranke]

Created attachment 32156 [details]
test case for plausible renderings

test case showing the various plausible interpretations of nested tables and floats.

[Dirk Pranke]

Created attachment 32157 [details]
illustration of different plausible renderings

[Dave Hyatt]

You could resurrect the code we used to have to do this (and probably limit it to strict mode).

[Tim McConnell]

This behavior affects contentEditable regions as well.

[Dirk Pranke]

I'm not working on this now nor do I expect to be in the near future, so I am disclaiming ownership in case someone else wants to pick this up.

[Brent Fulgham]

At this point, all major browsers appear to render the same way (option #3 in the test case).