Bug 13538 - Adjacent absolutely positioned element and siblings in CSS table placed below adjacent replaced content (<img>/<object>/etc.)
Summary: Adjacent absolutely positioned element and siblings in CSS table placed below...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://canvex.lazyilluminati.com/83/p...
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2007-04-29 01:51 PDT by Elliott Sprehn
Modified: 2012-06-21 20:03 PDT (History)
3 users (show)

See Also:


Attachments
Sample Image (1.44 KB, image/png)
2007-04-30 19:41 PDT, Elliott Sprehn
no flags Details
Reduction (1.38 KB, text/html)
2007-04-30 20:07 PDT, Elliott Sprehn
no flags Details
Cross Browser Consistency (1.12 KB, text/html)
2007-04-30 20:18 PDT, Elliott Sprehn
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Elliott Sprehn 2007-04-29 01:51:27 PDT
On the referenced page the canvas and help content is pushed down below below the two <object>'s on either side of the box in the middle of the page, each of which loads a single svg image.

If the absolutely positioned help section is hidden with #help_bg { display: none; } the page renders as expected.

The help content, which is positioned absolutely over the canvas, renders as expected over the canvas as shown when hovering the "help" link, though the entire section is pushed down below the objects.

It appears as though the inner section is being expanded to 200% height.

The canvas is unrelated as the section's height still expands and pushes the content down even if the canvas is not present.

Reproducible in Safari 2.0.4 and the latest nightly (Sun Apr 29 3:44:55 GMT 2007).
Comment 1 Elliott Sprehn 2007-04-29 01:52:50 PDT
Needs a reduction; I'll do it when I get some time.
Comment 2 Dave Hyatt 2007-04-29 04:04:16 PDT
Willing to bet the table display types have something to do with this bug.

Comment 3 Elliott Sprehn 2007-04-30 19:41:38 PDT
Created attachment 14279 [details]
Sample Image
Comment 4 Elliott Sprehn 2007-04-30 20:07:45 PDT
Created attachment 14280 [details]
Reduction

In the attached test case two CSS table cells are placed adjacent to each other, each with a single element of replaced content (in this case an img). An element is placed before the replaced content and positioned absolutely to place it over the img. 

However, Webkit places the entire cell down near the bottom of the replaced content in the second column.

Resizing (-/+) the text causes the dropped element to move up and down.
Comment 5 Elliott Sprehn 2007-04-30 20:18:36 PDT
Created attachment 14281 [details]
Cross Browser Consistency

If a div is used in place of the replaced content in the adjacent element with the absolutely positioned child then Presto and Gecko behave very similarly to Webkit, while webkit remains consistent in both cases.

Webkit still moves the element up an down depending on the size of the text though.
Comment 6 Elliott Sprehn 2007-04-30 20:32:14 PDT
It appears that if there's no content in the absolutely positioned adjacent cell then the cell is not dropped down in Webkit. Still is in Presto and Gecko though.
Comment 7 Elliott Sprehn 2007-04-30 20:34:40 PDT
References to Gecko and Presto here are for Firefox 2 and Opera 9.1.
Comment 8 Eric Seidel (no email) 2007-11-30 02:28:01 PST
When the display:table-cell divs are replaced by real table cells the bug does not reproduce.
Comment 9 Dave Hyatt 2007-12-04 17:24:13 PST
Real table cells use vertical-align:middle by default.  CSS tables default to vertical-align:baseline. This is an unfortunate difference between the two, especially since the baseline of table cells is actually very poorly defined.

The bug here is that RenderTableCell::baselinePosition always uses the first content it encounters to determine a baseline.  In this case that is the absolutely positioned div.  The behavior of this method is definitely incorrect, since we should be looking for a real baseline (like inline-block does).  In this case the canvas element establishes a real first line baseline, so we should be respecting it.

Changing this method will be kind of dangerous and might break existing tables, but it might be worth trying to improve.  In the meantime, the author could work around the problem with a vertical-align:middle on the table cells.
Comment 10 Robert Hogan 2011-08-03 11:08:14 PDT
Is this still a problem? I get consistent results across Chromium 12, FF4 and Opera 9 for 'Reduction'. Consistent results between Chromium 12 and FF4 for 'Cross Browser Consistency', while Opera 9 displays the second cell in a new row. 
Chromium 12 displays different results for each of the results.

QtTestBrowser against trunk is consistent with Chromium 12.
Comment 11 Elliott Sprehn 2012-06-21 20:03:44 PDT
This appears to be fixed now. I'm not sure at what point things changed in there, hyatt@ would have to comment.