Bug 10209 - REGRESSION: table layout wrong, large image is now wrapping to next line
Summary: REGRESSION: table layout wrong, large image is now wrapping to next line
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: https://www.asylumtel.com/
Keywords: HasReduction, InRadar, Regression
Depends on:
Reported: 2006-08-02 08:01 PDT by Nemeth 'FooLman' Gabor
Modified: 2007-05-10 16:43 PDT (History)
4 users (show)

See Also:

reduction of the site (684 bytes, text/html)
2006-08-03 19:58 PDT, Darin Adler
no flags Details
Reduction - working with Firefox. (820 bytes, text/html)
2006-08-05 01:25 PDT, Nemeth 'FooLman' Gabor
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nemeth 'FooLman' Gabor 2006-08-02 08:01:11 PDT
the two images at https://www.asylumtel.com/ stating corporate and partners should be next to each other (and is in the latest Safari, or any other browser), and not beneath like webkit is rendering.
Comment 1 Darin Adler 2006-08-03 19:58:22 PDT
Created attachment 9865 [details]
reduction of the site
Comment 2 Darin Adler 2006-08-03 19:59:00 PDT
I attached a reduction. The bug is specific to strict mode, it seems, and has something to do with table cells.
Comment 3 jonathanjohnsson 2006-08-04 11:54:43 PDT
(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.
Comment 4 Dave Hyatt 2006-08-04 14:42:12 PDT
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.
Comment 5 Nemeth 'FooLman' Gabor 2006-08-05 01:25:06 PDT
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.
Comment 6 Stephanie Lewis 2006-11-06 19:52:08 PST
radar 4823058
Comment 7 Dave Hyatt 2006-12-14 23:35:34 PST
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.
Comment 8 Dave Hyatt 2006-12-14 23:37:56 PST
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.
Comment 9 Dave Hyatt 2006-12-14 23:40:56 PST
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.
Comment 10 Dave Hyatt 2006-12-15 00:13:29 PST
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.
Comment 11 Ian 'Hixie' Hickson 2006-12-15 10:28:31 PST
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?
Comment 12 Dave Hyatt 2007-01-13 03:01:45 PST
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.
Comment 13 Dave Hyatt 2007-05-10 16:43:57 PDT
I am sticking with my opinion that this is behaving as intended.