1538075 - vertical alignment of button containing a block is different from Chrome

Status: NEW

(Core :: Layout: Block and Inline, defect, P3)

Description

[Cameron McCormack (:heycam)]

Attachment: reduced test 1

See the attached test case. In Chrome, the two buttons are aligned. In Firefox (and in Edge right now), the second button is a few pixels higher.

This is a reduced test case of an issue I see on Fastmail.

Comment 1

[Cameron McCormack (:heycam)]

I guess it's something to do with finding the baseline of the <button>, and not looking through the scroll frame.

Comment 2

[Cameron McCormack (:heycam)]

Attachment: Fastmail screen shot

This is how the problem manifests on Fastmail.

Comment 3

[Cameron McCormack (:heycam)]

Attachment: reduced test 2

This makes it more obvious.

Comment 4

[Cameron McCormack (:heycam)]

Marking webcompat? to get a sense of whether this affects other sites beside Fastmail.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced test 3

Comment 6

[Daniel Holbert [:dholbert]]

So there are a few issues here:
(1) For buttons with multiple line-boxes, Chrome seems to be deriving the baseline from the first line, whereas Firefox/Edge derives it from the last line.

(2) For buttons whose contents are scrollable, Chrome seems to be deriving the baseline from the text, whereas Firefox/Edge generate a baseline from the scrollable element's margin-box.

In both of these cases, Firefox/Edge are consistent with how they handle display:inline-block, while Chrome is doing something different. I'm not sure if buttons are specified well enough to have a definitive answer to who's right here, but our consistency-with-inline-block seems pretty sane, FWIW.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: pseudo reference case, for reduced test 3 (using inline-block instead of button)

Here's an amended version of "reduced test 3" where I've simply replaced the buttons with inline-blocks (with border and padding). Firefox/Chrome/Edge all agree on this version, and the agreed behavior matches how Firefox/Edge render "reduced test 3", FWIW.

Comment 8

[Cameron McCormack (:heycam)]

I just found https://bugs.chromium.org/p/chromium/issues/detail?id=894849, which Mats filed last year. And there is a linked open issue on the HTML spec: https://github.com/whatwg/html/issues/4081

Comment 9

[Cameron McCormack (:heycam)]

Which might not quite be the same issue (display:inline-block on the button itself rather than on its contents) but seems related.

Comment 10

[Daniel Holbert [:dholbert]]

Quoting mats from (tangentially-related) bug 1487826 comment 4:

using first-baseline for <button> in Chrome/Safari is bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=690036

The chrome bug isn't super-clear, but the particular comment https://bugs.chromium.org/p/chromium/issues/detail?id=690036#c7 seems to basically be describing this issue (at least the first-line vs. last-line aspect)

Comment 11

[Daniel Holbert [:dholbert]]

FWIW, https://github.com/whatwg/html/issues/4081#issuecomment-429393625 says that Chrome uses modern flexbox to implement button layout, and flexbox does indeed have different more-modern/friendly baseline behavior as compared to CSS21 layout constructs like inline-block, as of https://github.com/w3c/csswg-drafts/issues/2902 .

Comment 12

[Daniel Holbert [:dholbert]]

(though per https://github.com/whatwg/html/issues/4081#issuecomment-429989272 , biesi wants to get rid of this flexbox usage long-term, which may conceivably change the Chrome behavior here.)

Comment 13

[Koji Ishii]

Thank you heycam@ for pointing this issue to me.

I don't have opinions which is better, but WebKit seems to render the same as Blink, so if Blink changes, it forces authors to choose whether to match to Blink/Gecko or to WebKit.

Is Gecko willing to change? If you can consider that, it might make web-compat a bit easier for authors. If not, we can ping WebKit if they're willing to change too.

Comment 14

[Daniel Holbert [:dholbert]]

I think in general, we're willing to make changes (if we've got resources available), where there's a good argument for the new behavior and where webcompat allows or demands it, if the new behavior is reasonably well-specced/well-understood.

Right now I'm not sure that Blink's behavior is well-specced/well-understood, though. I suspect it's just whatever falls out of the fact that Blink is using CSS Flexbox under the hood for button centering -- and, given that biesi wants to change that, we probably shouldn't rely on that particular implementation detail too heavily when coming up with concrete long-term expectations here.

(Do you know if WebKit uses flexbox under the hood for button-contents centering? If they don't, then I suspect there are interesting edge cases where they'd disagree with Blink, even if they happen to agree on the testcase here.)

Comment 15

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 16

[Mike Taylor [:miketaylr]]

(so far we don't have a ton of evidence this happens a lot in the wild)