Block Editor: Improve the Select/Navigation mode and keep it persistent #65055
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
…nt after making changes
youknowriad
added
[Type] Enhancement
|
Size Change: -25 B (0%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
I do too, but I'm not confident that nested groups should be selectable. Makes it feel overwhelming quickly.
|
|
I do think there's merit in the simplified Inspector in this mode as well (with contentOnly), where it retains the top-level block.
|
That feels like a contradiction to me. So I would like to clarify what you mean. For me when you say nested groups shouldn't be selectable, it means "no drill down" and just top level selectable with leafs editable (like synced pattern with overrides). But what happens for things like "Media & Text" block, it's also a container block but I'm guessing you would want to be able to select it to change position of the image or the image itself... Btw, how do I reproduce the last screenshot you shared above? Is it a synced pattern? Something else? |
Add |
|
The thing I like about the approach in this PR is that you can still insert inner blocks for things like Buttons and Lists. In principle, I also see the argument for reusing the existing "Select" mode and not adding any more "modes" to the editor. If we're aiming for a simplified editing experience however, I would not want to have to see all the Group blocks. It's too overwhelming even with the "click through". I feel the I also don't like the custom toolbar of the existing It's good that we're exploring alternative UX approaches in all these PRs. For me, it's critical that we devise the right experience before we get "bogged down" in implementation details. |
|
I'd like this as an alternative to #65027 if clicking on a content block (Paragraph, Image, etc.) selected that block immediately instead of requiring you to drill down and if the List View appeared flattened. Maybe it doesn't even need to be a separate mode, just enabled on all patterns. |
I'd still expect to be able to edit content, not any layout elements. For example, for Cover both Media & Text I'd expect the "Replace" button in the toolbar, for replacing media, and to be able to select the contents of them. |
|
I'm going to close this. Happy if this sparked some discussion and thoughts about the most viable approach. Let's see where you folks take this next. |
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.
Related to #64866.
Alternative to #65027
Still pretty exploratory as well.
This PR takes an alternative approach to #65027. Instead of introducing a new mode that mixes multiple things (content only...), it starts from the premise that the existing "Select mode" can already be a good mode to a design tool. By making small tweaks to how it behaves we can improve the situation a lot and even consider this mode as the default in some situations later (site editor...)
So what this PR focuses on is the following:
Downside:
Personally, I feel this is already an improvement over trunk for the "select" mode so I'm going to keep this PR small to try to get some feedback on this part only.
That said, if this is a direction we want to pursue, there's a lot of things we can improve here and consider as follow-ups:
Testing instructions