Custom HTML block experience much like Groundhog Day

[bobbingwide]

Issue Overview

In 2.3.0 the Custom HTML block has been changed to include the recently introduced wp-codeeditor.
The user experience is not good. See for yourself.

Steps to Reproduce (for bugs)

1. Create a post containing two HTML blocks s below
2. View in the browser, the two blocks look pretty similar
3. Edit Block
4. Warnings appear in the first block regarding indentation
5. Resolve the problems
6. Save
7. Reload the page
8. Go to 4. or move on to the second block
9. Click on Edit as HTML
10. Notice it hasn't really changed.
11. Ignore the annoying warning signs
12. Update
13. Go to 7.
14. Go to 4. or 9.

<!-- wp:html -->
<p>Here's a list NOT inside a paragraph</p>
<ul>
    <li>One</li>
    <li>Two</li>
</ul>
<p>which is probably OK HTML</p>
<!-- /wp:html -->

<!-- wp:html -->
<p>Here's a list inside a paragraph
    <ul>
        <li>One</li>
        <li>Two</li>
    </ul> which is probably bad HTML
</p>
<!-- /wp:html -->

Expected Behavior

• Custom HTML blocks that don't prompt me to make unnecessary changes
• Blocks that accept the content as typed without saying it's been changed
• Behaviour similar to the Text widget

Current Behavior

See the Steps to reproduce and the animated git.
Additionally, take the following considerations into account

• The HTML | Preview tab should appear whenever you click into a tag as well as text in a different block
• Or when you change cursor from a tag to inner text
• HTML | Preview tab to appear more often when using iPad
• Update button should be enabled whenever the block is changed
• Consistent CSS styling in Preview
• Unexpected console messages

 Warning: Failed prop type: You provided a `value` prop to a form field without an `onChange` handler.

Possible Solution

Document the requirements that the Custom HTML block is supposed to satisfy
and develop tests to demonstrate it meets them.

Screenshots / Video

Related Issues and/or PRs

#5123

Todos

• Tests
• Documentation

[afercia]

Just tested a bit the Custom HTML block and I'm afraid there are a few big usability issues that make it basically unusable, in its current state. Seems to me the autocompletion feature, combined with the writing flow, is the root cause. A couple examples:

1

• start typing an HTML attribute, e.g. the type of a button
• a drop-down appears to suggest the available attribute values

• at this point, many users who are used to other code editors and to use just the keyboard to code, will try to use the arrow keys to select one of the values
• press arrow down
• the caret goes to the following block:

• expected: arrow down should cycle through the suggestions and allow to pick one of them, users shouldn't be forced to use the mouse

2

• type a double quote after the equal sign
• the autocompletion inserts two double quotes and places the caret in between:

• type button
• at this point the caret is at the end of the word button and before the closing double quote:

• you need to move the caret to the right
• it's very unlikely users will try to use the mouse for this
• as soon as you press the arrow right key, the caret goes to the following block:

These are just two examples, I've noticed other unexpected behaviors that break the way I'm used to write code (and I guess many other users are used to type code with the keyboard, resorting to the mouse very very rarely).
Being thrown out from the editable area while typing isn't the best experience for users, and I doubt this can be released in its current state.

[mtias]

The HTML block no longer includes syntax highlighting by default.