Creating a new color in multibyte character, the style in editor will be broken.

[iidastudio]

Description

When creating a new color in Editor>Style>Pallet>Custom, the editor style is broken if a color name is created using multibyte characters such as Japanese or Emoji.

Especially when the language setting is Japanese, the default name is "color1", which is broken as it is.
Japanese default value should be "color1" to disable input of multibyte characters or not break when typed.

Also, the css custom properties created in theme.json (--wp--preset--xxxx,--wp--custom-xxxx) are not output in the above action, which seems to break the style.

Step-by-step reproduction instructions

1. Editor>Style>Pallet>Custom
2. Create a new color name with multibyte characters
3. Save and Reload
4. Check the editor's style
5. Try renaming the colors you create.
   Try also if you set the language to Japanese.

Screenshots, screen recording, code snippet

editor-style-bug.mov

Environment info

WordPress 5.9.1
Gutenberg 12.6.1
Chrome 98.0.4758.109

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

[delowardev]

Actually, this bug comes from the CSS parser, here allowed characters for the CSS properties are /^(\*?[-#\/\*\\\w]+(\[[0-9a-z_-]+\])?)\s*/; (But in reality, CSS custom properties support emojis and other language characters too)

Parser prop matcher:

gutenberg/packages/block-editor/src/utils/transform-styles/ast/parse.js

Line 244 in d591591

let prop = match( /^(\*?[-#\/\*\\\w]+(\[[0-9a-z_-]+\])?)\s*/ );

I think the easiest solution will be allowing only these /^(\*?[-#\/\*\\\w]+(\[[0-9a-z_-]+\])?)\s*/ characters in the color name field as its being used as CSS custom properties. Thoughts?

[t-hamano]

This issue may also be related to #49711.

[t-hamano]

The root cause of this problem is probably the use of the kebabCase() function in many places where color slugs are generated.

This function is a paramCase in the change-case library and replaces or removes non-Latin characters with hyphens. If all characters are multibyte characters, all characters will be deleted and become empty.

Here are some of the codes that are causing the problem.

In custom palettes, multibyte characters are deleted when palette labels are changed:

gutenberg/packages/components/src/palette-edit/index.tsx

Line 229 in ab97d28

kebabCase( nextName ?? '' ),

Multibyte characters are removed when generating CSS variables with --wp-preset-- prefix:

gutenberg/packages/block-editor/src/components/global-styles/use-global-styles-output.js

Line 81 in ab97d28

`--wp--preset--${ cssVarInfix }--${ kebabCase(

I think the easiest solution will be allowing only these /^(*?[-#/*\\w]+([[0-9a-z_-]+])?)\s*/ characters in the color name field as its being used as CSS custom properties. Thoughts?

I hesitate to take the approach of limiting input characters. Users will want to name their custom palettes based on their language. Ideally, I think it should generate a unique and appropriate slug for whatever characters are entered.

[t-hamano]

Currently custom palettes do not generate a slug from the label, but generate a unified slug called --wp--preset--color--custom-{position}.

This issue is no longer occurring, so I'm closing this issue.

However, if we add a palette via theme.json, we can define any slug and will experience similar issues. This issue is tracked as #49711.