Bug 13374 - Problem with calculating row height with spanned cells (Picture Overlaps Text)
Summary: Problem with calculating row height with spanned cells (Picture Overlaps Text)
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.pikes.org/student/student....
Keywords: HasReduction
: 15664 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-17 11:01 PDT by Jarrod Young
Modified: 2008-02-15 14:40 PST (History)
4 users (show)

See Also:


Attachments
Incomplete reduction (15.46 KB, text/html)
2008-02-05 16:50 PST, Chasen Le Hara
no flags Details
test case (936 bytes, text/html)
2008-02-05 20:10 PST, Chasen Le Hara
no flags Details
Test case (1.06 KB, text/html)
2008-02-05 22:33 PST, Chasen Le Hara
no flags Details
minimal test case for calculating cell height (1.16 KB, text/html)
2008-02-06 00:45 PST, Robert Blaut
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jarrod Young 2007-04-17 11:01:00 PDT
Picture on left overlaps text on the page and links cannot be accessed because of it.
Comment 1 mitz 2007-04-17 11:35:59 PDT
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?
Comment 2 Chasen Le Hara 2008-02-04 13:28:09 PST
I can confirm this in nightly r29955.
Comment 3 Robert Blaut 2008-02-04 14:46:52 PST
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.
Comment 4 Chasen Le Hara 2008-02-05 11:30:25 PST
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.
Comment 5 Robert Blaut 2008-02-05 12:50:04 PST
(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 ;)

Comment 6 Chasen Le Hara 2008-02-05 16:50:51 PST
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.
Comment 7 Chasen Le Hara 2008-02-05 20:10:52 PST
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.
Comment 8 Chasen Le Hara 2008-02-05 22:33:15 PST
Created attachment 18952 [details]
Test case

Cleaner test case.
Comment 9 Robert Blaut 2008-02-06 00:45:09 PST
Created attachment 18956 [details]
minimal test case for calculating cell height
Comment 10 Robert Blaut 2008-02-06 00:59:03 PST
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 :(
Comment 11 Chasen Le Hara 2008-02-06 08:48:33 PST
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.
Comment 12 Robert Blaut 2008-02-15 14:40:26 PST
*** Bug 15664 has been marked as a duplicate of this bug. ***