Bug 13538 – Adjacent absolutely positioned element and siblings in CSS table placed below adjacent replaced content (<img>/<object>/etc.)

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Elliott Sprehn]

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).

[Elliott Sprehn]

Needs a reduction; I'll do it when I get some time.

[Dave Hyatt]

Willing to bet the table display types have something to do with this bug.

[Elliott Sprehn]

Created attachment 14279 [details]
Sample Image

[Elliott Sprehn]

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.

[Elliott Sprehn]

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.

[Elliott Sprehn]

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.

[Elliott Sprehn]

References to Gecko and Presto here are for Firefox 2 and Opera 9.1.

[Eric Seidel (no email)]

When the display:table-cell divs are replaced by real table cells the bug does not reproduce.

[Dave Hyatt]

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.

[Robert Hogan]

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.

[Elliott Sprehn]

This appears to be fixed now. I'm not sure at what point things changed in there, hyatt@ would have to comment.