Option to disable changing block into specific block according to first input

[ghost]

If someone can give this a better title, then please do! :)

When I want to add a H3 that starts with a number, like

1. Introduction
   the block immediately changes into a list block.

I can change it manually by going into the code editor, add the number and go back to the visual editor, but in general it would be very nice to have an option to disable this auto fill thing completely.

[mcsf]

I can change it manually by going into the code editor, add the number and go back to the visual editor

It's not a very discoverable feature, but you can use the standard Undo action (via the top-bar button or keyboard shortcut) to cancel the automatic conversion.

^ @mtias, I wonder how useful it would be to generally use snack-bar notifications for this sort of thing; see the same comment in #15102 (comment).

but in general it would be very nice to have an option to disable this auto fill thing completely.

Ideally we'd improve the overall experience so that the need for these configurations would be minimised. Otherwise these APIs can grow unsustainably. /cc @ellatrix in case you have thoughts.

[mtias]

I think we shouldn't convert automatically if you are within a heading block and type 1., that seems odd.

[mcsf]

I think we shouldn't convert automatically if you are within a heading block and type 1., that seems odd.

I agree we have an easy win in this particular case, but I’m curious on thoughts about the approach generally.

[mcsf]

I gave this a look and it seems there are a couple of questions to answer.

Note: Right now, any block using RichText is subject to this behaviour. The reason why this happens for some block types (e.g. Heading) but not others (e.g. Verse) depends solely on whether the block's edit function passes onReplace to RichTextContainer. Without onReplace, RichTextContainer's inputRule method is skipped.

Q.º 1: How can we generalise assumptions about when prefix transformations should automatically kick in and not? So far, I personally can't think of a scenario where a block other than Paragraph should ever auto-transform into something else. Should this behaviour only apply to the default block type? A similar alternative: should this behaviour only apply when a block type passes RichText a new prop such as __unstableAllowPrefixTransformations? If so, in the core project we would have core/paragraph pass this prop by default.

Q.º 2: Other types of transformation support conditions such as the type of the source block. prefix transformations do not; should they? I worry that this can make for a confusing interface very quickly. It's worth mentioning that prefix transformations are handled by RichTextContainer, thus with no knowledge of the calling block type. It's not that this can't be changed, but it begs the question: should any piece of RichText ever care about the outside block type? Or could it make more sense for transformations to look at the current tagName?

Q.º 3: Would an acceptable compromise be to have prefix transformations support an isEligible method?

---

I'd like to fix the Heading case quickly, but I think we need at least some answers to these questions first. :) /cc @mtias @ellatrix

[mcsf]

Draft PR #19727 illustrates the API described in Q.º 1.

[mtias]

I'd be inclined to say it only makes sense on a paragraph block; the same way slash inserter only works there.

[ghost]

Personally I think it is not right to have these transformations at all. First because choosing a block is already a kind of transformation, choosing auto formatting/changing the type of block after the first input really doesn't speed up editing, and lastly because it is the user who should decide how to use a block. When I as a user want to start a paragraph with a 1. because I want to add that line in bold and right underneath the rest of the text, or for whatever other reason, I should be able to do that without the block transforming into another type of block. These kind of automations will always in some or other way conflict with personal/creative wishes of the user.

[mcsf]

Personally I think it is not right to have these transformations at all. First because choosing a block is already a kind of transformation, choosing auto formatting/changing the type of block after the first input really doesn't speed up editing

Bear in mind that these features follow WordPress's principles around designing for the majority, aiming for simplicity, etc. As an editor, Gutenberg tries to find the right line between presenting a block-based editing experience and letting blocks fade away for a smoother experience. Prefix transformations allow users to follow conventions around text formatting so that their content is recognised and lifted into the appropriate block types. In this sense, this feature does speed up editing and does make editing easier.

lastly because it is the user who should decide how to use a block. When I as a user want to start a paragraph with a 1. because I want to add that line in bold and right underneath the rest of the text, or for whatever other reason, I should be able to do that without the block transforming into another type of block. These kind of automations will always in some or other way conflict with personal/creative wishes of the user.

These are the cases in which the automated behaviour is unwanted, and that's fine. This is also what Undo is for: a way to cancel the automation. As I said earlier in the discussion, I do believe there is room to improve how visible this feature is. But, by existing, the Undo feature enables us to introduce convenient automations with more confidence.

First because choosing a block is already a kind of transformation

This is why a concrete task from this issue is to make sure that prefix transformations don't apply to block types other than the default Paragraph type.