Site Editor Layout Breaks When changing existing names of Font Sizes with Long Names in theme.json

[snehapatil2001]

Description

• When updating existing font sizes with long names in the theme.json file, the Site Editor layout breaks when selecting these font sizes. The issue results in the text overflowing and overlapping with other elements in the Site Editor panel, making the layout look misaligned and negatively impacting the user experience.
• This happens when the font size names are long enough to extend beyond the available space, causing visual disruptions and layout issues.

Expected behavior

Font size names with long text should be properly truncated with an ellipsis or wrapped within the available space, preventing any overflow or layout issues in the Site Editor.

Step-by-step reproduction instructions

1. Open your theme's theme.json file and update the existing font sizes with long names. Example:

   {
     "settings": {
       "typography": {
         "fontSizes": [
   	{
   		"fluid": false,
   		"name": "Small small small small small small small small small small small small small small small",
   		"size": "0.875rem",
   		"slug": "small"
   	},
         ]
       }
     }
   }

2. Navigate to the Site Editor (Appearance > Editor).
3. Open the Typography panel and select one of the custom font sizes with a long name.
4. Observe how the Site Editor layout breaks, with text overlapping or causing a horizontal overflow.

Screenshots, screen recording, code snippet

Screen.Recording.2024-12-27.at.3.17.15.PM.mov

Environment info

• WordPress: 6.8-alpha-59561
• PHP: 8.1.29
• Server: nginx
• Database: MySQL 8.016
• Browser: Version 131.0.6778.205
• OS: macOS
• Theme: Twenty Twenty-Five
• Plugins: Gutenberg 19.9.0

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Mamaduka]

Thanks for contributing, @snehapatil2001!

I believe this is the same or similar to #68271.

cc @yogeshbhutkar

[snehapatil2001]

Thanks for the feedback, @Mamaduka

• The issue I reported differs slightly from #68271. The previous issue was related to dropdown created when adding new font sizes in the theme.json.
• However, my issue focuses on updating existing font sizes name. In this case, no dropdown is created. Instead, the font size name is displayed beside the label in the Site Editor, and when the name is too long, it overlaps with other elements.
• I did try implementing the changes from the PR associated with #68271, but unfortunately, it doesn’t resolve this specific issue. Let me know if you’d like me to provide additional details or screenshots to clarify further.

[yogeshbhutkar]

It seems this change originates from this PR, where the update aimed to align the FontSizePicker control's header spacing (label + toggle) with the spacing used across the design tools.

That said, it appears to have been assumed that labels would not exceed a height of 16px. However, this raises some concerns about how labels that span multiple lines might behave within this updated layout.

This bug can be fixed by removing this CSS rule:

gutenberg/packages/components/src/font-size-picker/styles.ts

Line 22 in f1fadbb

height: ${ space( 4 ) };

But that would break the spacing again. Alternatively, the label can be truncated to fix the bug.

cc: @snehapatil2001

[t-hamano]

Two approaches have been proposed to this issue.

@WordPress/gutenberg-design Which approach do you prefer?

#68383: Show all the text

#68452 Truncate text

[Mayank-Tripathi32]

#68452 Truncate text

Honestly, I believe this approach would result in a better design. We could implement a hover dialog to display the full text when needed.

Why?
Text can often exceed three lines, and truncating it would provide a cleaner, more user-friendly interface.

[yogeshbhutkar]

This overflow issue was previously identified in the dropdown elements in PR #68280, which was addressed by truncating the text. To maintain consistency, I believe we should apply a similar solution here.

Additionally, since the bug persists and remains unresolved, it would be beneficial to reach a design consensus to address this issue comprehensively.