Gutenberg: Remove the "Edit as HTML" button from blocks that don't support editing of their HTML

[azaozz]

Because of the way most blocks save user input, they don't support editing of the HTML. In spite of that we have an "Edit as HTML" button for each block which, in most cases, doesn't work properly. There are two options to fix this: either the blocks need a way to "read" and "understand" HTML (tags, attributes, text, all of it), or we should remove the "Edit as HTML" buttons from them.

Currently we end up "blaming the user" for editing the HTML and "breaking" the block. This ends up as pretty bad user experience.

What happens:

1. We tell the user: "Here is a button to edit the HTML" (implied: "if you know what you're doing"). This is the same as in the classic editor.
2. The user believes us and edits the HTML.
3. Then, when the user tries to switch back to continue editing we tell them: "Oops, it appears you edited the HTML? Too bad, your HTML may be OK, but you cannot use the (visual) editor any more. You must throw away your changes/content or convert to another block type if you want to use visual editing again".

I understand that some HTML in some blocks can be edited successfully (only in classic block?). However there is no indication where and which HTML. I'm also aware that most users don't edit the HTML. This is an advanced feature inherited from the classic editor where it was needed much more often.

In that terms the best (IMHO) solution is to remove the "Edit HTML" buttons from blocks that don't support it, including the global "Edit HTML" button. Being an advanced, rarely used feature makes this a perfect candidate for implementation by a plugin. Of course "Edit HTML" should still be available for blocks that fully support it like the classic block.

Another (perhaps less appealing) possibility to mitigate the bad user experience would be to offer to convert blocks where the HTML was edited to "classic" blocks instead if "html" blocks. Then we won't be locking users away from continuing to edit "visually".

Yet another possibility would be to add "Convert to HTML block" to all blocks that don't support editing of the HTML. Then the users will at least be aware that if they edit the HTML they won't be able to edit "visually" afterwards.

Related: #8950, #8450, #7604, #8131.

[GlennMartin1]

An alternative would be to keep it mostly as-is, but rename the label.

Instead of Edit HTML, it could be renamed to Code HTML (advanced). Both the word Code (instead of Edit), and the added word advanced would forewarn the user.

It won't make good press to require an additional plugin for Gutenberg to accomplish the same thing that's done in Classic.

[azaozz]

Not sure if changing the label would be enough here. The issue is that the block "breaks" after editing the HTML and needs to be "reverted" or the block type has to be changed. This should be made very clear before the user attempts it.

The "smallest change" would be to remove the "Edit HTML" and add "Convert to HTML block" for all blocks where the HTML cannot be edited.

It won't make good press to require an additional plugin...

Frankly I'm not that concerned about (temporary) good press/bad press. I'm concerned about making the best editor we can :)

I agree that editing of the HTML should always be available in the classic block. That corresponds to the behavior of the classic editor. However don't think we should have "Edit HTML" for blocks where the HTML cannot be edited just to say that we have some "parity". That feels quite wrong.

[johngodley]

An interesting idea, and it does sound sensible. I've been looking at a bunch of stuff to improve the 'edit as HTML' validation experience (#7604), but I didn't take a step back to think if the feature was necessary. If this is changed to 'convert to HTML block' then the need for a lot of the validation experience disappears.

I'm fairly new to Gutenberg so I don't know a lot of background. Pinging @mtias for thoughts regarding this and #7604

[jrchamp]

In case this is still the right place to have this discussion, it seems like if the block uses a render_callback that it might not make sense to show this option ever.

[chrisvanpatten]

I would love to see this exists in a supports-style property, e.g. supports.edithtml = false (with the default as true for backcompat).

[mtias]

@chrisvanpatten that is already possible with:

supports: {
    html: false,
},

We are also already showing a "keep as HTML" when a block breaks. I think we can close this issue and continue to optimize that flow. I'm not sure using render_callback as the heuristic would work well in practice, since every block can be augmented that way.