Select Mode: Use the content-only behavior in select mode #65204
Conversation
youknowriad
added
the
[Type] Technical Prototype
|
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. |
| @@ -40,83 +40,38 @@ function BlockStylesPanel( { clientId } ) { | |||
| ); | |||
| } | |||
|
|
|||
| function BlockInspectorLockedBlocks( { topLevelLockedBlock } ) { | |||
There was a problem hiding this comment.
Instead of creating a custom "inspector control" for "content only" mode (and similar), I refactored this component to reuse the same block inspector control component by passing a "isContentLockingParent" flag instead.
There was a problem hiding this comment.
This makes everything easier to reason about 👍
| </PanelBody> | ||
| ) } | ||
|
|
||
| { ! isContentLockingParent && ( |
There was a problem hiding this comment.
Right now, we hide all "inspector controls" because our APIs Slot/Fill assume that we always want to render the "selected block"'s controls. It's not the case for "content only".
There was a problem hiding this comment.
I think that's ok for now in this PR. We'll want to follow up shortly afterwards to see if we can render the controls for the selected block.
Alternatively we can explore drill down.
| templateLock === 'contentOnly' || | ||
| ( editorMode === 'navigation' && | ||
| ! sectionsClientIds.includes( clientId ) ) | ||
| ) { |
There was a problem hiding this comment.
The change here is what "flattens" the tree in "navigation" mode.
|
Size Change: -2.11 kB (-0.12%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
youknowriad
requested review from
ajitbohra,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
The change in select mode means the "block moving mode" doesn't work anymore. I decided to remove it in the last commit for the following-reasons:
|
There was a problem hiding this comment.
Thanks for bringing together the ideas in a coherent PR 👍
What I like about this PR:
- the canvas selection is flattened - I can only select "content"
- the block toolbar is simplified - although we may need to tweak what is/isn't shown.
Things to consider for improvement:
- we should hide the
<BlockVariationTransforms>component. On the Group block especially it's a "layout" thing and should be avoided. - in List View removing any
blockEditingMode === disabled"container" type blocks (e.g. Group, Columns, Cover...etc) that are descendants of the "sections" (i.e. are not the sections themselves) would help to simplify the tree for users. A lot of the complexity comes from too many layout blocks being visible. - we could consider using a "Dark" block toolbar - I think this will help signify to the user that they in a particular mode.
- (probably one for a follow up) on many blocks the available controls are too limited. For example on the Heading block we should allow changing the level.
- a couple of times I saw the List View completely flatten itself. This seemed to be an intermittent bug and I wasn't able to narrow down the reproduction steps. I will update here when I figure it out.
- I couldn't hit
ENTERto add a new paragraph.
|
I think we need to codify what this means. What controls do we want to allow an why. So far this PR is about "content only" mode. But "level" is not considered content. What is the impact of this on "patterns" or "contentOnly" locking... We shouldn't be thinking about this mode in isolation. Right now this "content lock container" mode is enabled for these three cases:
When a container is considered "content lock container", it triggers a few things:
This is good for me. But it assumes that we want to keep a consistent behavior between these cases. Do we really want that? If not, why? and what are these differences. For instance, when you say "allow level" for Heading. Sure, I can see how that is useful for "select mode" but do we want the same for "patterns/reusable blocks"? Also, how to codify that: is it a block author's decision? is it something based on attribute roles (level is not content)... |
I agree and I appreciate the prompt to look at this holistically. Thanks for raising the other use cases. I'm aware of (most) of them and I haven't forgotten about them. In this review however, I was specifically focusing on the UX experience of how editing in a "simplified mode" feels. What are the benefits/drawbacks...etc. This is because you specifically referenced prior work in this area as the genesis of this PR. My thought was once we know how we want this experience to feel, we can cross reference with other potential use cases (patterns...etc) and decide if there is sufficient overlap or whether we need a different approach between the various scenarios. For example, some things we might wish to enable in a "simplified mode" for general editing would not work well with Patterns. Happy to dive into the various scenarios and codify the differences in a more indepth review. |
youknowriad
force-pushed
the
update/content-only-select-mode
branch
from
66a01ed
to
df55f3a
Compare
|
@getdave I realize that I didn't clarify my opinion on your previous behavior suggestions. Sometimes I have the tendency to share a minimal reply. I think the suggestions are great. I would add that maybe we should also show the "block toolbar" for the "content locking container" in addition to the toolbar of the selected block. And maybe remove the "block transforms..." from the selected block (treat it like an inline toolbar) |
I do miss being able to select the content locking container (pattern). |
Interesting idea. Actually for me, I think it should be the opposite. "edit" mode (weird name though) is ideal for templates and pages for me as you can actually compose patterns, you insert ready to use patterns from the inserter and only edit their content, if you want to dive into the details, you switch to design mode. |
|
@jameskoster the current PR is not great for that yet (pattern composition) because of this #65204 (comment) |
|
My preference regarding 6.7 would be to ship Zoomed Out Mode in 6.7 and leave the Design/Edit tool in the plugin.
Totally agree with this. To me it's "block mode" versus "pattern mode". |
I totally agree that a pattern-centric edit experience makes a ton of sense in many scenarios, while a block-centric experience makes sense in others. There are just a few missing pieces in the pattern-centric mode as it exists in this PR that make the experience quite lacklustre in the template editing context specifically. For example if you edit TT4 page template, you can only select / edit contents in the footer which feels quite unexpected to me. Agree the naming isn't helping matters. I know you mentioned this is planned elsewhere, but I think being able to select / re-order sections would help a lot, as would a way to ergonomically drill into each section and edit the composite blocks. One thing I'm curious about is how 'Edit' mode should treat root level blocks like Title, Featured Image, and Content when template editing. Technically I suppose they wouldn't be selectable, but I worry that might feel strange to use. |
|
I opened #65485 for exploring changes to the block toolbar (including selecting and moving sections) |
|
I think right now, we need to find a way to move forward here. We know it's not the ideal experience yet but we have to find a way to iterate towards it. We can't keep building on a single PR forever. Since it's not the default mode, you have to explicitly switch, I think it might be ok to land this PR and we continue iterate on the remaining bigs separately like the block toolbar PR above. Also, we're now past the 6.7 deadline in Gutenberg. |
|
One thing I would like to do before merging is to rename "Design" and "Edit" to either "Advanced", "Simple". or "Block", "Pattern" or something like that. Anything but "Design" and "Edit" for me. WDYT |
|
@youknowriad something I would like to add here is that I think we are missing a few fundamental pieces in the "contentOnly" editing mode which impacts all of these simplified editing modes. Regardless whether you are in this mode here, or in pattern overrides, or plain content only locking, the fact that you cannot add additional list items to a list (#52018) for example creates a lot of friction that I would love us to address before we roll this out more and more prominently |
|
@fabiankaegy That's a good point. Quote block is probably similar, it feels some blocks should have special treatment (I don't like special cases :P). We need to gather all of these things in an issue to be able to categorize them and generalize them better. |
Yeah completely agree. Now is the perfect time because we can use all of the next cycle to refine this. I just felt weary about including it in 6.7 yesterday. |
|
I updated the issue and added a todo list there #60021 Feel free to add more. |
youknowriad
added
[Type] Enhancement
|
To avoid bike shedding on the name of the modes here, I also added an item to to the issue's todo list. |
| canMove, | ||
| onMoveTo, | ||
| onlyBlock, |
There was a problem hiding this comment.
They might be unused internally, but I'm wondering whether these would be considered a public API if the slot fill is public.
There was a problem hiding this comment.
You're right. But IMO, these are bad props to start with and that are very specific to the "move to" feature that was removed.
| templateLock === 'contentOnly' || | ||
| editorMode === 'navigation' | ||
| ) { | ||
| // Sections should always be contentOnly in navigation mode. |
There was a problem hiding this comment.
I'm also wondering if the sectionClientIds logic should be mixed with the templateLock logic. Could there ever be a situation where the section root has templateLock: 'contentOnly' and then the sections logic unexpectedly applies? Not sure, maybe it's nothing to worry about 😄
|
I think this PR caused a negative impact on the "typing" performance metrics. Around 5% to 10%. This is most likely due to the increased complexity of the |
Alternative to #65027
Unifies the approach in #65027 with the one in #65055
This PR tries to implement the behavior that was explored in #65027 but instead of introducing a new rendering mode, this replaces the "select tool"'s behavior with it.
Notes
Testing instructions