Update Block Styles Preview Pane Title

[shimotmk]

Resolves #40463

What?

Block Styles preview title character limit is removed to improve the look and feel of the title.

Why?

How?

Before

After

Testing Instructions

1. Refer to the following code to add a block style.

function twenty_twenty_two_register_block_styles() {
	// Hello,Hello,…
	register_block_style(
		'core/image',
		array(
			'name'  => 'twentytwentytwo-image-1',
			'label' => esc_html__( 'Hello,Hello,Hello', 'twentytwentytwo' ),
		)
	);

	// Hola,Hola,Ho…
	register_block_style(
		'core/image',
		array(
			'name'  => 'twentytwentytwo-image-2',
			'label' => esc_html__( 'Hola,Hola,Hola', 'twentytwentytwo' ),
		)
	);

	// こんにちは,こんにちは
	register_block_style(
		'core/image',
		array(
			'name'  => 'twentytwentytwo-image-3',
			'label' => esc_html__( 'こんにちは,こんにちは', 'twentytwentytwo' ),
		)
	);

	// 你好,你好,你好,你好
	register_block_style(
		'core/image',
		array(
			'name'  => 'twentytwentytwo-image-4',
			'label' => esc_html__( '你好,你好,你好,你好', 'twentytwentytwo' ),
		)
	);
}
add_action( 'init', 'twenty_twenty_two_register_block_styles' );

2. Go to the block editor and place the image block.

3. Open the side panel and look at the style preview.

Screenshots or screencast

[shaunandrews]

With long style names and text wrapping its very easy to end up with an unbalanced list of buttons, putting emphasis (via size) on some styles randomly. Here's a few examples:

This also leads to a rather tall list of of buttons, pushing down other (arguably more important) controls within the Inspector sidebar.

The existing design encourages the use of short style names, and truncating longer labels to keep a consistent interface.

[shimotmk]

I made an adjustment to change the width of the button when the style is odd.

First of all, we found that this issue had a bug in the character limit of the title of the block style depending on the language in which it is displayed.

At that time, we thought it was not appropriate to limit the number of characters in the title before adjusting the character limit.
This is because there was no example of a block or block pattern that also had a character limit on the title.
#40463 (comment)

[ramonjd]

I understand the reason why we want to wrap titles to accommodate CJK character widths, but removing the limit will impact all locales.

Also, what if the title wraps over three lines?

I'm not convinced the solution lies in adjusting the design, but rather, finding a way to deal with truncation of wide character centrally (in the truncate component) thereby spreading the benefit to all places in the app and to as many locales as we can.

[shimotmk]

Also, what if the title wraps over three lines?

I do not know what is better for me.

I thought the title should not be restricted, but if there is another way, I am willing to close this pull request.

[shaunandrews]

I'm not convinced the solution lies in adjusting the design, but rather, finding a way to deal with truncation of wide character centrally (in the truncate component) thereby spreading the benefit to all places in the app and to as many locales as we can.

Agreed with this. We can definitely consider updating the design — maybe using a single column display when necessary to accommodate long titles. But we should first resolve the underlying issue with the truncation to make the existing design work as intended.

[ramonjd]

Would it hurt to add an overflow: hidden to the button as a band aid measure?

[ndiego]

Simply allowing text wrapping seems like the easiest and most direct way to address this issue. While multiline descriptions do not look great, this is a choice made by theme authors and extenders. Truncating descriptions punishes people who want more verbose descriptions and also those that are using CJK characters.

[ramonjd]

Truncating descriptions punishes people who want more verbose descriptions and also those that are using CJK characters.

That's a fair point. Truncation tries to "solve" a difficult problem (or rather sweeps it under the mat) of variable lengths across locales. Would be keen to see some alternative designs. A dropdown? There I said it 😄

[mtias]

The consistent vertical weight is an important aspect of the usability of this design. I'm in favor of trying the truncation with ellipsis first. Style names are not meant to be complicated or verbose given they are fairly opaque.

[ramonjd]

The consistent vertical weight is an important aspect of the usability of this design. I'm in favor of trying the truncation with ellipsis first. Style names are not meant to be complicated or verbose given they are fairly opaque

Thanks @mtias !

Would using CSS text-overflow: ellipsis; be acceptable for now to make the UI "behave" until we can decide a neat approach via the <Text /> component?

Example diff

diff --git a/packages/block-editor/src/components/block-styles/index.js b/packages/block-editor/src/components/block-styles/index.js
index 0a86433096..5ac0bec2cc 100644
--- a/packages/block-editor/src/components/block-styles/index.js
+++ b/packages/block-editor/src/components/block-styles/index.js
@@ -115,15 +115,7 @@ function BlockStyles( {
 							onClick={ () => onSelectStylePreview( style ) }
 							aria-current={ activeStyle.name === style.name }
 						>
-							<Text
-								as="span"
-								limit={ 12 }
-								ellipsizeMode="tail"
-								className="block-editor-block-styles__item-text"
-								truncate
-							>
-								{ buttonText }
-							</Text>
+							{ buttonText }
 						</Button>
 					);
 				} ) }
diff --git a/packages/block-editor/src/components/block-styles/style.scss b/packages/block-editor/src/components/block-styles/style.scss
index bed73bfedf..e4840b03cd 100644
--- a/packages/block-editor/src/components/block-styles/style.scss
+++ b/packages/block-editor/src/components/block-styles/style.scss
@@ -42,6 +42,9 @@
 		box-shadow: inset 0 0 0 1px $gray-400;
 		display: inline-block;
 		width: calc(50% - #{$grid-unit-05});
+		text-overflow: ellipsis;
+		overflow: hidden;
+		white-space: nowrap;
 
 		&:focus,
 		&:hover {
@@ -53,10 +56,6 @@
 		&.is-active:hover {
 			background-color: $gray-800;
 			box-shadow: none;
-		}
-
-		&.is-active .block-editor-block-styles__item-text,
-		&.is-active:hover .block-editor-block-styles__item-text {
 			color: $white;
 		}

[mtias]

What is the current problem with Text?

[ramonjd]

What is the current problem with Text?

Ah, sorry. I forgot to add context. There was discussion about this over at the issue, which boils down to the following:

Chinese, Korean and Japanese (CJK) characters are about twice the width of latin characters.

When specifying limit={ 12 } for CJK via <Text />, we'll get 12 characters, but the combined width of those characters will be about the same as 24 latin characters.

I proposed a string width checker in the Text/Truncate component, but I haven't tested it and am not yet convinced it's a fabulous idea.

[shimotmk]

cosed at #42975