Summary: | REGRESSION: table layout wrong, large image is now wrapping to next line | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Nemeth 'FooLman' Gabor <gnemeth> | ||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED INVALID | ||||||||
Severity: | Normal | CC: | bdakin, darin, hyatt, mitz | ||||||
Priority: | P2 | Keywords: | HasReduction, InRadar, Regression | ||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
URL: | https://www.asylumtel.com/ | ||||||||
Attachments: |
|
Description
Nemeth 'FooLman' Gabor
2006-08-02 08:01:11 PDT
Created attachment 9865 [details]
reduction of the site
I attached a reduction. The bug is specific to strict mode, it seems, and has something to do with table cells. (In reply to comment #2) > I attached a reduction. The bug is specific to strict mode, it seems, and has > something to do with table cells. > I'm confused when looking at the reported page and the reduction in different browsers: * Latest Safari and Firefox 1.5 renders the reported page as it was intended, Opera 9 and latest WebKit does not. * Latest WebKit, Firefox 1.5 and Opera 9 renders the testcase with the images on top of each other, only latest Safari renders them side by side. By just looking at these facts, it's hard to know what's correct. I think it would be informative to have a reduction created using latest WebKit vs Firefox also. I guess I'll try that tomorrow. The reduction renders the same in Firefox and Safari.... but the site looks good in Firefox. I'm not sure this is a valid reduction. Created attachment 9887 [details]
Reduction - working with Firefox.
The problem is with the "td" tag's display style attribute.
When it is set to "table-cell" the site renders correctly, with "inline" it does not.
radar 4823058 The basic bug here is that <td style="display:inline"> results in something that is not a table cell (in both Firefox and Safari). This is because the display type has been changed from table cell to inline. In quirks mode we just ignore this, but in strict mode we assume you know what the hell you're doing. In this case the author clearly doesn't. The bug arises when a <td> is no longer a table cell. In Safari we still apply the table's cellpadding to the <td>s. This seems clearly wrong to me if the object in question is no longer a table cell, so fix will be coming shortly. Actually I'm not sure how to fix this. The additional style info is added in before we even know what our ultimate display type is going to be, so we have nothing to go on to figure out not to map in the extra style. Lowering the priority of this to P2. Safari's rendering is not clearly "wrong" here, since there's no clear-cut rule regarding whether or not the HTML content model table properties apply to the content model vs. the renderers. Actually I wasn't quite right. We are applying the cell padding of the <table> to anonymous cells. Firefox does not do this. I believe our behavior is more correct. Note that WinIE can't be trusted at all for this test, since it does not support changing the display types of table elements. I believe this is invalid. INVALID? Why would anonymous cells get padding? I agree that "cellpadding" should be propagated to TD elements, but why would it propagate to elements that aren't even in the DOM? Because to do otherwise would yield inconsistent padding results. If I say <table border=10> do you expect the anonymous cells to not have a border? That doesn't make any sense. I am sticking with my opinion that this is behaving as intended. Closing. |