Improve conversion of blocks modified externally by other editors

[koke]

I've been testing the Aztec editors on iOS and Android, and the Classic editor for comparison, and bad things often happen when you edit Gutenberg content. A recent example is adding text before an image block:

1. Open a post with an image block in the classic editor (iOS and Android do something similar though)
2. Switch to visual mode and place the cursor in front of the image
3. Insert one or more characters
4. Switch to html mode and notice that the character(s) entered are inbetween the starting block comment and the element. That is not valid and causes the "modified externally" placeholder to appear.

The resulting HTML of that edit is:

<!-- wp:image {"id":96} -->
<figure class="wp-block-image">
some text
<img src="https://sandbox.koke.me/wp-content/uploads/2018/05/fullsizeoutput_52f7.jpeg" class="alignnone wp-image-96" alt="">
</figure>
<!-- /wp:image -->

To this, Gutenberg responds with a "This block appears to have been modified externally", and when you Convert to Blocks, it recovers the image block but removes the edited text.

I wanted to start the discussion of how can we make Gutenberg more resilient to external edits without losing content that the user has created somewhere else.

I think my proposal would be that whenever Gutenberg encounters some unexpected markup that could be considered as content that doesn't match what's expected, it turns into a classic block. I'm not too attached to this path though, but the current options seem insufficient:

• Convert to blocks loses content. You can undo, but short of going to the code editor and fixing manually, there's not much you can do
• Edit HTML. That's still HTML, and there's no way back, I'm surprised you can't convert a raw HTML block into at least a Classic one.

I'm missing a way to turn a mangled block into classic either automatically or by user's choice, then fixing whatever needs fixing visually, and then convert to blocks properly.

[danielbachhuber]

Related #6826 #7097

[mtias]

The invalid block message used to offer ability to convert to Classic. It was just too many options and not the best UX in the dialog. We should probably list all the options available in an ellipsis menu on the invalid block window (overwrite, keep as html, convert to classic, convert to multiple blocks, etc). cc @jasmussen

I don't agree Classic would be the best option in the above case as you will lose most of the image tools that are specific to Gutenberg. We could also have yet another option that retains the image block but extracts the extra markup into its own block.

I'm surprised you can't convert a raw HTML block into at least a Classic one.

There's a task for allowing this. Should be trivial to implement.

[koke]

I'm not too attached to Classic, but I think it's a slightly better fallback than throwing away part of the content. If we can safely extract that content into a separate block, I'm OK with that.

[jasmussen]

The invalid block message used to offer ability to convert to Classic. It was just too many options and not the best UX in the dialog. We should probably list all the options available in an ellipsis menu on the invalid block window (overwrite, keep as html, convert to classic, convert to multiple blocks, etc).

Specifically with regards to this, I feel like if the ideal solution is to make sure this dialog shows up as rarely as possible. If we can do that, then it's probably fine to have more options present. I'll doodle.

Switch to visual mode and place the cursor in front of the image
Insert one or more characters
Switch to html mode and notice that the character(s) entered are inbetween the starting block comment and the element. That is not valid and causes the "modified externally" placeholder to appear.

When you say "infront of the image", do you mean literally to the left of the image with a tall cursor, or above the image?

In Gutenberg you can't do the former unless it's an inline image. In that vein, would the merging of inline image support improve things here? Even if it looks like a block, if it's treated as an inline image in Gutenberg, it should give no validation errors?

Aside from that, and forgive me if this is a silly question, is there any way to ensure that it's hard for you to place the cursor between HTML comments that aren't text?

[koke]

When you say "infront of the image", do you mean literally to the left of the image with a tall cursor

Yes, that's the case. I wouldn't say the intent here is to have the image inlined. I can just put the cursor there because I want a paragraph before the image (a good example would be trying to add text between two images where there's no empty line to place the cursor), and as soon as I start typing, it seems to be just that:

Even if you tap return after you type and make the text a proper paragraph, it would still be inside the block. I've tested both classic editor and calypso (I'd expect something similar from Aztec) and this is the resulting HTML:

<!-- wp:image {"id":96} -->
<figure class="wp-block-image">test before</figure>
<figure class="wp-block-image"><img class="wp-image-96" src="https://sandbox.koke.me/wp-content/uploads/2018/05/fullsizeoutput_52f7.jpeg" alt="" /></figure>
<!-- /wp:image -->

is there any way to ensure that it's hard for you to place the cursor between HTML comments that aren't text?

I'm not an expert in editors myself, but from what I know it seems hard without adding a good amount of knowledge about Gutenberg to the editors. Even if you add logic to know about the comments and pretend they are pseudo HTML block elements, any new text inherits its style from where the cursor is at. Even if you could somehow glue the comment delimiters to the figure element (which feels like a big if to me), the inserted text would just split into another image block with the text inside a figure element.

Also, in the particular examples of images, they can have captions so that block can have text content.

[jasmussen]

I wouldn't say the intent here is to have the image inlined.

No, absolutely. I'm purely suggesting that once the Gutenberg support for inline images gets merged in, the "incompatible block" error message might disappear, as when that happens, Paragraph blocks will be able to contain images with no validation errors. Forgive me if that's unrelated.

[mtias]

Closing to consolidate on #7604.