Gutenberg: Multiple block selection

[ellatrix]

The user should be able to align/convert a selection over multiple paragraph blocks. I guess this could be solved by having one text block for multiple paragraphs, but how do you then align/convert a single paragraph? I thought it might be nice to be able to select multiple connecting paragraph blocks. Would love to see some discussion around this.

[jasmussen]

Really important discussion to have. It also ties directly into #3: what happens when you press ⌘ + A?

Important to keep two things in mind when diving into this:

1. The goal for the editor:

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or 'mystery meat' embed discovery.

1. We'll still have an HTML view somewhere, that doesn't have any blocks.

In a way it could boil right down to the two approaches that have been discussed as worthy of prototyping:

• In one, TinyMCE is the parent. ⌘ + A selects every block. What UI we show here is going to be a good question, probably worth looking at what desktop layout apps do when you select everything. This speaks to the "inspector" concept that @folletto has come up with.
• In the other prototype, TinyMCE is a child. When you pres ⌘ + A, you select all the text inside the current block. You have to go into the HTML editor if you want to copy the whole post.

[aduth]

I'd shared a demo in Slack which considers treating paragraphs individually, but also as a combined unit when selecting across multiple:

http://codepen.io/aduth/pen/jyRaOp

[jasmussen]

That works great @aduth !

[jasmussen]

One reason why selecting multiple blocks would be a boon, is when creating longer blockquotes. Say you want to excerpt a document, you might copy/paste that document, select it, then convert it to a blockquote.

[mapk]

Another take on @aduth's Codepen.

[androb]

I like that @mapk
The separate blocks feel a bit clumsy.

[aduth]

It's not illustrated well by the CodePen since the toolbar is static, but it might be problematic to allow selecting across blocks of differing types, which is why my original prototype limited it to adjacent paragraphs only.

• What block-level controls would I expect to see if I've selected across a heading, paragraphs, and list?
• What if a block's editable text is non-trivial (i.e. not just a single element like <h2> or <p>)?
  
  
  
  • For example, quotes may need separate contenteditable fields for paragraphs and the citation, or display some markup before/after the editable text.
  
  

[jasmussen]

These are the right questions to ask @aduth, they are 🔑 to get this right.

What block-level controls would I expect to see if I've selected across a heading, paragraphs, and list?

Blockquote. Incidentally this begs the question: how do you "un-blockquote" a big quote that has lots of nested content? Do blockquotes have a special button in the inline toolbar to remove that formatting?

CC: @mtias & @folletto since their input here would be interesting.

[folletto]

It's not illustrated well by the CodePen since the toolbar is static, but it might be problematic to allow selecting across blocks of differing types, which is why my original prototype limited it to adjacent paragraphs only.

To find a solution to this it might be useful to think of this in two separate parts:

1. Selection — the selection should happen on the whole system. It's just natural to be able to select everything, the "blocks" should be transparent to that, regardless of block time.
2. UI — we then need to decide: what UI should show up, and how blocks that aren't text should show their highlighted status.

I think the prototype above shows a compelling solution, we need to come up with a toolbar / inspector that allows changing in bulk multiple blocks, copy-paste, and deal with "incompatible" blocks. Initially could be as simple as "a block that is incompatible/different is left unchanged if a block change is triggered", and then we can iterate.

Blockquote. Incidentally this begs the question: how do you "un-blockquote" a big quote that has lots of nested content? Do blockquotes have a special button in the inline toolbar to remove that formatting?

Good question. I think it's a matter of how we are treating blockquotes:

• If it's a block on its own, it can revert to base text by switching to text block, and otherwise can have indentation controls on its toolbar/inspector.
• If it's treated inside a text block, then indentation can happen with a command in the toolbar, and only when indentation happens, a button to un-indent can appear.
• It could be a dropdown from "normal" to "indent-level-N": as there's no "lock" in the need of an ident level 2 to be inside an ident level 1 it's less sequential and more like choosing a header: clicking on the icon always raises +1 indent, and to revert there's the dropdown that swaps back to any level instantly.

[joyously]

Selection — the selection should happen on the whole system. It's just natural to be able to select everything, the "blocks" should be transparent to that, regardless of block time.

+10 for this. Think of how a user would enclose a selection in a container, so that they can apply styles for the group (like a background color or width or float). They select several existing blocks and choose what to enclose them? Or create the container block and move other blocks into it, singly or as a group?

[jasmussen]

Here's a pretty neat prototype by Ella for selecting across blocks in the multi-instance approach: https://codepen.io/iseulde/full/bqmwvb/

[ellatrix]

Even though it doesn't seem to be one of the initial requirements for this plugin, I think it's important to get this figured out as soon as possible. Only being able to select inside block boundaries is bit awkward and it feels limiting.

When people select across blocks in the current editor, what do they want to do with this selection? It seems that in most cases this is: copy/paste (internal or external), move with the arrows, delete and applying formatting on the selected blocks (wrap in quote, align...)

These seem to be mostly block level interactions, so might it make sense to switch to block level selection as soon as you cross the block boundary?

One other use case is deleting and merging part of two or more pieces of text at once. You'd have to delete the pieces and merge separately (3+ steps). Any other use cases that this solution doesn't solve?

[ellatrix]

Just in case you can't try the demo:

There are three editable areas (so much like text areas). You can select text inside the area normally.

As soon as you move the mouse outside this area, you're selecting blocks instead of just text. If you copy, the blocks will be copied as a whole.

[ellatrix]

Another thing we could try is having a global contenteditable and the non editable blocks outside of it (which can have smaller editable fields). This could work by having anchors in the main editor that hold the space for the non editable block. Selection in the main editor would just work as normal, and the placeholders can contain the HTML that should be copied. Another cool thing is that you can move blocks around without actually moving the node in the DOM, so iframes wouldn't refresh. One big downside is that you'd have to keep the dimensions is sync...

[androb]

Interesting idea @iseulde

@intronic how does this approach compare/complement with what you were looking at with the tinymce-single-react-ui prototype?

And with your thoughts around a block API @spocke and @Afraithe ?

[Afraithe]

Not sure our block api serves any purpose in a multi instance tinymce setting. In single tinymce, selection isn't really much of an issue and handled. I think we view blocks a bit differently here.

[jasmussen]

As an update on this, we are exploring two approaches for this in #513, of which one of them addresses some of the concerns.

[jasmussen]

In master we have a continuous text block, and you can split it into individual paragraph blocks if you like, with double enter. You can merge them right back again with backspace. This is working well. As such, I'm going to close this as addressed for now.

If during a dogfooding period we find that this is still not fully addressed, we can always reopen this!

[ellatrix]

Hm, I'm not sure what these two have in common?

[jasmussen]

Oh I'm sorry, got over eager there, and misread the use case as merging blocks.

[jasmussen]

We are in a good place with many of the blocks now, so it feels like time to revisit this!

Here's a fresh mockup:

When you drag outside the boundaries of a block, you start selecting the _blocks_. The purpose is solely to allow you to delete multiple blocks, or to move multiple blocks.

[ellatrix]

Looking good :)

[jasmussen]

This is in! Closing this ticket in favor of #950, and #951.