Firefox applies percent-height ancestor-resolution quirk to deeply-nested percentages inside of a definite-height flex item (whereas Chrome does not)
Categories
(Core :: Layout: Flexbox, defect, P3)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
Details
Attachments
(2 files)
STR:
- Load attached testcase.
EXPECTED RESULTS:
- Top section should probably have a tall purple area.
- Lower section should probably have a short purple area.
In other words, the testcase should look the same as it would if you added <!DOCTYPE html> to trigger standards-mode.
ACTUAL RESULTS:
Both sections have tall purple areas.
It appears we are digging up through all the div wrappers to the flex item (the outermost unstyled div wrapper), which has a definite height due to part 3 of https://drafts.csswg.org/css-flexbox-1/#definite-sizes . This is arguably reasonable -- there's a case to be made (as in bug 1578586) that we shouldn't apply quirks-mode features to elements that use a modern layout type (like flexbox) -- but in the attached testcase, the element that we ultimately resolve the percent-height against is still a block (and the flex container is the parent of that block that forms the percent basis). So... it's debatable whether it makes sense to exempt this scenario, and perhaps we shouldn't change our behavior on this.
Having said that: we do differ from Chrome on this, and this seems to be the underlying cause of webcompat issue https://github.com/webcompat/web-bugs/issues/48423
Chrome's behavior actually doesn't make a lot of sense, here -- their quirks-mode behavior also disagrees with the standards-mode rendering, but they stray in the opposite direction. Their quirks-mode rendering has a short purple area in both sections -- i.e. they're treating the flex item as having an indefinite height in quirks mode (though it has a definite height in standards mode). I'm going to file a Chrome bug on this... Depending on how that shakes out, maybe this will end up being closable with no action.
|
Reporter | |
Comment 1•5 years ago
|
||
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 2•5 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
Chrome's behavior actually doesn't make a lot of sense, here -- their quirks-mode behavior also disagrees with the standards-mode rendering, but they stray in the opposite direction.
I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1054185 on Chrome here, BTW.
|
|
Reporter | |
Comment 3•5 years ago
|
||
OK, I think our behavior here does make sense.
Summing up the situation:
-
bug 1578586 was about preventing percentages on a child of an indefinite-height flex item from quirkily "tunneling past" that indefinite-height flex item to its parent (the flex container) and resolving against that.
-
However: if the flex item itself ends up being definite height, then of course it does establish a percent basis that percentages on its children can resolve against.
-
And moreover: if the flex item is definite-height and is a block, then it's a totally reasonable target for this quirky "tunneling" behavior, for deeply-nested percent values inside of it.
The only thing we were aiming to do in bug 1578586 was to prevent the flex container from ending up being the thing that we resolve against via this quirk. But it seems pretty reasonable that we allow the tunneling to happen for stacks of nested blocks inside of the flex container, if the flex container itself isn't involved.
Description
•