Bug 3564 - width of nested table not reduced by floating element in same cell if width="100%" parameter set
Summary: width of nested table not reduced by floating element in same cell if width="...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: 412
Hardware: Macintosh OS X 10.4
: P3 Normal
Assignee: Nobody
URL: http://www.whiterose.org/test/float_t...
Keywords:
: 8539 12508 17584 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-16 04:57 PDT by Michael Croft
Modified: 2010-04-06 16:38 PDT (History)
8 users (show)

See Also:


Attachments
source of page showing float nested table error (2.24 KB, text/html)
2005-06-16 04:59 PDT, Michael Croft
no flags Details
another test case indicating the differences between a nested div and a nested table (1.14 KB, text/html)
2009-06-30 16:42 PDT, Dirk Pranke
no flags Details
test case for plausible renderings (3.49 KB, text/html)
2009-07-01 16:33 PDT, Dirk Pranke
no flags Details
illustration of different plausible renderings (3.47 KB, text/html)
2009-07-01 16:35 PDT, Dirk Pranke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Croft 2005-06-16 04:57:45 PDT
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.
Comment 1 Michael Croft 2005-06-16 04:59:41 PDT
Created attachment 2387 [details]
source of page showing float nested table error
Comment 2 Chris Petersen 2005-06-16 15:42:43 PDT
I can reproduce this issue using TOT WebKit and Safari 2.0 (v412) under 10.4.1 (8B15).
Comment 3 Eric Seidel 2005-12-27 23:59:38 PST
Beth was hacking in this area recently.  It still looks wrong on TOT however.
Comment 4 Joost de Valk (AlthA) 2006-02-13 15:36:15 PST
Changing component
Comment 5 Alexey Proskuryakov 2006-04-24 21:38:36 PDT
*** Bug 8539 has been marked as a duplicate of this bug. ***
Comment 6 Derk-Jan Hartman 2007-09-20 17:13:05 PDT
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
Comment 7 Derk-Jan Hartman 2007-09-21 17:29:10 PDT
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).
Comment 8 mitz 2008-02-27 22:22:16 PST
*** Bug 17584 has been marked as a duplicate of this bug. ***
Comment 9 mitz 2008-02-27 22:23:25 PST
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.
Comment 10 mitz 2008-02-28 13:24:06 PST
*** Bug 12508 has been marked as a duplicate of this bug. ***
Comment 11 Dirk Pranke 2009-06-30 16:42:23 PDT
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.
Comment 12 Dirk Pranke 2009-06-30 16:43:19 PDT
Taking over the bug from Beth, if that's okay ... 
Comment 13 Dirk Pranke 2009-07-01 16:33:25 PDT
Created attachment 32156 [details]
test case for plausible renderings

test case showing the various plausible interpretations of nested tables and floats.
Comment 14 Dirk Pranke 2009-07-01 16:35:00 PDT
Created attachment 32157 [details]
illustration of different plausible renderings
Comment 15 Dave Hyatt 2009-07-02 10:24:34 PDT
You could resurrect the code we used to have to do this (and probably limit it to strict mode).
Comment 16 Tim McConnell 2009-11-20 01:05:16 PST
This behavior affects contentEditable regions as well.
Comment 17 Dirk Pranke 2010-04-06 16:38:09 PDT
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.