Example: <table width="500px" border="1"> <tr> <td style="width: 300px;">test 1</td> <td width="100%">test2</td> </tr> </table> <table width="500px" border="1"> <tr> <td style="width: 300px;">test 3</td> <td>test4</td> </tr> </table> In the first table, the first cell should take up the 300px it specified, and the second cell should take up 100% of the remaining width of the container.

>In the first table, the first cell should take up the 300px it specified, and the second cell should take up 100% of the remaining width of the container. and this is specified where that it should do this? Especially how does that fit with http://www.w3.org/TR/CSS21/tables.html#width-layout?

From the section you linked: "If the specified 'width' (W) of the cell is greater than MCW, W is the minimum cell width." And: "A percentage value for a column width is relative to the table width. If the table has 'width: auto', a percentage represents a constraint on the column's width, which a UA should try to satisfy. (Obviously, this is not always possible: if the column's width is '110%', the constraint cannot be satisfied.)" I interpret this to mean that in the sample I gave the specified 'width' should be the minimum cell width. The specifiction of 100% "cannot be satisfied." The spec seems ambiguous, in that the second passage I quoted uses the term "constraint" without specifying that it is constraining the maximum, not the minimum. I believe the intent of the spec is to constrain the maximum.

Ah I overlooked that the cells are in the same row. The cell width specification is not correct in the first case, so the browser goes into its fixup code (the GIGO principle, garbage in - garbage out). And we can do whatever we want as this is not covered by any spec that I know. We render this identical to IE and Opera, which have followed the NN.

Why is the first width specificatin not correct? If it is not correct in the first case it shouldn't have been applied correctly in the second. The only difference between the two cases is that the first has a non-css width specifier on the second cell.

The example I posted at first didn't properly demonstrate the problem. I was given a better example: http://dkime.com/dochope.html This is taken from the PayPal shopping cart application. Go to http://dochope.com and click the "View Cart" to see the original. The link above is the simplified test case. In the new example: * The first table uses a style for pixel width in the first cell and html for percent width in the second * The second table uses html for pixel width in the first cell and html for percent width in the second * The third table uses a style for pixel width in the first cell and a style for percent width in the second The second table is the only one that displays as you would expect. I wouldn't reopen this bug, except that the PayPal code is out of my control, and it gets thousands of unique visitors a day -- not just my site, everyone using PayPal shopping cart.

Thats the ugly nowrap fixed width quirk hack, and we dont apply that hack for style widths but we do it for html widths

the code at http://lxr.mozilla.org/seamonkey/source/layout/tables/nsTableCellFrame.cpp#230 interacts with http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLTableCellElement.cpp#399

Drew you are relying on illegal behaviour here. Its an error that origined from NN but has nothing to do with a spec. So this if ever will only work in quirks mode (http://www.mozilla.org/docs/web-developer/quirks/)

I wish I were the one relying on that behavior. As I said, this is the PayPal shopping cart page. Is there any process that seems to work for requesting someone fix their code to standards?

This patch should first of all make the nowrap thing a quirk. Second it should increase the min table cell width to a fixed width if nowrap in specified. IE resets the nowrap attribute regardless how the fixed width has been specified via html or the style system. This patch resets the nowrap only for the html width but increases the table cell width. This should also help in couple of those img. wrap scenarios.

Comment on attachment 170731 [details] [diff] [review] patch So what is the quirk? That in quirks mode table cells with fixed HTML width set don't have the "nowrap" attribute apply to actually prohibit wrapping? And that table cells with the nowrap attribute set and a width specified behave weirdly? If that's correct, r+sr=bzbarsky...

fix checked in

*** Bug 323310 has been marked as a duplicate of this bug. ***