102847 - specified (minimal) width on table cell is not respected

Status: RESOLVED WONTFIX

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

Description

[Greg K.]

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.

Comment 1

[Greg K.]

Attachment: Test case that demonstrates the problem

Comment 2

[Greg K.]

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

Comment 3

[karnaze (gone)]

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

Comment 4

[Greg K.]

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?

Comment 5

[karnaze (gone)]

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. 

Comment 6

[Greg K.]

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.

Comment 7

[Greg K.]

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.)

Comment 8

[Greg K.]

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.

Comment 9

[Greg K.]

Attachment: Test Case 2, exhibiting empty table cell width problem.

Comment 10

[Greg K.]

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.

Comment 11

[Greg K.]

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

Comment 12

[karnaze (gone)]

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. 

Comment 13

[Greg K.]

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.

Comment 14

[Greg K.]

Attachment: Screen capture of Test Case 2 on Mac/2001100808

Comment 15

[[not reading bugmail]]

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?

Comment 16

[[not reading bugmail]]

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

Comment 17

[karnaze (gone)]

-->alexsavulov

Comment 18

[Alexandru Savulov]

looks like is working now.

greg:

could you test again with a recent build?

Comment 19

[Greg K.]

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?)

Comment 20

[Alexandru Savulov]

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

Comment 21

[Greg K.]

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

Comment 22

[Greg K.]

Attachment: Improved testcase

This testcase describes the problem better.

Comment 23

[Greg K.]

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.

Comment 24

[Greg K.]

Attachment: Refined testcase

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->block&inline

Comment 26

[Mats Palmgren (inactive)]

Attachment: Testcase, not using 'nowrap'

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.

Comment 27

[Mats Palmgren (inactive)]

-> Tables

Comment 28

[Bernd]

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

WONTFIX ?

Comment 29

[Bernd]

no opposition -> gone