1471942 - [css-flexbox][css-grid] overflow:hidden causes Firefox to use inline-grid/inline-flex's border-box bottom edge for baseline alignment

Status: VERIFIED DUPLICATE of bug 969874

(Core :: Layout, defect, P3)

Description

[frlinw]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce:

https://codepen.io/frlinw/pen/WyYgjM


Actual results:

with `overflow:hidden`, `inline-flex` behave like `inline-block` and cause an extra space below. This extra space can be removed if you change `vertical-align` value

But the spec says:
https://www.w3.org/TR/css-flexbox-1/#flex-containers
"vertical-align has no effect on a flex item."


Expected results:

Extra space should not be added when a dom node has overflow:hidden + display:inline-flex

Comment 1

[roxleitan]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180702220046

I managed to reproduce the issue using Firefox Nightly 63.0a1 on Windows 10 x64.

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for the bug report! I think there's a misunderstanding here, though.

(In reply to frlinw from comment #0)
> with `overflow:hidden`, `inline-flex` behave like `inline-block` and cause
> an extra space below. This extra space can be removed if you change
> `vertical-align` value
> 
> But the spec says:
> https://www.w3.org/TR/css-flexbox-1/#flex-containers
> "vertical-align has no effect on a flex item."


You're talking about two different things here.

A box width "display:inline-flex" is *not* a flex item - it's not what the spec is talking about there. The flex item here is the thing *inside of it* (an anonymous box that wraps the #######).  And indeed, vertical-align has no effect on that box. It does have an effect on the layout of the inline-flex

To illustrate this, here's a demo with "display:inline-flex; vertical-align:top" where it does clearly have an effect in all browsers: https://jsfiddle.net/6fbz39x7/

Anyway -- having said this, I can confirm that Chrome & Edge do seem to render your testcase differently than Firefox does, and I'm curious why that's happening, so I'm leaving this open for the moment & investigating a bit more...

Comment 3

[Daniel Holbert [:dholbert]]

So the real difference here is that browsers disagree about whether it's possible to derive a baseline from an element that has "display: inline-flex" and "display: inline-grid".  Here's a more targeted testcase for that:
https://codepen.io/dholbert/pen/MXMNzK

Firefox synthesizes a baseline from the border-box bottom edge for the first 3 cases (inline-{block,flex,grid}), and does real baseline-alignment for inline-table.

In contrast, Chrome & Edge synthesize a baseline from the border-box bottom *only* for the first case (inline-block), and they do real baseline-alignment for inline-flex, inline-grid, and inline-table.

Comment 4

[frlinw]

Thanks, indeed someone already corrected me about flex item
I opened an issue on csswg-drafts repo to have more informations about what are spec expectations on this particular case, it's still unclear https://github.com/w3c/csswg-drafts/issues/2838#issuecomment-401120120

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 6

[Daniel Holbert [:dholbert]]

If it's not clear, the extra space in the original testcase comes from this set of facts:
  - The inline-flex element gets placed into a line in its block formatting context.
  - That line happens to not have any characters in it, but I think it gets a baseline established as if it did -- so e.g. it might be 16px tall, with its baseline set to be 2px from the bottom. (just making up numbers for simplicity)
  - So when we place an "overflow:hidden;display:inline-block" (or inline-flex) element into it, we have to baseline-align that element with the line that it's in. In this case, since we think we can't get a baseline from inside the inline-block/inline-flex element, we fall back to deriving a baseline from the element's border-bottom edge. So, that means we align the element's border-bottom edge with the line's baseline -- which as I said above, is ~2px from the bottom (for example).
  - So we end up with some blank space below the border bottom.

In contrast, if you set vertical-align:top (or anything besides the default vertical-align:baseline probably) on the inline-block / inline-flex, then we *don't bother* baseline-aligning it, and we just align its top to the top of the line (or its center to the center of the line, etc).  This means we aren't locked into aligning its border-bottom to be ~2px from the bottom of the line. So, if sizing permits, there's no reason it has to have blank space below it in the line anymore.

Comment 7

[Daniel Holbert [:dholbert]]

> since we think we can't get a baseline from inside the inline-block/inline-flex element

...and this ^^ is the part that differs between browsers (for inline-flex), BTW.  And which confusingly differs in Chrome/Edge between "inline-block" vs. "inline-flex".  (Firefox is consistent between these container types; Chrome/Edge are not.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (with visible scrollbars & taller overflowing content)

Here's a testcase with "overflow:scroll" to force scrollbars to paint.

This demonstrates that table is actually a special case (apparently no browser honors overflow:hidden/overflow:scroll on it -- presumably you have to set those on a parent or on a cell, not on the table).  So that explains why inline-table does baseline alignment in Firefox even in the presence of overflow:hidden, whereas none of the other types do.

So, I'm inclined to think that the Chrome/Edge behavior here is inconsistent & buggy.

Comment 9

[Daniel Holbert [:dholbert]]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=860820 on the behavior in Chrome, FWIW.

Comment 10

[Daniel Holbert [:dholbert]]

...and https://bugs.webkit.org/show_bug.cgi?id=187416 on the behavior in WebKit (and https://bugs.webkit.org/show_bug.cgi?id=187413 on a side issue I ran into there)

Comment 11

[Daniel Holbert [:dholbert]]

And given https://github.com/w3c/csswg-drafts/issues/2838#issuecomment-401120120 and the fact that we're consistent (for inline-block/grid/flex) with the browser consensus behavior for "inline-block", I'm going to tentatively say we're doing the least-bad thing here, and I'm resolving this as "invalid". (Though it's conceivable we may want to reopen down the line, if other browsers don't fix this & if interoperability requirements start to crystallize around their behavior.)

Comment 12

[frlinw]

I know Gecko is the good student most of the time, but I still have some doubts when you are alone vs all
I will report this on Edge side
Once again, Thanks for your time Daniel !

Comment 13

[Daniel Holbert [:dholbert]]

Thanks!

BTW, I found some spec text about this, but it's still not really clear if the specs require anything in particular (for inline-flex / inline-grid), so I'd like to see the specs clarified. I filed https://github.com/w3c/csswg-drafts/issues/2902 -- see that page for more details.

Comment 14

[Daniel Holbert [:dholbert]]

Per fantasai's note on my github issue ( https://github.com/w3c/csswg-drafts/issues/2902#issuecomment-407576395 ), it sounds like:
 - `inline-block` is intended to be a special case [perhaps special-cased for sad legacy purposes]
 - inline-flex/inline-grid are indeed meant to behave differently, and their behavior is defined by the last paragraph of https://drafts.csswg.org/css-align/#baseline-export :
 # For the purposes of finding the baselines of a box,
 # it and all its in-flow descendants with a
 # scrolling mechanism (see the overflow property)
 # must be considered as if scrolled to their origin.

So I think that means this bug should be reopened as a valid issue.

Comment 15

[Daniel Holbert [:dholbert]]

Also: I just realized this is basically a duplicate of bug 969874.