Additional classes not removed when editing as HTML

[mmtr]

Describe the bug
When we edit as HTML a block containing additional classes, if we try to remove one of them, they are actually kept on the block content. The only way to remove them is from the sidebar.

To Reproduce

• Create a quote block
• Edit the HTML of the quote block and add another class in the <blockquote>:
  <blockquote class="wp-block-quote new”><p>fdsfsdfsdd</p></blockquote>
• Update the post and confirm you can see the new class on the published post.
• Edit again as HTML the block and remove the new class.
• Update the post.
• ⚠️The new class is still on the published post.

Expected behavior
The new class should be removed from the block.

Video

[draganescu]

The problem here might be solved if the Edit as HTML option would show the full block syntax.
For example, a quote block with a custom CSS class:

• if seen in Edit as HTML mode:

<blockquote class="wp-block-quote custom-css-class"><p>Nullam quis risus eget urna mollis ornare vel eu leo. Cras mattis consectetur purus sit amet fermentum.</p><cite>Nullam Ornare Vestibulum</cite></blockquote>

• if seen as code in the Code editor view:

<!-- wp:quote {"className":"custom-css-class"} -->
<blockquote class="wp-block-quote custom-css-class"><p>Nullam quis risus eget urna mollis ornare vel eu leo. Cras mattis consectetur purus sit amet fermentum.</p><cite>Nullam Ornare Vestibulum</cite></blockquote>
<!-- /wp:quote -->

I'm missing why are they different. It would require some convoluted fix to also remove the attribute if the custom class name is removed for an edge case where things would be clearer for the the advanced user if we'd present the whole picture beforehand. So, I suggest that we show the full block syntax when a block is edited alone as HTML.

cc @aduth

[aduth]

I seem to recall a worry that including the block comment demarcations in the block-level "Edit as HTML" would have been both overwhelming and lead to a higher risk of human error (e.g. removing or otherwise mangling the comments). I think it was the hope that the majority of changes a user might want to make through "Edit as HTML" wouldn't require a modification of the block comments. In some cases, this is still true (e.g. editing the markup of a paragraph, or most RichText fields for that matter). Unfortunately, it's not always the case. Sometimes it can highlight a problem of the block implementation if the markup and comment attributes are so heavily co-dependent. Other times it may be perfectly valid.

We certainly could show the full markup, including the block comments. There may be some benefit, but also some risks as noted.