Bug 136332 - Subpixel layout: Inline-block is offset from dominant baseline with em based padding
Summary: Subpixel layout: Inline-block is offset from dominant baseline with em based ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 133932
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-27 23:17 PDT by Philippe Wittenbergh
Modified: 2023-06-29 16:32 PDT (History)
4 users (show)

See Also:


Attachments
test case 1 (1.78 KB, text/html)
2014-08-27 23:17 PDT, Philippe Wittenbergh
no flags Details
Screenshot (48.30 KB, image/png)
2014-08-27 23:18 PDT, Philippe Wittenbergh
no flags Details
test case 2 (requires Ahem) (1.42 KB, text/html)
2014-08-27 23:21 PDT, Philippe Wittenbergh
no flags Details
This is still a problem in the latest WebKit nightly, r201711 (13.29 KB, image/png)
2016-06-06 14:50 PDT, Han
no flags Details
By contrast, this has been fixed in Chrome 50 (13.31 KB, image/png)
2016-06-06 14:51 PDT, Han
no flags Details
265546@main (7.16 KB, image/png)
2023-06-29 16:30 PDT, zalan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Wittenbergh 2014-08-27 23:17:21 PDT
Created attachment 237291 [details]
test case 1

An inline-block with em based padding whose computed value is *not* an integer is offset by a 2~3 px from the dominant baseline. The inline-block is positioned lower than it should be, and misaligned with the inline content that surrounds it.

In the test case: the inline-block has a light green background and a padding of 0.35em (computed value: 5.6px); the dominant baseline is represented by the red line. If I change padding to .375em, the inline-block is aligned correctly.
Comment 1 Philippe Wittenbergh 2014-08-27 23:18:17 PDT
Created attachment 237292 [details]
Screenshot

Pixie screenshot of test case 1
Comment 2 Philippe Wittenbergh 2014-08-27 23:21:54 PDT
Created attachment 237293 [details]
test case 2 (requires Ahem)

This is basically the same as test case 1, but using the Ahem font. Notice the gap under the red line (dominant baseline) and the different size of the inline-block vs the inline-span.
Comment 3 Han 2016-06-06 14:50:47 PDT
Created attachment 280635 [details]
This is still a problem in the latest WebKit nightly, r201711
Comment 4 Han 2016-06-06 14:51:17 PDT
Created attachment 280636 [details]
By contrast, this has been fixed in Chrome 50
Comment 5 Rob Brackett 2016-10-05 20:30:43 PDT
I’ve just run into this issue myself and spent quite a long time trying to get a few elements aligned.

Additionally, I noticed that `<button>` have a different offset from the dominant baseline than other inline-block elements (e.g. a `<span>`), even when they have `-webkit-appearance: none` set. Giving a `<span>` `display: inline-flex` makes it behave like the `<button>`, but still doesn’t fix the overall issue.

FWIW, I initially encountered this issue in a flexbox that contained a mix of spans and buttons, so it’s not just an issue for normal inline layout. I can attach my reduced test-case with buttons if it’s helpful.
Comment 6 Ahmad Saleem 2023-06-29 16:14:57 PDT
Seems to work fine with WebKit ToT (265630@main) using MiniBrowser (Ahem one) and match Chrome Canary 117, I think we can close this.
Comment 7 zalan 2023-06-29 16:30:40 PDT
Created attachment 466876 [details]
265546@main

This still looks broken to me.
Comment 8 Ahmad Saleem 2023-06-29 16:32:58 PDT
(In reply to zalan from comment #7)
> Created attachment 466876 [details]
> 265546@main
> 
> This still looks broken to me.

I used Ahem one, might have missed while doing CMD + Tab. Good catch!