Bug 136332

Summary: Subpixel layout: Inline-block is offset from dominant baseline with em based padding
Product: WebKit Reporter: Philippe Wittenbergh <phiw2>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ahmad.saleem792, karlcow, rob, zalan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 133932    
Bug Blocks:    
Attachments:
Description Flags
test case 1
none
Screenshot
none
test case 2 (requires Ahem)
none
This is still a problem in the latest WebKit nightly, r201711
none
By contrast, this has been fixed in Chrome 50
none
265546@main none

Philippe Wittenbergh
Reported 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.
Attachments
test case 1 (1.78 KB, text/html)
2014-08-27 23:17 PDT, Philippe Wittenbergh
no flags
Screenshot (48.30 KB, image/png)
2014-08-27 23:18 PDT, Philippe Wittenbergh
no flags
test case 2 (requires Ahem) (1.42 KB, text/html)
2014-08-27 23:21 PDT, Philippe Wittenbergh
no flags
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
By contrast, this has been fixed in Chrome 50 (13.31 KB, image/png)
2016-06-06 14:51 PDT, Han
no flags
265546@main (7.16 KB, image/png)
2023-06-29 16:30 PDT, zalan
no flags
Philippe Wittenbergh
Comment 1 2014-08-27 23:18:17 PDT
Created attachment 237292 [details] Screenshot Pixie screenshot of test case 1
Philippe Wittenbergh
Comment 2 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.
Han
Comment 3 2016-06-06 14:50:47 PDT
Created attachment 280635 [details] This is still a problem in the latest WebKit nightly, r201711
Han
Comment 4 2016-06-06 14:51:17 PDT
Created attachment 280636 [details] By contrast, this has been fixed in Chrome 50
Rob Brackett
Comment 5 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.
Ahmad Saleem
Comment 6 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.
zalan
Comment 7 2023-06-29 16:30:40 PDT
Created attachment 466876 [details] 265546@main This still looks broken to me.
Ahmad Saleem
Comment 8 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!
Note You need to log in before you can comment on or make changes to this bug.