Allow white space HTML entities such as     in the Additional CSS Class option

[mipon]

Is your feature request related to a problem? Please describe.
I've been using a plugin for several years which allows the user to set options using class attributes and generates plugin outputs. The set options are something like <tag class="optionA:foo optionB:bar"> and the plugin converts the output into something else.

The problem is when the option value contains a white space. It was possible to insert   like <tag class="optionC:hi&nbsp;there"> with the classic editor. However, setting optionC:hi there in the Additional CSS Class option causes the invalid block message.

Other HTML entities such as © and & seem to be accepted.

Describe the solution you'd like
It seems Gutenberg converts those HTML entities set to the control into actual characters. So just leave the user input as it is.

Describe alternatives you've considered
Natively support additional inspector controls that allow the user to set custom tag attributes like data-foo="bar" title="Hi there!". The mentioned plugin also accepts options through custom attributes. It's possible to write a plugin that adds such controls but when it is deactivated those blocks with custom tag attributes become invalid with the current design.

[aduth]

The problem is when the option value contains a white space. It was possible to insert   like <tag class="optionC:hi&nbsp;there"> with the classic editor. However, setting optionC:hi there in the Additional CSS Class option causes the invalid block message.

I've verified that the block invalidation does occur. In that sense, I think there is a bug needing to be addressed in that the user should not be able to invalidate their own block by using the "Additional CSS Class" field.

To the original point, however, I'd wonder why you need to use specifically the HTML entity rather than just a space character?

[mipon]

@aduth

To the original point, however, I'd wonder why you need to use specifically the HTML entity rather than just a space character?

See here.

[aduth]

@aduth

To the original point, however, I'd wonder why you need to use specifically the HTML entity rather than just a space character?

See here.

It's still not entirely clear. Is the general idea that some plugins interpret values from a class name, where the class name may include spaces, while accounting for the fact that a space in a class name is typically the demarcation of a separate class? If so, it definitely seems like an edge case. That said, a resolution to the unintended block invalidation may incidentally allow for support.

[mipon]

It's still not entirely clear.

class=title:hi there is interpreted as array( 'title' => 'hi', ) while
class=title:hi there is interpreted as array( 'title' => 'hi there', ).

Is the general idea that some plugins interpret values from a class name, where the class name may include spaces, while accounting for the fact that a space in a class name is typically the demarcation of a separate class?

I'm not here to judge whether something is general or not. One generally accepted idea by the majority if I have to insist is that many functionalities have lost in the process of transferring from TinyMCE to Gutenberg. And this addressed issue is one of them; now it is unable to set values containing   in a class attribute.

If so, it definitely seems like an edge case.

About at least the users of a plugin with 50,000 active installations will be saved by fixing this. If you call the number is too rare to fix the problem, then, I'll tell them to use Classic Editor.