Persist custom CSS classes during block conversion when block supports additional classes

[benoitchantre]

Issue Overview

When converting a Classic block to blocks, existing classes are removed. CSS classes can have been added manually (edit as HTML or TinyMCE text mode) and should be kept to preserve the appearance of the content.

Steps to Reproduce (for bugs)

1. Add a Classic bloc and copy the code below when editing as HTML
2. Convert to blocks

<h2>Paragraph with CSS classes</h2>
<p class="custom-class-1 custom-class-2">Sed quae tandem ista ratio est? Ipse Epicurus fortasse redderet, ut Sextus Peducaeus, Sex. Aberat omnis dolor, qui si adesset, nec molliter ferret et tamen medicis plus quam philosophis uteretur. Ne amores quidem sanctos a sapiente alienos esse arbitrantur. Hoc non est positum in nostra actione. Quacumque enim ingredimur, in aliqua historia vestigium ponimus. <i>Non quam nostram quidem, inquit Pomponius iocans;</i></p>
<h2>List with CSS class</h2>
<ul class="custom-class">
<li>Utrum igitur tibi litteram</li>
<li>Videor an totas paginas commovere</li>
<li>Videamus animi partes, quarum est conspectus</li>
</ul>

Expected Behavior

Each block should keep its classes.

Current Behavior

Block classes are removed

Tested with Gutenberg 2.1

[youknowriad]

Converting to blocks can be a bit destructive because it's very hard to ensure all kind of markup is transformed properly, that's one of the reasons it's an explicit action instead of an automatic migration. so I'm considering this as an enhancement.

That said, it would be nice if we could add these extra classNames as custom classNames (Inspector control) when the block supports it.

[danielbachhuber]

@WordPress/gutenberg-core Can you provide technical direction on how I should implement this?

[youknowriad]

The idea would be to be to create a custom matcher for the className, it would be used only internally to parse the custom className attribute (removing the generated className and assigning the remaining classes to the className attirbute)

This all would happen in editor/hooks/custom-classname.js. We'd have to change the definition of the className attribute and use the new "source" (something like "source: customClassname", it would be awesome to have a mechanism to define custom sources, but until we have it it's fine to hardcode this custom source in the parser blocks/api/parser.js) instead of persisting the custom className into the comments attributes.

[designsimply]

Re-opening because I tested with 3.4 and found that #7538 fixes the case where adding classes in html mode resulted in an invalid block but did not address the case where the class attribute is removed when using "Convert to Blocks." Since it has come up a number of times in feedback, this issue should remain open for debate.

Also closed #8275 as a duplicate.

[danielbachhuber]

did not address the case where the class attribute is removed when using "Convert to Blocks." Since it has come up a number of times in feedback, this issue should remain open for debate.

Interesting. My understanding was that both scenarios had been addressed..

[aduth]

Discussing this with @designsimply , the main issue preventing the classes from being preserved is that they are removed during the Raw Handling processing. The behavior implemented in #7538 would be capable of preserving the class if the 'raw' transform was to receive the node with classes intact.

[maddisondesigns]

Is this going to be fixed? #7538 says it's been merged but as of Gutenberg 4.0 Convert to Blocks is still stripping classes.

[samhermes]

Seeing the same as @maddisondesigns. This would be super helpful to have.

[youknowriad]

Tried again and it seems like this is fixed

[changochivo]

It seems this problem has come back!