Bug 10209 – REGRESSION: table layout wrong, large image is now wrapping to next line

• Status: RESOLVED
• Resolution: INVALID
• Component: Layout and Rendering

[Nemeth 'FooLman' Gabor]

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.

[Darin Adler]

Created attachment 9865 [details]
reduction of the site

[Darin Adler]

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.

[Dave Hyatt]

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.

[Nemeth 'FooLman' Gabor]

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.

[Stephanie Lewis]

radar 4823058

[Dave Hyatt]

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.

[Dave Hyatt]

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.

[Dave Hyatt]

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.

[Dave Hyatt]

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.

[Ian 'Hixie' Hickson]

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?

[Dave Hyatt]

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.

[Dave Hyatt]

I am sticking with my opinion that this is behaving as intended.

Closing.