Closed Bug 41306 Opened 25 years ago Closed 25 years ago

problems with percentage widths in unconstrained table cells

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: karnaze)

References

Details

(Keywords: regression, testcase, Whiteboard: [nsbeta2+] 6/22 [fix-in-hand])

Attachments

(4 files)

first testcase (upper cell has explicit width smaller than lower cell)
451 bytes, text/html
Details
second testcase (upper cell is unconstrained)
429 bytes, text/html
Details
using <col> to specify the width of table cells does not allow % width declared children to render correctly.
1.21 KB, text/html
Details
patch to fix the bug
3.88 KB, patch
Details | Diff | Splinter Review
DESCRIPTION: Percentage widths aren't working correctly (if it's possible to say that, since the spec isn't all that clear) in table cells with unconstrained widths. However, they *are* working correctly in table cells with constrained widths that are widened because of other cells in the column. I will attach two testcases that differ only slightly, showing this problem. Both testcases contain tables with two cells in the same column. Both cells contain a DIV element with width of 50%. The lower cell in both has a given width of 600px. In the first testcase, the upper cell is given a width of 300px. In the second testcase, the upper cell is given a width of auto. What happens is, in the second testcase, the DIV in the upper cell acts as if it has a width of auto, whereas in the first testcase, the width of 50% works, with respect to the new width given to the cell. A *nice* solution to this problem would be to make the second testcase work like the first, and reflow the contents of the second cell after its final size has been assigned (but doesn't this happen already? is it not done right?). (Or is the problem that the first cell has been assigned something in the block code that says its width is 'auto', which is then cached? That could be the problem. In fact, it makes more sense, in which case this may be a block reflow bug, except that it also applies to form controls.) That solution would meet user expectations, and I think it would also fit with the spec (although I'm not sure). I'm not sure what other solutions would be allowed by the spec (perhaps even the current one, although it's ugly). STEPS TO REPRODUCE: * load second testcase attached ACTUAL RESULTS: * upper DIV spans whole width of cell EXPECTED RESULTS: * both DIVs (in both testcases) should be 50% of cell width, which should be 600px in both cases. DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-06-01-08-M16 ADDITIONAL INFORMATION: I'm curious how IE5 handles this... (and MacIE5).
*** Bug 41302 has been marked as a duplicate of this bug. ***
For the record, there are other, more complicated, things dealing with percentage widths in table cells that don't work right (e.g., percentage width on something in a one-cell table), but I'm not sure *if* they should work right. The problem here will, I think, solve the bug 41302 and bug 40222.
I'm using Win98 IE5 and I can say that it handles the first case wrong. Instead of resizing the first <div> because of the increase width of 300 to 600 in the table cell, WIN IE5 actually sizes the 50% width to the 300 specified in it cell. So the first <div> renders like if you specified 25% while the second <div> renders as 50%. The second test case renders "correctly".
*** Bug 40222 has been marked as a duplicate of this bug. ***
This bug was actually a regression between the builds of 2000-05-16-08-M16 and 2000-05-17-12-M16 (on Linux). Marking as such.
Keywords: regression
I confirmed that both bugs marked as duplicates of this one regressed between those same builds.
The cell was recently made the containing block (rather than the cell's block to fix other bugs). I'm not convinced yet that the 2nd attachment should behave as suggested. The percentage <div> is inside an auto cell and is therefore ignored. I realize that table's have a bunch of compatibility cases that violate the spec, but in this case Nav appears more in line with the spec than IE.
I think, for consistency, if the second attachment behaves as it does, then the first should have the DIV be 25% the width of the cell.
*** Bug 41387 has been marked as a duplicate of this bug. ***
I still think this is a bug. I noticed that mozilla ignores the width given in either html or css for the <col> tag for calculating percentage widths of children. Is my understanding of the <col> element wrong when I see it as a way to replace having to place repetitive html/css attributes in cells of the same table column (like color, bgcolor, width, align, etc.). What I don't get in this logic so far (for this rendering bug) is how a table cell renders in 800px's (in my testcase) so the table cell must "know" that its 800px's and NOT be able to "tell" its children the width to be able to calculate percentages correctly?
*** Bug 41459 has been marked as a duplicate of this bug. ***
The patch puts things back as of a couple of weeks ago. Nav and IE differ on these test cases and the CSS spec is unclear, but the consensus seems to be that IE has got it right. Also, I'm starting to see duplicate bugs. bug 28811 will need to be reopened, but it could be solve with some changes in the block code. So, since the fix is available, it is more stable to have it than not, and this is a recent regression, I'm nominating for nsbeta2.
Status: NEW → ASSIGNED
Keywords: nsbeta2
Whiteboard: fix-in-hand
Marking nsbeta2+. Will become minus on 6/22
Whiteboard: fix-in-hand → [nsbeta2+] 6/22 [fix-in-hand]
Adding testcase keyword so this doesn't show up on the bugathon search page.
Keywords: testcase
Checked in the patch.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verified with 2000-07-05-09.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: