Open Bug 1538075 Opened 5 years ago Updated 2 years ago

vertical alignment of button containing a block is different from Chrome

Categories

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

defect

Tracking

()

Webcompat Priority P3

People

(Reporter: heycam, Unassigned)

References

Details

Attachments

(5 files)

Attached file 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.

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

Attached image Fastmail screen shot

This is how the problem manifests on Fastmail.

Attached file reduced test 2

This makes it more obvious.

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

Flags: webcompat?
Attachment #9052787 - Attachment description: reduced test → reduced test 1
Attachment #9052789 - Attachment description: reduced test → reduced test 2

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.

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.

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

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

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)

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 .

(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.)

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.

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.)

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

Webcompat Priority: --- → ?

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

Webcompat Priority: ? → revisit
Webcompat Priority: revisit → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: