Bug 187416

Summary:	WebKit is is inconsistent on whether "overflow:scroll; display: inline-*" can determine baseline from its contents
Product:	WebKit	Reporter:	Daniel Holbert <dholbert>
Component:	Layout and Rendering	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED INVALID
Severity:	Normal	CC:	ahmad.saleem792, bfulgham, simon.fraser, zalan
Priority:	P2	Keywords:	FromImplementor
Version:	Safari 11
Hardware:	Unspecified
OS:	Unspecified

Description Daniel Holbert 2018-07-06 14:45:43 PDT

STR:
(1) Visit https://jsfiddle.net/06wxgroy/

EXPECTED RESULTS:
Consistent baseline-alignment between the 3 cases there.

ACTUAL RESULTS:
For the first case (inline-block), Safari aligns "abc" with the bottom of the scrollable box's border.

For the second and third case (inline-flex & inline-grid), Safari aligns "abc" with the first line of text inside the scrollable box.

I'm not aware of any spec support for treating inline-flex and inline-grid differently from inline-block here.

For reference: Edge, Chrome, and Safari/WebKit happen to all be in agreement on this (with WebKit having bug 187413 as an extra quirk), while Firefox treats all three boxes the same (using the bottom of the scrollable box's border).  We (Mozilla) received a bug report about this ( https://bugzilla.mozilla.org/show_bug.cgi?id=1471942 ) but I think the Firefox behavior seems most coherent, hence filing this bug.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=860820 for this issue in Chrome, too, BTW.


(Note: bug 187413 is related but distinct. That bug is specifically about "inline-block" being inconsistent, depending on the presence/absence of scrollbars.  Whereas, this bug here is about inconsistency between inline-{block,flex,grid} when scrollbars are present.)

Comment 1 Daniel Holbert 2018-07-10 09:21:47 PDT

tl;dr: Sorry for the trouble - looks like this is actually "Invalid".


Details: the spec text for display:inline-block;overflow:scroll is:
====
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.
====
https://www.w3.org/TR/CSS22/visudet.html#normal-block

I guess that is pretty specific to inline-block, and I just found this in the flexbox spec (and grid has a similar chunk):
====
When calculating the baseline according to the above rules, if the box contributing a baseline has an overflow value that allows scrolling, the box must be treated as being in its initial scroll position for the purpose of determining its baseline.
====
https://drafts.csswg.org/css-flexbox-1/#flex-baselines

So, I guess this is "invalid" and the specs *require* this inconsistency between inline-block vs. inline-flex/grid here (weird).

Comment 2 Daniel Holbert 2018-07-10 09:31:51 PDT

...oh, though actually, the flex text that I quoted above (and similar grid text) seems to be about *child boxes* ("the box contributing a baseline") -- it's not about the flex/grid container itself.  It doesn't say anything about what happens when the *container* has overflow set to something non-"visible", RE baselines.

So I'm back to thinking this isn't really defined in the specs, beyond the requirements from CSS2 about inline-block, which I'd think would implicitly apply to other inline-* containers in the absence of specific contradictory text.

Comment 3 Daniel Holbert 2018-07-10 11:12:28 PDT

I filed https://github.com/w3c/csswg-drafts/issues/2902 to clarify this in the spec.

Comment 4 Ahmad Saleem 2022-10-06 05:00:33 PDT

From Chromium bug, it seems that Firefox changed their behavior to align with all other browsers in the JSFiddle and I tested with Safari 16, Chrome Canary 108 and Firefox Nightly 107 and all browsers are rendering this same (on JSFiddle).

Marking this as "RESOLVED INVALID" since Firefox changed the behavior compared to Webkit. Thanks!