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.
Created attachment 2387 [details] source of page showing float nested table error
I can reproduce this issue using TOT WebKit and Safari 2.0 (v412) under 10.4.1 (8B15).
Beth was hacking in this area recently. It still looks wrong on TOT however.
Changing component
*** Bug 8539 has been marked as a duplicate of this bug. ***
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
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. ***
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.
Taking over the bug from Beth, if that's okay ...
Created attachment 32156 [details] test case for plausible renderings test case showing the various plausible interpretations of nested tables and floats.
Created attachment 32157 [details] illustration of different plausible renderings
You could resurrect the code we used to have to do this (and probably limit it to strict mode).
This behavior affects contentEditable regions as well.
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.
At this point, all major browsers appear to render the same way (option #3 in the test case).