Open Bug 1443284 Opened 6 years ago Updated 2 years ago

percentage height in auto-height table cell in fixed-height table is treated as auto

Categories

(Core :: Layout: Tables, defect, P3)

defect

Tracking

()

Webcompat Priority P3

People

(Reporter: jandem, Unassigned)

References

()

Details

(Whiteboard: [webcompat])

Attachments

(4 files)

Attached file Testcase
In Chrome the menu is easier to use because the "hover area" for the menu items is bigger.

I reduced it to the attached 26-line testcase. Note how in Chrome and Safari, the green element is much bigger than in Firefox.

I don't know if this is a Gecko bug but filing just in case.
Component: CSS Parsing and Computation → Layout
Flags: needinfo?(dholbert)
This sounded familiar, but the only related things I found so far are bug 601931 and bug 1386982, neither of which is really right.

Resummarizing to make it clear what's actually going on here.
Summary: greetz.nl menu doesn't work well in Firefox → percentage height in auto-height table cell in fixed-height table is treated as auto
The previous testcase used 'display:flex' on the innermost element, but this happens for 'display:block' as well, as shown in this testcase.

(For extra emphasis, I'm adding a red background on the fixed-height ancestor here. This red background is shown in Firefox, but in Chrome it gets covered up by the lime area.)
Attachment #8956211 - Attachment description: testcase 2 (using "display:block" on innermost element) → testcase 3 (using "display:block" on innermost element, and with red background on ancestor that shows up in Firefox)
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #1)
> This sounded familiar, but the only related things I found so far are
> bug 601931 and bug 1386982, neither of which is really right.

This actually looks quite a lot like bug 601931.  Both that bug & this bug have a "height:100%" child of a table-cell -- and we disregard the percent height, whereas Chrome and Edge (and I assume WebKit) resolve it.
Flags: needinfo?(dholbert)
(Oh, I guess in bug 601931, the percent-height basis ultimately comes from another cell in the same row, whereas in this case it comes from the table itself. Not sure if that makes a difference or to what extent this table behavior is specced these days...)
Component: Layout → Layout: Tables
Whiteboard: [webcompat]
[Triage 2018/03/23 - P3]
Priority: -- → P3
FWIW, for workaround purposes: if a site is hitting this bug, they may be able to get things working by:
 (a) adding an explicit "display:table-cell" wrapper (which we've already got in the testcases here)
 (b) styling that wrapper with "height:100%" (which I'm doing in this reference case).

This resolves the "broken chain" of height resolution between the inner percent-height block and the outer fixed-height table.  The inner block resolves its percent height against its cell (its containing block), so if the cell has a specified height (e.g. height:100%) which can be resolved against the table, then all is well.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: