Gutenberg cross-block selection

[atimmer]

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.

Problem

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.

Solution approach

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:

• Clicking and releasing a block.
• Touching and releasing a block.
• Focusing a block using the keyboard.

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 SHIFT+Arrow down in a block it selects text. When you reach the end of the block you want the selection to continue to the next block. So at this point the block needs to lose it's contenteditable property and the selection re-applied. Because the browser also supports SHIFT+Arrow down on a selection on HTML we don't have to do anything else. This could also be solved by removing the contenteditable property as soon as you start selecting. The browser's default selection mechanisms would handle all the rest.

Other behavior includes pressing keys when you have selected HTML. When you press ENTER you expect the selected content to be deleted. Given that we already control a lot of the keys in Gutenberg I don't see this as a really big problem.

Expected Behavior

I can select text over multiple blocks.

Current Behavior

I can only select the blocks themselves.

Todos

• Tests
• Documentation

[ephox-mogran]

Because the browser also supports SHIFT+Arrow down on a selection on HTML we don't have to do anything else. This could also be solved by removing the contenteditable property as soon as you start selecting. The browser's default selection mechanisms would handle all the rest.

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:

https://jsfiddle.net/bzf5vy9u/1/

https://jsfiddle.net/bzf5vy9u/3/

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.

Other behavior includes pressing keys when you have selected HTML. When you press ENTER you expect the selected content to be deleted. Given that we already control a lot of the keys in Gutenberg I don't see this as a really big problem.

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 keypress instead of keydown (due to how shift changes them). You'll probably need to use the Range APIs and call deleteContents or insertNode etc, but you are once again going to hit potential differences within browsers (for complex content). Browsers can choose to represent selections around images and other non-text nodes differently. Also, some might select into a bold tag and others might not. Just be aware that to get finely polished behaviour can take a long time. As soon as Gutenberg blocks are no longer tightly controlled, the edge cases might become a lot harder to identify. Also, if you expect ranged selections to move into the Classic Text block, then you'll need to solve the problem of complex content ranges. This also goes for partial selections into tables, lists etc.

So in summary, don't underestimate how difficult this might be to get it right.

[anna-harrison]

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

[atimmer]

@ephox-mogran Thank you for the comprehensive overview. It’s good to have all this context in one place.

[jasmussen]

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.

[JJJ]

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:

• Blue background is the highlight color in WordPress
• Grey background is the highlight color in Safari

I have 2 flow problems:

• I don't know what to expect in my clipboard when I cut/copy
• I don't know what more dragging & dropping will result in

I have 2 confidence problems:

• I don't know why something that works pretty-much everywhere else does not work here
• I haven't learned anything, and am still not sure how to complete the original task

---

I think we could improve this with some clever user-select CSS rules to prevent the grey background from appearing, and that might be enough for v1, but I tend to agree with @atimmer that the penultimate goal should be, eventually, to invent a way to shift-click or drag-target multiple blocks, and have the block-editor show the intersection of block properties and all that fun stuff.

[karmatosed]

@rosswintle has this to say in #4222:

This is an/my opinion. I've searched a few pages of issues to see if it's anywhere else, but I couldn't find anything in the pages that I looked at (and there were a lot to wade through).

I've been using Gutenberg today to write a big post with lots of paragraphs. I did it partly on an iPad, and then, in frustration, switched to my desktop.

My opinion is this: having every paragraph as a separate block is confusing and creates too much pop-up user-interface/controls.

This was hard on an iPad because the combination of taps required to select some text in a different paragraph was really tricky (and it's different to selecting text in a different paragraph then it is to select text in the current paragraph), and just because there were so many controls appearing and disappearing as I moved around that it really got in the way of the writing experience.

I find myself wondering why every paragraph needs to be a block, and whether multi-paragraph blocks were tried at any point and rejected?

[aduth]

Related: #179

[aduth]

Related: #3696

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[mcsf]

As I close #179, I'm attaching this comment here in case the linked demo proves useful:

#179 (comment)

[getsource]

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?

[mtias]

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.

[getsource]

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.

[jasmussen]

@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:

• Set caret in text, use arrow keys to move across every block.
• Set caret in text, hold shift, select across blocks.
• Set caret in text. Press ⌘A once to select all text in paragraph. Press ⌘A twice to select all blocks.
• Select across blocks, then press Esc to clear selection and set caret at the start.
• Select across blocks, then ⌘X to cut or ⌘C to copy, then paste wherever.

GIF:

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.

[atimmer]

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.

[mtias]

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.

I don’t think it’s unfamiliarity with Gutenberg, if that’s what you mean

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.

As web application become more widespread, having the possibility to have multiple carets/selection is something that is good to have.

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.

[getsource]

@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.

[JJJ]

To me this seems like a basic and expected function in a text editor

...and...

It's odd to me that I feel like I need to prove it

...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.

[getsource]

@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.

[chrisvanpatten]

I wonder if this could be tied into the Unified Toolbar option, so you get cross-block selection when that's enabled? It provides a "writing style" mode and this could be added there.

[getsource]

Ooo. I like that idea @chrisvanpatten. Especially if it looks like user needs will conflict.

[designsimply]

Closed #13026 as a duplicate and wanted to include the video and a note from that report.

My biggest difficulty with Gutenberg is that selecting and manipulating text is awkward -- I see different behaviors depending on where my mouse is located when I start to drag and select text on the screen. See the attached video -- different behaviors occur when:

-My mouse is hovering over the title or a blank block.
-My mouse is hovering over the left margin.
-My mouse is inside a block with text.

[mapk]

Has this been resolved? I can click and highlight across multiple blocks, but as soon as I let up from the mouse, the Editor forces the blocks themselves to be selected, not the text. Is this issue still a problem?

[mtias]

That's the thing we wanted to see if it was worth implementing at some point — partial selections between consecutive blocks so you could merge two paragraphs, etc.

[ellatrix]

Let's close this issue. Most of what's described here has been accomplished. We should open follow up issues for additional enhancements like partial block selection and fixing remaining issues.