I Steps: Go to http://b.walla.co.il/ Scroll to the center of the webpage. II Issue: Notice the misalignment in one of the table columns as well as its text in center column. III Conclusion: The issue is caused by the table-layout:fixed style and missing width of the outermost table. According to the W3C docs, in a fixed table layout, the horizontal layout only depends on the table's width and width of the columns. In this case, IE/FF3/Safari seem to be getting the computed width correct if the width is not explicitly specified. IV Other browsers: FF3: ok Opera: ok IE 7: ok V Nightly tested: 30236
Created attachment 19423 [details] screenshot
Created attachment 19424 [details] reduction
Reduced test case: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20HTML%3E%3CHTML%3E%3CHEAD%3E%3Cstyle%20type%3D%22text%2Fcss%22%3ETABLE%20%7BTABLE-LAYOUT%3A%20fixed%3B%20height%3A1em%3B%20background-color%3Alime%3B%7D%3C%2Fstyle%3E%3C%2FHEAD%3E%3CBODY%3E%3Cp%3Ethe%20table%20is%20100%25%20wide%20in%20Gecko%20and%20Trident.%20Presto%20and%20Webkit%20renders%20it%20tiny.%3CTABLE%3E%3CTR%3E%3CTD%3E%3CTABLE%20width%3D%22100%25%22%3E%3C%2FTABLE%3E%3C%2FTD%3E%3C%2FTR%3E%3C%2FTABLE%3E%3C%2FBODY%3E%3C%2FHTML%3E
Per the paragraph: 'The table's width may be specified explicitly with the 'width' property. A value of 'auto' (for both 'display: table' and 'display: inline-table') means use the automatic table layout algorithm. However, if the table is a block-level table ('display: table') in normal flow, a UA may (but does not have to) use the algorithm of 10.3.3 to compute a width and apply fixed table layout even if the specified width is 'auto'." from CSS 2.1 spec [http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout] the bug is INVALID. Webkit does NOT have to expand width for the table without explicitly 'width' property set. Per spec all of browsers renders it correctly but differently. Opera 9.50 behaves in this case like Webkit.
Looks like a valid compatibility issue.
(In reply to comment #5) > Looks like a valid compatibility issue. > So marked as NEW.
I am unsure if I should open a new bug for the stuff below, but it seems similar to this bug. Setting a width to 0px for a td or it's sub element, like say on a div doesn't seem to have an effect in webkit. It seems that width is ignored. Couple of test cases are as follows (as well as attached) which can show the difference between webkit and FF/IE: <!DOCTYPE html> <html> <body> <table cellpadding=0 cellspacing=0 style="width: 100%;"> <tbody> <tr> <td style="width: 0px;"> <input type=checkbox /> </td> <td>test</td> </tr> </tbody> </table> </body> </html> In the above case, the checkbox and the term "test" should be next to each other. In other words the td containing the checkbox should take the width of it's child element. If in the above code, I change the 0px to say 1px, then it works as expected. <!DOCTYPE html> <html> <body> <table cellpadding=0 cellspacing=0> <tbody> <tr> <td style="background: red;"> <div style="width: 0px;">test</div> </td> <td style="background: green; width: 100%;">test</td> </tr> </tbody> </table> </body> </html> This one shows an issue similar to the prior test case. But it also shows how webkit defaults to a 100% width on the table while FF/IE default to auto. In this test case the red part should not be visible as the div has a 0px width. But it seems the td ignores that and just takes up the width of the div's child which is simple text. There is also a downstream bug in the domain of these issues http://code.google.com/p/chromium/issues/detail?id=72309
Created attachment 81866 [details] testcase1 for comment 7
Created attachment 81868 [details] testcase2 for comment 7
"testcase1 for comment 7" is broken in Safari Technology Preview 188 while Chrome Canary 123 and Firefox Nightly 125 are matching each other. As for other tests, all browsers are matching each other. Adding 'BrowserCompat'.