From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4) Gecko/20010913 BuildID: 2001091313 If, in a two-column table, the first cell has a CSS2 'min-width' property set but has no contents, and the second cell's contents have the CSS2 'white-space: nowrap" declaration, then the min-width declaration is ignored and the first table cell is given the lowest possible width. Reproducible: Always Steps to Reproduce: 1. Access the attached testcase Actual Results: The first table cell of Table 1 is displayed with a width significantly less than the 'mid-width: 200px' CSS2 declaration made on it. This is caused by the 'white-space: nowrap' declaration on the paragraph in the second cell. Observe that Table 2 does not exhibit this problem because it lacks the 'white-space' declaration and so this property inherits a default value of 'normal.' Expected Results: The first cell of Table 1 should be displayed with a width of 200px as declared.

(Note that the attached testcase also, when resized, exhibits the problem described in bug 84422.)

We don't yet support min-width on tables.

karnaze, is it intentional for cells with specifically defined widths to collapse when something like 'white-space: nowrap' forces a table wider than the window? I guess what I'm asking is, is min-width even the issue here?

The cell width will not be honored if the table can be made to fit within the viewport. If min-width were working it would ensure that the width were honored.

Thanks, karnaze. I don't see an bug specifically about implementing min/max-width/height in tables. Do you know of one? This bug ought to depend on it.

Karnaze, is it intentional to collapse table cells in different rows to different widths in order to try to fit the table within the viewport? (I'll attach a testcase.)

Upon further investigation, I believe the problem may be caused by something else. There appears to be a serious bug in table layout when empty cells are involved. In Test Case 2 (to be attached shortly), you'll see a series of 2-by-2 tables with the upper-left cell empty save for whitespace. Each of the four tables lays out incorrectly, in that columns of row 1 are not the same width as cells in the same column of row 2. Can you verify this, Karnaze? If so, I think I need to change the summary of this bug.

Karnaze, the problem can also be seen by accessing [http://greg.tcp.com/mozilla/Apache%20Directory%20Listing/Advanced.html] and narrowing the window until the table becomes too narrow for the viewport.

Note that if you access Test Case 2 and see the bad layout, then go Back, then Forward, layout corrects for some reason.

Greg, you have mentioned a few different things that are separate bugs. But focusing on the problem about the cells in the same column not being the same width, I'm not seeing that unless the viewport is shrunk very small. Also, keep in mind that the doctype on test case 2 is strict, which means that we will likely render differently than IE and Nav.

karnaze, I'm attaching a screenshot of Test Case 2 as seen using Mac/2001100808. I'd be interested to know what this looks like on comparable builds on other platforms. If you can't reproduce on other platforms, perhaps try using a Mac build. As I mentioned, if you load Test Case 2, then go Back, then Forward, then the table layout corrects itself.

I think I've got two cases that exhibit similar behavior if a page is rendered bad because of width and whitespace issues, then is correct in the back the forward steps, correct from a cache reload and correct in composer... see http://store.westerndigital.com/product.asp?sku=1744550 from bug 104012. and www.tweak3d.net from bug 102800. both have similar problems that soundlike they may get fixed by this. I see the bahavior and am currently trying to find the cause. Do you agree?

Similar symptoms, but I guess they are not related to this bug. As I find no code in their pages for either CSS2 items.

-->alexsavulov

looks like is working now. greg: could you test again with a recent build?

Alexandru, test case 2 now seems to work properly, but test case 1 still exhibits the problem. In Table 1, the left, green cell has a min-width of 200px, but since the paragraph in the right, blue cell has white-space set to nowrap, the mid-width on the left cell is ignored. (Is this the desired or intended behavior?)

testcase1 reveals a case where we emulate an IE quirk (wrong behaviour). even though it might not be correct, we do that be cause web authors are making use of that IE "feature". i won't close this bug, but set it to a lower priority

Is that something where we'll emulate the bad IE way in Quirks, but do it right in Standards?

This testcase describes the problem better.

Though there may actually be a problem with min-width, my testcase exhibits a different fundamental problem, and that is that hard widths on table cells are ignored when white-space:nowrap comes into play. Revising Summary to better describe the problem my testcase exhibits. Once it's fixed, I can take a better look at min-width.

->block&inline

In the earlier testcases the 'white-space:nowrap' really just forces a large minimal width for the right cell. An element with a specified large 'width' achieves the same thing, so the bug has nothing to do with 'nowrap' per se.

-> Tables

Is there any browser out there that handles this different than we? IE and opera handle this as we do. WONTFIX ?

no opposition -> gone