Open Bug 1421660 Opened 4 years ago Updated 2 years ago
Should table row groups be containing blocks?
It sounds to me like they should not. I rebased bug 975644 and fiddled around a bit with it and the test-case pointed out by bug 975644 comment 32 doesn't work because of this (we claim that the <thead> is the containing block of the header cells, and thus restrict its sticky position). Looks like table rows were excluded in bug 729143. But it's not clear that table headers and similar table frames shouldn't also be excluded... Blink doesn't claim that the <thead> is a containing block. Perhaps it would make sense to have an explicit eIsContainingBlock in the IsFrameOfType flags, or a mozilla::ContainingBlock nsContainerFrame subclass, or something like that instead of using eIsLineParticipant for this? Xidorn also mentioned he was worried about the result of this function for some ruby frames. : https://searchfox.org/mozilla-central/rev/9f3bd430c2b132c86c46126a0548661de876799a/layout/generic/nsFrame.cpp#7540
David, Boris, you probably know this the best (given Ehsan is away), could you please take a look at comment 0? I'll happily work on this if you want :)
I'm specifically concerned about nsRubyTextContainerFrame since it isn't line participant but I would be surprised if it should be considered to be a block container. (Haven't checked the spec for this, though)
Per spec, last I checked, no table-internal frames should be containing blocks. That said, the spec may not match reality. See https://github.com/w3c/csswg-drafts/issues/2004 for example. And the real question is what should happen given a fixed-height table row group containing several percentage-height table rows. What are the percentages resolved relative to?
I landed https://hg.mozilla.org/integration/autoland/rev/bdafa059aa94 working around this bug for sticky containers, so it may need to get reverted if / when we fix this.
You need to log in before you can comment on or make changes to this bug.