Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Provide tools for selecting vs. editing blocks #17088
The goal of this ticket is to keep the benefit of the recently-shipped "clickthrough" interface, without negatively affecting the editing experience:
As is, we probably can't ship that clickthrough interface to WordPress without further refinement (see also #16888).
Instead of providing a once size fits all interface for editing and manipulating blocks, this ticket suggests splitting the two, using tools:
The idea is:
1. The Edit Tool
The Edit tool is selected by default, and the selection tool is optional.
2. The Selection Tool
Choose the selection tool from the dropdown in the editor bar, or press
As such, this Selection tool absorbs the "clickthrough" interface as it exists today.
Content in the sidebar is unchanged, you can manipulate block properties as usual on any selected block.
To exit the selection tool:
What problem does this solve?
The block editor aims to be both an editor for writing, but it increasingly offers layout options through more complex blocks. By doing both in the same interface, we end up with an often heavy UI that gets in the way.
By splitting this behavior into two tools, we can open up the editing tool to be optimized towards just that: writing and editing. And similarly, we can optimize the selection tool towards layout. This gets especially important as page designs grow in complexity.
Near term, this lets us keep the simplicity of editing text by clicking it directly, while adding a new selection tool for when you need to work with layers of nesting.
Longer term, by splitting into edit and layout tools, we can potentially focus both interactions. Ideas include:
Perhaps the focusing of the edit tool can even open up additional ways to select across blocks.
Questions & Next Steps
The minimal version of the solution outlined here boils down to creating a new tool which absorbs what we have so far referred to as the "clickthrough" interface for selecting blocks.
An open question is whether the Escape button is an appropriate keyboard shortcut to revert to the default Edit tool, given that it is also the interface for invoking navigation mode. The current working idea is that nothing needs to change here:
The obvious alternative is to find a different keyboard shortcut for selecting the Edit tool.
Your thoughts are most welcome.
I'm concerned this introduces mode errors into Gutenberg:
Users will always expect to be able to drag and drop images or select a paragraph with a click and drag then drag that elsewhere, regardless of the tool used.
Thanks for your thoughts. It's interesting that you mention vim — I encounter such errors all the time in vim, and have learned to press Ctrl + C to escape whatever trouble I got myself in at that time. So the example is great, yet ironically vim is also a very much loved productivity tool for so many. I'm not making a point here, just meandering on a delightful example.
To your point, though, I would suggest your concern is very much valid, and it has already been the driving force for many aspects of the mockup shown above, the Escape key suggestion being one example, the visual distinction suggested for hover styles applied by the two tools being another example. I will share some additional ideas in a minute, but just wanted to acknowledge the thought and note that I'll add the "needs design feedback" label to expand the review range.
The mode thing is not a new concern for this issue, it is one we deal with in virtually every app we use. The block editor and slack both have "navigation modes". In Slack, set focus in the chat, press tab, now the arrow keys navigate at the chat item level rather than scrolling the scrollbar. In the block editor, set the cursor in text, press Escape to enter navigation mode, now the arrow keys navigate at the block level, rather than moving the caret.
Key to both of those is that it's easy to "escape" those modes. In slack, press tab, or click anywhere with the cursor. In the block editor, press Enter, tab out of the editing canvas, or click anywhere with the cursor. In Figma when you have the comment tool selected, press Escape to select the default tool, or click it from the toolbar. In Docs when you are in viewing mode, you have to press a dropdown to choose another mode to exit it.
Those are a variety of different use cases for entering and exiting modes. In the best of them, entering and exiting these interfaces is virtually invisible because it doesn't get in the way. Without any prototype of the suggested interaction, it's very hard to make a proper judgement call to say with confidence that your concern is going to result in a problem. That's not to dismiss it, that is to keep the concern in mind as we do prototype it.
Which brings me to so some of the other ideas I explored as I mocked these things up:
Those three all emphasize that the selection tool would be an optional interface that you can live without. Throw in #17089 and you could go about your day without using the layout affordance.
I would suggest this is an editing action, which means it exits the selection tool and appends the image after the paragraph. Same as today, in other words.
While selecting non adjacent blocks is not part of this issue (see #16811), I agree this tool would be an obvious interface for hosting that feature. And I would expect it to work same as today. Append.
Given it's an edit action, I would expect you to exit the selection mode and start typing. As a new paragraph block below the one you selected, like the aforementioned append actions.
As noted, I did explore showing the two tools side by side, which has the benefit of being able to show a selection highlight of the tool selected. But to address the very reason for your question, it should be easier to exit this tool than enter it, and the dropdown provides valuable context to what the tool offers.
It may be worth expanding again on the goal here — there is no limit to how deeply a block can nest, and we're already seeing delighfully complex blocks that offer completely bonkers lovely layouts. This new market of premium blocks is one that is not gracefully handled by the current editor. The goal of providing the selection tool is to improve those layout affordances, and avoid the fiddly nature of what we have now, without breaking the direct manipulation of the current default interface: click text to edit it.
The idea of grouping these together is that they are global tools. Undo and redo still work if you are using the selection tool, and inserting a block I would imagine exits that tool immediately.
As suggested in the ticket, no real change here. If you never pick the selection tool, everything is like it is in
That's not covered by this issue. I would imagine if this becomes a requested feature and some concensus emerges that this is necessary, then the selection should start from outside the blocks. Simply making a drag action on a block in the selection mode would drag that block to rearrange it.
Thanks for the feedback!
Once there's a prototype I shall open a new ticket if it still makes sense for this feature request. Here's an example for reference, it would be especially useful once people start experimenting with how blocks are arranged spatially
Since this is a new mode, we can introduce other affordances into the block UI that wouldn't normally make sense, such as showing block hierarchy next to the blocks visually in the margins, padding/margin adjustments, borders, etc that would normally get in the way of the editing experience. Perhaps even the mobile UI selection design pattern of checkboxes for selection
This might also be a means of implementing other modes, such as a view only, or an editor commenting/commentary/markup mode
I've had some similar thoughts along these lines indeed. There is a great deal of potential. But I didn't want to get ahead of myself. But yes, I do hope that this opens up a way to both simplify and focus various editing experiences.
I did think of a History tool, that would surface the revision history in a sidebar, and in the editing canvas show, using
If you're referring to the history tool idea I briefly surfaced, then yes maybe. But to be clear that idea is not fully formed at all, so probably should not be considered at this point.
If you're referring to the tools, I would suggest no. I consider the code editor an entirely different editor to the block editor. They may save to the same point in the database, and you can definitely jump into the code editor to debug or fix things. But the transition to and from the code editor is not always as smooth as it would need to be, in order to be comparable, I would say.
This is just lovely.
I really love this. It might be my past experience with design software biasing my opinion, but this separation of modes makes so much sense.
absolutly! So cool!!
Thanks, @SchneiderSam, appreciat your thoughts.
I do think that the clickthrough interface solved a problem, it just solved it also when you didn't want that particular problem solved, so to speak! I do believe, and it is good to get generally positive thoughts to the same, that by splitting in these two tools we can keep the best of the clickthrough, when you want it and not when you don't!