[css-2][css-flexbox][css-grid] baseline position of inline-flex/inline-grid elements with overflow:hidden

[madmoizo]

overflow: hidden with display: inline-flex result in an extra space (below the dom node)
The extra space is unexpected and the way to fix it (with vertical-align) seems to be hacky.

This behaviour is implemented on Gecko but not on Blink/EdgeHTML.

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

Specs

https://www.w3.org/TR/CSS2/visuren.html#block-formatting
https://www.w3.org/TR/css-flexbox-1/

[SelenIT]

Actually, the behavior of the inline-block elements regarding the baseline position is described in the last paragraph of Section 10.8.1 of CSS 2.x (vertical-align propery definition):

The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge.

If the baseline of the element is the bottom margin edge and it has vertical-align: baseline (as by default), it has space below the baseline reserved for the descenders of the font characters (the same thing occurs with the <img> elements by default). I see this behavior in all major browsers. In general, all inline-* elements are expected to be placed into the line of text and be somehow aligned with the neighbor text, so using these display values in other context is already somehow "hacky". In the SO example, the better solution would be to use display: block for the inner element.

[madmoizo]

You are totally right about inline-block, all browsers behave the same way (extra space below)

My bad, the issue is not related to inline-block but to inline-flex !
As you can see here: https://codepen.io/frlinw/pen/WyYgjM
There is an extra space below on Firefox but not on Chrome & Edge

Can you tell me which implementation is the good one ?

[SelenIT]

Very good question! It applies to inline-grid elements as well. I found no remark about them like that for the inline-blocks in neither CSS Flexbox nor CSS Display specs, so the behavior of Blink and Edge seems to be technically spec-compliant. However, in case when such an element with overflow: hidden (or auto/scroll) has fixed height and it's content has much vertical space above its first text line (see the fork of your pen), I'd say that the Gecko's behavior, reusing the logic for inline-blocks, makes more sense.

[madmoizo]

reusing the logic for inline-blocks, makes more sense

In the spec https://www.w3.org/TR/css-flexbox-1/#flex-containers:

• vertical-align has no effect on a flex item

That means, if you reuse inline-block behavior for inline-flex, you'll have the extra space and no way to remove it

Anyway, this point is (partially) ignored by all browsers because vertical-align: middle on an inline-flex node cause an extra space above
https://codepen.io/frlinw/pen/mKQzqK

[SelenIT]

Inline-flex elements are (inline-level) flex containers, not flex items. Their direct children are flex items, and their vertical (in case of horizontal writing mode and flex-direction: row) position is controlled by the align-items/align-self properties. The vertical-align property still affects the vertical position of the container itself in the line box.

[madmoizo]

ok thanks & sorry for the confusion

Do you see a reason for this extra space above with vertical-align: middle ?

[SelenIT]

According to the spec for vertical-align,

middle
Align the vertical midpoint of the box with the baseline of the parent box plus half the x-height of the parent.

In other words, this value aligns the vertical center of the box with the vertical center of the lowercase characters of the parent. This point is usually lower than the middle of the line box height, so it shifts the box a bit down. So it's the correct behavior.

[Loirooriol]

CSS2 is too old, I would like a CSS Flow Layout spec that would explain these things properly, taking new kinds of boxes into account.

[dholbert]

Quoting @SelenIT's above comment:

I'd say that the Gecko's behavior, reusing the logic for inline-blocks, makes more sense.

I agree (speaking on behalf of Mozilla/Gecko), and I filed a bug on Chrome's behavior for this scenario: https://bugs.chromium.org/p/chromium/issues/detail?id=860820

[SelenIT]

@dholbert, I believe your description of the issue is much better, so this should be marked as a duplicate.

[dholbert]

Thanks! Sounds good to me. I actually forgot that this thread existed when I filed that newer issue :)

[madmoizo]

duplicate of #2902