Size Change: +88 B (0%)

Total Size: 835 kB

_{compressed-size-action}

Kind of ridiculous that I haven't fixed this earlier. Requires a new RichText prop though because the behaviour is quite different from onSplit.

It's fine. The most important part is that the proposal is finally there :)

Should it be marked an unstable API at first?

Should it be rather onEnterAtEnd?

Should Enter from the middle of a caption create a new empty paragraph below? Maybe be a nicer experience.

For the blocks that have a single item and the caption as the last item, it could move the content after the cursor to a new block. You can explore it separately.

To do: add this to all other blocks with a caption. Which makes me wonder... should we create a figure-caption component to be used in blocks?

The shared component for caption would be awesome 👍

Super bonus points, Image block could be constructed out of the nested Media (Image variation) and Paragraph (Caption variation) blocks, the container block would have template locking that, doesn't allow to add or remove blocks but maybe you could reorder them :)

Should it be rather onEnterAtEnd?

Since we've used split and merge for other props and APIs, I think split might be better? I'm not sure.

For the blocks that have a single item and the caption as the last item, it could move the content after the cursor to a new block. You can explore it separately.

I was thinking about that and tried that first, but to be honest I like the subtle boundary between between the blocks. If we implement text splitting of a caption, we also have to implement merging a paragraph with an image. I'm not sure if that makes sense.

Oh I guess onEnter can make sense if it's implemented full by the block and doesn't necessarily add splitting.

Related to: wordpress-mobile/gutenberg-mobile#426

From my tests this breaks the insertion of multiple lines on the following blocks:

• pre
• code
• verse

On mobile and web.

I'm guessing some props need to be update on the use of RichText component there, or define a default value for the prop that behaves as before.

@SergioEstevao Yes, I'm aware of it, the e2e tests did not pass for those. It should be fixed now.

Ooh this will be super valuable!