Open Bug 666447 Opened 10 years ago Updated 10 years ago

Sort out the behavior of nsIFrame::GetContainingBlock for inner table frames

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

People

(Reporter: ehsan.akhgari, Unassigned)

Details

nsIFrame::GetContainingBlock returns the containing block of the outer table frame when called on inner table frames.  This leads to complications (see bug 10209 comment 110) in case the containing block of the outer table frame is a positioned inline frame.  We need to figure out a more elegant way of handling that.
So is there a reason to not just return the containing block of the table outer frame for table inner frames?
(In reply to comment #1)
> So is there a reason to not just return the containing block of the table outer
> frame for table inner frames?

The confusion mostly rises from the fact that the CSS spec defines containing blocks for elements, and doesn't say anything about the special case for tables.  I do think that it should be OK.  For future reference, we should make sure that nsHTMLReflowState::ComputeContainingBlockRectangle does something sensible in this case.
Per http://www.w3.org/TR/CSS21/visudet.html#containing-block-details
the containing block of the table, caption, and inner table elements is the outer table box (table wrapper box). Is this a problem somehow?
The spec's definition of "containing block" there is useless here, since it differs for percentage base calculations.  The spec's containing block for percentage calculations ignores the table wrapper box and uses the next up block.
You need to log in before you can comment on or make changes to this bug.