Changed character limit to be calculated from character width

[shimotmk]

Resolves #40463
Related #40807

What?

Changed character limit to be calculated from character width.

Why?

How?

This comment is used to calculate the width of the character count using the string-width package.
#40463 (comment)

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', 'twentytwentyone' ),
		)
	);

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

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

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

	// Hello,こんにちは
	register_block_style(
		'core/image',
		array(
			'name'  => 'twentytwentytwo-image-5',
			'label' => esc_html__( 'Hello,こんにちは', 'twentytwentyone' ),
		)
	);
}
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

[ramonjd]

Thanks for persisting with this one.

Things work as described in the browser, and functionality-wise, a good addition to the Truncate component I think.

My only question would be to ask whether the library is appropriate.

This package and its dependencies aren't actively maintained, and I'm wondering the utility is worth the bump in package size:

| `build/components/index.min.js` | 233 kB | +5.01 kB (+2%) |

(from the CI reports)

Plus jest doesn't seem to be able to compile the library via Babel.

Even so, do we care about possible ANSI or emoji characters?

Taking those away, it seems as if string-width relies mainly on eastasianwidth

Maybe we could get away with just using https://github.com/komagata/eastasianwidth?

I'm not sure. What do you think?

[mirka]

May I suggest we stick with the standard CSS truncation here (the overflow: hidden approach also mentioned by @ramonjd)? Using the Truncate-based components, we can achieve this by doing:

// Assuming `ellipsizeMode='auto'` and `limit=0`, which are the default values
<Truncate numberOfLines={ 1 }>
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
</Truncate>

My impression is that the character-based limit API is not scalable, both in terms of i18n and emojis. Something like string-width does compensate for those things, but then... how useful is the limit construct really? When would anybody actually want that? I'd think that most single-line truncation needs are based on the (often responsive) rendered width of the container element, not a character-based count/width.

I would probably discourage people from using limit unless they absolutely have to, for example if they need ellipsizeMode head or middle. I'm also open to deprecating this prop, as it is easy to misunderstand or misuse, whether or not we add string width compensation. What do folks think?

cc @ciampo

[ciampo]

May I suggest we stick with the standard CSS truncation here (the overflow: hidden approach also mentioned by @ramonjd)? Using the Truncate-based components, we can achieve this by doing:

// Assuming `ellipsizeMode='auto'` and `limit=0`, which are the default values
<Truncate numberOfLines={ 1 }>
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
</Truncate>

My impression is that the character-based limit API is not scalable, both in terms of i18n and emojis. Something like string-width does compensate for those things, but then... how useful is the limit construct really? When would anybody actually want that? I'd think that most single-line truncation needs are based on the (often responsive) rendered width of the container element, not a character-based count/width.

I would probably discourage people from using limit unless they absolutely have to, for example if they need ellipsizeMode head or middle. I'm also open to deprecating this prop, as it is easy to misunderstand or misuse, whether or not we add string width compensation. What do folks think?

100% aligned with the above, let's move forward with what suggested by @mirka !

[shimotmk]

Hi @mirka
I've made a new pull request based on the code you suggested, so please take a look at it.
#42975