Block editor: remove root appender #60697
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ellatrix
added
[Type] Enhancement
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +421 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
|
This is working well for me especially in the site editor where shown in this GIF is the appender causing layout shifts at the end of each document, including template parts edited in isolation mode:
This branch fixes that by omitting those appenders causing the shifts, as shown in this GIF:
One nuance is on the post editor, there's currently a heuristic to show this appender after the last block, if that block is not a text block. Shown here, the appender after an empty image, from trunk:
Here, the same case, shown without said appender: I think it's fine to remove it there, you click the image and press Enter. But you can't click the space below, to type text. |
|
By the way those two GIFs also show an issue that appears to be a regression in trunk: if you go to the site editor, edit a template part in isolation (focus mode), then exit out to site view and enter the site editor again, the site editor itself will be in focus mode. It seems like the query that gets appended when you enter template part editing mode ( |
|
@jasmussen I just pushed a commit to make the 40vh space below the blocks append a default block on click. |
|
That works great! Can that have any side effects in the numerous other editing contexts we have? |
|
I added it only for the normal post editing experience (where the typewriter is also active). This is not added for site editor post editing, where we also don't have the typewriter padding. I guess at some point we'll have to see if we can bring this experience to the post editor inside the site editor as well. In those cases we rely solely on Enter or the dropdown menu to append a block, which I think is also fine. Maybe one little thing we could do is show the appender when the last block is selected? But that would re-introduce the layout shift when clicking around. |
|
Maybe we should start with this and see how that feels? It's between releases. |
jasmussen
approved these changes
Apr 12, 2024
|
But it's worth noting that in the site editor, nothing is really changing from trunk, because the appender there gets added to the template root, not the post-content block. The post content block does have an appender, but only if you select the pos content block itself. |
richtabor
approved these changes
Apr 12, 2024
|
Removing the root appender may have affected accessibility. See #61391. |
|
@ellatrix and @jasmussen Let's say you insert 3 paragraph blocks and 1 image block for a total of 4 blocks. If I want to now add a 5th block, I can't do that because the image block is not a text block. Let's think from the perspective of a user with no vision, how has this experience been made better for them? I have real concerns with PRs like this one that touch lots of visual concepts and nothing is flagged for accessibility review. If you can give me a valid explanation as to how keyboard only users are supposed to be able to always add a block from the end of the content, I'll likely just go away. What I'm not going to accept is enter will do it in some blocks but not all. Accessibility is made possible by patterns, not guesses based on which type of UI you are in. Thanks. |
Enter should work from the block wrapper for all blocks. Is there one where this doesn't work? |
|
@ellatrix It's another one of those hidden patterns we're expecting users to figure out. For example, the paragraph block is the block wrapper so Enter key will add a new block if the caret is near the end. Yet another concept users must understand. If in an image block where focus is placed on the first tabbable by default, users would have to very specifically know to press Left Arrow then Enter to add a new block. I think at a certain level, this is fine for users like you or myself who understand how the editor works. For people who are simply trying to write a blog post with some different blocks, this could be the worst user experience. Even navigation mode made this a fairly hidden feature but I do not like to think about what happens if we remove patterns users have already discovered. The only other real discoverable method to add a block is via the add block button, right? I think you can get to it with a double Shift+Tab? |
youknowriad
reviewed
May 28, 2024
| @@ -53,6 +54,8 @@ export default function VisualEditor( { styles } ) { | |||
| [] | |||
| ); | |||
|
|
|||
| const paddingAppenderRef = usePaddingAppender(); | |||
There was a problem hiding this comment.
Should we move this one (and the padding bottom) to the "editor" package (VisualEditor component) instead? That way the same behavior would apply to pages (in non preview mode) in the site editor too.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Let's see what tests fail and how this tests manually.
If this isn't working for the post editor, I think this is a writing flow issue that we need to resolve differently.
Why?
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast