Inconsistency between browsers of rendering tables with fixed layout and width set to 'auto' 
https://bugs.webkit.org/show_bug.cgi?id=17583
Summary Inconsistency between browsers of rendering tables with fixed layout and widt...
jasneet
Reported 2008-02-27 18:31:03 PST
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
Attachments
screenshot (145.92 KB, image/jpeg)
2008-02-27 18:32 PST, jasneet 		no flags
Details
reduction (519 bytes, text/html)
2008-02-27 18:33 PST, jasneet 		no flags
Details
testcase1 for comment 7 (246 bytes, text/html)
2011-02-09 13:58 PST, Darth 		no flags
Details
testcase2 for comment 7 (282 bytes, text/html)
2011-02-09 13:59 PST, Darth 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
jasneet
Comment 1 2008-02-27 18:32:08 PST
Created attachment 19423 [details] screenshot
jasneet
Comment 2 2008-02-27 18:33:09 PST
Created attachment 19424 [details] reduction
Robert Blaut
Comment 4 2008-02-28 12:02:08 PST
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.
mitz
Comment 5 2008-02-28 13:28:36 PST
Looks like a valid compatibility issue.
Robert Blaut
Comment 6 2008-02-28 13:49:48 PST
(In reply to comment #5) > Looks like a valid compatibility issue. > So marked as NEW.
Darth
Comment 7 2011-02-09 13:57:45 PST
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
Darth
Comment 8 2011-02-09 13:58:23 PST
Created attachment 81866 [details] testcase1 for comment 7
Darth
Comment 9 2011-02-09 13:59:47 PST
Created attachment 81868 [details] testcase2 for comment 7
Ahmad Saleem
Comment 10 2024-02-19 21:12:52 PST
"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'.
Note You need to log in before you can comment on or make changes to this bug.