-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to disable changing block into specific block according to first input #19566
Comments
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).
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. |
I think we shouldn't convert automatically if you are within a heading block and type |
I agree we have an easy win in this particular case, but I’m curious on thoughts about the approach generally. |
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 Q.º 1: How can we generalise assumptions about when Q.º 2: Other types of transformation support conditions such as the type of the source block. Q.º 3: Would an acceptable compromise be to have 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 |
Draft PR #19727 illustrates the API described in Q.º 1. |
I'd be inclined to say it only makes sense on a paragraph block; the same way slash inserter only works there. |
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. |
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.
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.
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. |
If someone can give this a better title, then please do! :)
When I want to add a H3 that starts with a number, like
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.
The text was updated successfully, but these errors were encountered: