Bug 274308 - (regression) -webkit-line-clamp showing one line less line with inline-block
Summary: (regression) -webkit-line-clamp showing one line less line with inline-block
Status: RESOLVED DUPLICATE of bug 277949
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Safari 17
Hardware: Mac (Apple Silicon) macOS 14
: P2 Normal
Assignee: zalan
URL:
Keywords: BrowserCompat, InRadar
Depends on: 261030
Blocks:
  Show dependency treegraph
 
Reported: 2024-05-17 05:15 PDT by Tanel Terras
Modified: 2024-09-04 06:24 PDT (History)
7 users (show)

See Also:


Attachments
rendering in safari, firefox, chrome (479.29 KB, image/png)
2024-05-22 01:32 PDT, Karl Dubost
no flags Details
minimal tescase (891 bytes, text/html)
2024-05-22 01:45 PDT, Karl Dubost
no flags Details
rendering in safari, firefox, chrome (minimal test case) (253.07 KB, image/png)
2024-05-22 01:46 PDT, Karl Dubost
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tanel Terras 2024-05-17 05:15:28 PDT
It seems that with fixes and changes in Safari 17, `-webkit-line-clamp` and `display: inline-block` causes weird bugs.
When clamped content includes elements with `display: inline-block`, -webkit-line-clamp value seems to subtracted by one (at least visually).

Examples: https://lit.dev/playground/#gist=4f7950f5ad46952aac643c501fa68f4e
Reproduction case includes two examples: Web Component that has slotted content (like in our Design System) and a regular lightDOM example with exact same visual behaviour.

When compared with Safari 16 the handling of `inline-block` element was much different - it seems to me visually that Safari 16 handled inline-block as inline element and in Safari 17 as block element.

Chrome and Firefox handle these cases as expected (by me) so figured it is a bug specific to Safari 17. Although Safari < 17 also has its quirks it is somewhat manageable in our use cases.
Comment 1 Tanel Terras 2024-05-17 05:28:00 PDT
Interesting observation from our Design System is also that when -webkit-line-clamp is toggled, Safari 17 clamps correctly after reassignment of -webkit-line-clamp.  

We are toggling on button click, then reassign -webkit-line-clamp with same initial value through JS.
Comment 2 Karl Dubost 2024-05-22 01:32:39 PDT
Created attachment 471469 [details]
rendering in safari, firefox, chrome

Thanks a lot Tanel for the report

1st paragraph shows 
  1 line in Safari 
  2 lines in Firefox/Chrome
2nd paragraph shows 
  2 lines in Safari 
  3 lines in Firefox/Chrome

Probably needs a simpler testcase. :)
Comment 3 Karl Dubost 2024-05-22 01:45:49 PDT
Created attachment 471471 [details]
minimal tescase

Load this testcase in all 3 browsers.
Comment 4 Karl Dubost 2024-05-22 01:46:45 PDT
Created attachment 471472 [details]
rendering in safari, firefox, chrome (minimal test case)

We can the difference in Safari when it includes an inline-block content.
Comment 5 Radar WebKit Bug Importer 2024-05-22 01:47:17 PDT
<rdar://problem/128527752>
Comment 6 Karl Dubost 2024-05-22 02:02:48 PDT
It's indeed a kind of regression.
Old build shows 2 lines but with the inline block being visible.
Comment 8 Karl Dubost 2024-05-22 02:31:47 PDT
<rdar://problem/128527752>
Comment 9 Karl Dubost 2024-05-22 02:36:34 PDT
So the fix from Alan, remove the inline block inside the line-clamp, but also in the same time reduced the line-clamp by one line. :)
Comment 10 Tanel Terras 2024-05-23 06:21:06 PDT
Thanks for looking into this!

Sorry for the overly complicated testcase. I was in process of ruling out that <slot> and its `display: contents` affect this somehow.
Comment 11 Tanel Terras 2024-09-04 05:46:45 PDT
Any updates on this regression?
Comment 12 zalan 2024-09-04 06:24:14 PDT
This works on trunk, processed at https://commits.webkit.org/282348@main (going to forward dupe it).

*** This bug has been marked as a duplicate of bug 277949 ***