A simple table that contains a fixed-width floating table ends up too wide because the floating table reports back a width that is larger than the specified width. However, by the time second pass reflow is done the floating tables width is correct. Here is the sample content (note: the actual images don't matter; use your own...) <html> <body> <table width=100% border=2> <tr><td> Y <table cellspacing=0 cellpadding=0 width=224 border=0 align=right> <tr> <td rowspan=4 width=10><img src="bluedot.gif" width=10 height=1></td> <td width=214><img src="woofer.gif" width=214 height=163 border=0 alt="screen shot"></td> </tr> <tr> <td height=8><img src="bluedot.gif" width=1 height=8 alt=""></td> </tr> <tr> <td><font size=-2 face="MS Sans Serif, Helvetica" color="#666600">CleanSweep Deluxe tracks the files you use most often, then recommends rarely used ones for you to delete.<br></font></td> </tr> <tr> <td height=8><img src="bluedot.gif" width=1 height=8 alt=""></td> </tr> </table> <p>X</td></tr></table> </body> </html>
Kipp, I think this is the bug you asked me to reassign to you.
Chris: I have more data for you on this bug, and I'm going to bounce it back to you (sigh). I've determined the source of the trouble. In particular, if a table contains a floating table then during pass1 reflow the inner floating table returns a max-element-size that assumes its width is unconstrained EVEN WHEN IT HAS A WIDTH=xxx parameter. Because it returns a large size, the result is that the outer table ends up too wide. What I did to prove this is to instrument the block code and have it log the max-element-size information that it combines to produce its returned value. And then I changed the simpel test in the bug report so that the text in the CENTER tag is longer. And low and behold the inner floating table reported a larger max-element-size than before.
chrisd, is this Linux specific?
Moving to M6.
Moving to M8.
I recall the above test case behaving as described above. However, a few weeks ago, I noticed that the 'over-width' behaviour was gone. Checking again with a jun23 build win95, this lays out fine. So, is this FIXED|WORKSFORME, or am I missing something in kipp's description.
this renders exactly the same in mozilla as it does with communicator 4.6 (m7, linux). email@example.com, july 1
Moving to M9.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
I remember fixing this a long time ago.
Using 8/5 Apprunner on Linux, verified bug fixed.
You need to log in before you can comment on or make changes to this bug.