Bug 13374 – Problem with calculating row height with spanned cells (Picture Overlaps Text)

• Component: Tables
• Status: NEW

[Jarrod Young]

Picture on left overlaps text on the page and links cannot be accessed because of it.

I don't see the problem. The page looks essentially the same in TOT, Safari 2 and Firefox. Can you attach a screenshot showing the bad layout?

[Chasen Le Hara]

I can confirm this in nightly r29955.

[Robert Blaut]

Opera and Webkit renders it identically (overlap causes). Only Firefox reserves more space for white td. This issue highly depends on screen width. It's visible on 1280x1024 screens. On narrower screens the issue can be unable to reproduce.

[Chasen Le Hara]

I'm inclined to mark this as an invalid bug. The picture on the left is in an absolutely positioned div in the body element. I don't believe there is any reason to expect room to be given for the picture (I don't know of a reason in the CSS specs).

What's interesting is how Firefox is deciding to give the space seen in it but not Webkit or Opera. I can create a reduction if we want to explore that.

[Robert Blaut]

(In reply to comment #4)

> What's interesting is how Firefox is deciding to give the space seen in it but
> not Webkit or Opera. I can create a reduction if we want to explore that.

Chasen, minimal test case is highly demanded in this case ;)

[Chasen Le Hara]

Created attachment 18943 [details]
Incomplete reduction

I've reduced the relevant code down quite a bit, but still haven't found the root issue. Basically, the presence of the image doesn't seem to have any effect on the table cell, but I still don't understand why its height is different in Firefox.

I'm going to come back to this bug in about five or six hours and see if I can't find the root issue.

[Chasen Le Hara]

Created attachment 18949 [details]
test case

Okay, this is fun. The bug basically boils down to fundamental differences between WebKit and Firefox with how table row/cell heights are calculated. This difference should be pretty visible in the test case.

Which is correct? I don't think either of them are wrong (except, perhaps, Firefox's capability to handle vertical-align: baseline). According to <a href="http://www.w3.org/TR/REC-CSS2/tables.html#height-layout">CSS2</a>,

<blockquote><p>CSS2 does not specify how cells that span more than [one] row affect row height calculations except that the sum of the row heights involved must be great enough to encompass the cell spanning the rows.</p></blockquote>

But perhaps I've over-simplified this and am quoting an irrelevant section of the spec. Someone with more knowledge of everything involved will after look over my test case.

[Chasen Le Hara]

Created attachment 18952 [details]
Test case

Cleaner test case.

[Robert Blaut]

Created attachment 18956 [details]
minimal test case for calculating cell height

[Robert Blaut]

Chasen, thank you for creating reduced test case :) I created further reduction which clearly shows differences between Webkit and Firefox in method of calculating cell (row) height. If we consider : http://www.w3.org/TR/CSS21/tables.html#height-layout paragraph:

"In CSS 2.1, the height of a cell box is the maximum of the table cell's 'height' property and the minimum height required by the content (MIN). A value of 'auto' for 'height' implies that the value MIN will be used for layout. CSS 2.1 does not define what percentage values of 'height' refer to when specified for table cells."

Based on above definition, in my opinion, Webkit and Opera calculating height properly. But the following paragraph says:

"CSS 2.1 does not specify how cells that span more than one row affect row height calculations except that the sum of the row heights involved must be great enough to encompass the cell spanning the rows."

So I'm a bit confused :(

[Chasen Le Hara]

I re-read those two paragraphs over and over and was confused as well. The first paragraph seems to indicate that the cells in the test case should be the (minimum value of the) height of the content (which WebKit correctly does for the first row, first cell).

That second paragraph seems to say that it doesn't handle how heights should be calculated in the test case, which obviously leaves the rendering up for grabs by everyone.

The rendering in WebKit in the test case is inconsistent with how it calculates row/cell height when the height of a table is set (in which case it acts like Firefox does in the test case by making the row heights equal percentages).

So, unless we want the behavior to be similar in those two different circumstances, I see this bug as a difference of opinion between WebKit and Firefox.

[Robert Blaut]

*** Bug 15664 has been marked as a duplicate of this bug. ***

[Brent Fulgham]

We do not match Chrome and Firefox here, so we should consider addressing.

[Radar WebKit Bug Importer]

<rdar://problem/96556108>