1542098 - A definite table-cell 'height' is used as the percentage basis for its children

Status: RESOLVED DUPLICATE of bug 1461852

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

Description

[Alice0775 White]

Attachment: screenshot Nightly68.0a1 vs Chrome75

Steps To Reproduce:

1. Open https://tenki.jp/sakura/3/

Actual Results:
Image and text overlap

Expected Results:
Text should be placed below image as Chrome and Edge

Comment 1

[Alice0775 White]

Attachment: Reduced html

Comment 2

[Alice0775 White]

Workaround:
remove 'height: 1em;' from css selector '.popular-spots-box li'

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 4

[Mats Palmgren (inactive)]

So, I guess since the height property is just a "minimum height hint"
or something for table cells we shouldn't use it as a percentage basis?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

My memory is that it's more complicated than that -- although I think it's the height of the row that's used as a percentage basis, in rather complicated conditions that were a function of WebKit reverse engineering Gecko which badly reverse-engineered IE. (I'd hoped to redo the table height code in ~2007 to be more faithful to what IE6 did, which made more sense, but it's too late for that now...)

I think the when does/doesn't a table row serve as a basis for percentage heights rules are pretty complicated -- but I'd at least hope it's always the row height that matters and not particular specified table cell heights.

(There's also the question of which specified heights matter as a percentage basis in the first-pass layout that's used to determine the height of the row, which might be different!)

Comment 6

[Sean Voisen (:svoisen)]

Bulk moving bugs that have been triaged P4 to P5 (P4 is reserved for WPT bugs).

Comment 7

[Daniel Holbert [:dholbert]]

Based on discussion above, I'm pretty sure this is the same as bug 1461852.