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
Cross-block selection is something that is absolutely necessary because every editor has this. In any location on any computing device, it is possible to select across paragraphs. Breaking this would be a huge break in users expectations.
Because Gutenberg has chosen for separating blocks into multiple editors this isn't easily achievable. Browsers don't support multiple selections/focuses. When you are in one editable field you cannot be in another one. Editable fields include inputs, textareas and contenteditable elements. So we need to work around this in a different way.
The only way to solve this while keeping paragraphs in different blocks is by removing the contenteditable property by default from all blocks. This property needs to be re-added once edit intent is shown.
Edit intent can be the following things:
The big advantages of this are when selecting over multiple blocks the user is just selecting HTML. So selecting content works in exactly the same way as you'd expect.
There is of course behaviour that is hard to (re-)implement with this model. When you press
Other behavior includes pressing keys when you have selected HTML. When you press
I can select text over multiple blocks.
I can only select the blocks themselves.
This is browser-dependent. Firefox and Chrome provide support for Shift+arrows in non content-editable environments, but IE and Edge do not appear to (from previous experience). I have two fiddles to show this:
The second fiddle wraps the entire area inside a div with tabindex just in case there was an issue with the keyboard focus not being set.
If you try and do a ranged selection between the bottom two paragraphs (normal p tags with no content editable attribute) you will notice (at least in my testing) that IE and Edge do not change the selection. Therefore, you would have to implement this yourself.
It is possible to implement this yourself, obviously, but it can be quite complicated. The streamlined content possibilities in WordPress at the moment will help (not having different font sizes inside the content, not floating images with text etc.), but there will still be challenges. You'll also be using some APIs which can be very browser-dependent. Be aware that this may not be as simple as you would like.
Any key press would be expected to replace the current selection with the inserted key. This will need to handle capitalised keys (and potentially IMEs), so you'll essentially have to make sure you are covering all input sources (also pasting), some of which won't be known until
So in summary, don't underestimate how difficult this might be to get it right.
FYI: A really high level description of differences between browser selection models with some examples are in this blog post we wrote earlier this year
Hi @atimmer, thanks for your thoughts.
Gutenberg has cross-block selection, just not the way you're used to from plain text editors. In this case, we've chosen to go the block editor route, not the text editor route.
There are a laundry list of pros and cons to either approach, which is why the Gutenberg project started with a 3 month phase where we tried both approaches. One prototype was the "single-instance" approach, where blocks were nested inside a single contenteditable field. The other prototype took the "multi instance" approach, which we ended up going with. The prototypes we decided between are no longer online, though they are buried in this repository somewhere if you look deep enough. Though a variant of the single instance approach can still be found here.
It was very difficult to make a choice between the two, because both approaches have their merits and downsides.
In case of the multi instance approach, there were clear benefits to how much easier it would be for plugin developers to create their own elaborate blocks, without worrying about affecting the surrounding blocks. It also embraced the block-level nature of the web in a way that was conducive to a contextual toolbar: when you select a paragraph, any alignment you give it applies to the block level, i.e. the entire block. When you select an image block, we don't show a "Bold" button, because that would have no effect on an image.
The downsides are obvious too, you can't start a selection in the middle of one paragraph and end it in the middle of another. Instead you select both blocks, no matter if you selected using the keyboard or the mouse.
In the case of the single instance approach, the chief benefits were that you could do exactly that — you could start and end a selection in the middle of paragraphs, and perhaps delete that to unify two paragraphs into one. On the other hand, you could make an image bold without knowing it. More problematic for an editor that was meant to gain a slew of new layout features was that with a single large content field, it was much more easy to make selections that were not actionable — if you selected some text from a caption and went too far and selected some of the paragraph block afterwards. Or when you have columns and grids, selecting ranges across blocks would also be a nightmare. When you can act on selections spanning multiple containers, it is a lot easier to end up with tag soup and the whole thing is less resilient.
In our block editor not only is such tag soup and stray unclosed elements confined and sandboxed to a single block, but we can detect them at the block level and offer ways to solve it.
In the end we made a decision back in March to go with the multi instance approach, acknowledging all the trade-offs that came with this decision. We felt the benefits outweighed the downsides.
To your proposal in question, we did actually try a "contenteditable" hack, where as soon as you started selecting across blocks, the contenteditable property is applied to the parent container, letting you select HTML. It's possible, but it's not simple to do, and in the end the benefits of being able to delete the text between two paragraphs in order to merge them did not seem huge.
On the flipside, this hack would prevent us from creating the multi-selection actions we are exploring now, and will also prevent plugins from hooking into that using simple Gutenberg APIs (see #3434 for context). For example, right now you can select 5 images and click a toolbar button to create a gallery of those. Or if you select 10 paragraphs, you can make it into a list or a quote. You can easily imagine a plugin registering a transformation that applies to one or several block types — say you could have a plugin block that registered itself as being able to convert multiple selected images into a slideshow.
Having multiple paragraphs within a block could still be a preferred experience for some, though it also removes the ability of having block level controls at the granularity of the paragraph — movers, customization, drop-cap, etc. One of the first few versions of the plugin allowed you to keep multiple paragraphs if desired, or break out of them at will. It was considered too complicated, but we could revisit.
In the end what we're building here is not just an editor. It's an editor, and also desktop publishing for the web. Some tradeoffs have to be made in order for other benefits to present themselves. I say this only as context for how we got to where we are today.
The problem (as I see it) with the current iteration is that the per-block editing decision isn't obvious, and users who try to highlight multiple blocks in a conventional click and drag type of way are greeted with something like this:
I see 2 highlights:
I have 2 flow problems:
I have 2 confidence problems:
I think we could improve this with some clever
Commenting here because I realized I hadn't left the feedback directly yet.
Not being able to select text across blocks (with the keyboard, for example) is a problem that I run into nearly every time I write or edit a post with Gutenberg.
Because this is a regression from the current editor, should it have the Backwards Compatibility label, or is there a different/better designation?
This is currently not planned to change for 5.0 as it was part of the very conscious tradeoff decision between the different early prototypes. There was a version of Gutenberg that had a multi-paragraph text block, with usual cross paragraph text selection, but it was considered to be adding friction to other interactions that wanted to be emphasized (applying block transformations, moving, etc).
Barring a drastic design philosophy change, this won't be considered a regression but a change in direction in the editing flow. There's an idea to explore a hybrid selection model, but it comes with its own set of complexities and tradeoffs in clarity:
@getsource it'd be great to expand on what sort of problems you run into with this model. I have to say I was skeptical of it and thought we might switch back to a multi-paragraph text model, but in practice the use cases for partial selections seem to come down to just a few and it's been a case of unfamiliarity more than anything. I feel similar about how the Notion editor works.
Thanks Matias! Sure, happy to explain further. When I’m editing with the keyboard, I can’t hold down shift to select and edit text across paragraphs to copy/paste and reorder it. This makes the content proofing/editing process more difficult, as it requires entering and exiting (switching between) blocks to perform those edits. The same problems happen if I am reordering/moving more than one paragraph, whether with keyboard or mouse, and don’t want to select an entire paragraph at the beginning or the end of the selection. I don’t *think* it’s unfamiliarity with Gutenberg, if that’s what you mean — it’s that the interface seems to require multiple edits to get the same outcome. It doesn’t work the way any other text editor I’ve interacted with works. Are there a lot of other common editors that work like Gutenberg does for selection? I haven’t used Notion before, but will take a look. Is it commonly used by the WordPress userbase? I wasn’t there when the decision happened, so I can’t speak to when it happened or the reasoning behind it. I have, however, provided this feedback directly to folks previously, and having a hard time understanding how getting rid of standard expectations for editing text would not be considered a regression. For context, part of my surprise is that I was previously told that this was still planned, and my understanding was that this was the ticket to watch. Edit: Sorry! Shouldn't have replied via email.
@getsource I think it's important at this point to clarify that much of what you're referring to works, and indeed we have a number of writing flow aspects to the block editor:
I imagine you're referring to the ability start a selection in the middle of one paragraph, select into the middle of another paragraph, and then for example press Delete to merge the two into one paragraph. This is not yet doable, and I agree it would be nice to have, which is why we hope to explore #3629 (comment) for the next phase. I would recommend you read this much more indepth comment in that light.
There's a bug right now involving the switcher, but we'll absolutely get that fixed before the 5.0.
I think we could also push for browser APIs that support this. As web application become more widespread, having the possibility to have multiple carets/selection is something that is good to have. A lot of desktop code editors have this too. I wouldn't know what the right process would be to get that started though.
Thanks for the extra context, Mike. There are individual items there that can be improved and fixed (copying/pasting is one I'd like to make more improvements around). The main thing is the experience optimization is being done around blocks, which means we have to be precise and deliberate in what sort of cross-block interactions we build upon. As you mentioned, we have already built a lot of refinements there, but we surely have a lot to still cover.
Sorry, meant unfamiliarity for those of us used to "single-sheet of text" editors. Would love to hear your thoughts on Notion when you give it a go.
Yes! I think this is an area where we can push the envelope in the toolkit and I'm very much looking forward to what we can build there.
@jasmussen Right, I was not referring to things that do work. There are many things that do work, and the editor is a lot more usable with the keyboard than it used to be. Thank you!
Correct, I'm referring to cross-block selection, which is the topic of this issue. I'm glad to hear that it's still being considered for a future version, and the prototype in the GIF posted by @mtias looks like a step in the right direction.
To me this seems like a basic and expected function in a text editor (which is what Gutenberg is replacing), and it strikes me as odd to hear it's not being considered important. I absolutely agree that there's room to improve after 5.0, but personally would love for this aspect of the editor to work properly in 5.0, due to current user expectations around editing.
I'm not sure how to prove that folks commonly use text editors to edit like this in terms of being able to raise the priority. It's odd to me that I feel like I need to prove it, but since we're here, any suggestions on ways to source that feedback are welcome.
@mtias I gave Notion a go, and found the data collection and text editing experience frustrating. Since I think further feedback on it in here would be a bit off topic, happy to connect with you on it outside of the issue.
...get huge +1's from me.
Needing to state these obvious things appears like feigned ignorance. It may not be, but it certainly feels that way on the other side of this. (Not that there's "sides" but hopefully you get my meaning.)
At the risk of stating more obvious things, text editors are for quickly and easily editing text. Maybe it's just that Gutenberg isn't a text editor anymore? Even if that's true, that means willfully and intentionally abandoning literally everyone that uses WordPress for writing and editing, which feels like a mistake.
Yes, people expect a fancier, more powerful editing experience, but that shouldn't come at the cost of removing every single other thing that people are used to doing almost everywhere else where a textbox has existed since the beginning of GUI computing.
@mtias reached out to me to chat directly about this, and I wanted to relay (after his okay) some of the conclusion of that back to the ticket.
My understanding from him is that he'd be open to someone implementing and proposing a solution for this prior to 5.0, but it's not currently high enough priority to be a blocker.
One of the important aspects of this, and I agree entirely, is that a solution to this problem should not make the user experience worse for users who are intending to select entire blocks.
I don't think I know enough about the internals involved here to do so before 5.0, but would love if anyone for whom this bug is important could help out, since I think it'd help users out during the transition to Gutenberg.
Closed #13026 as a duplicate and wanted to include the video and a note from that report.