Add Block: Continuous Text

[jasmussen]

Per discussion in #409 (comment), let's try two block approaches at the same time:

• Different paragraphs are separate text blocks.
• Contiguous paragraphs are part of the same text block.

In both cases a double (or single) enter would show the block-insert menu to the left. Depending on what you do next we would break out from the current text block or continue.

Block:

Inserter:

Inserter at the end:

Inserter between content:

Invoking the inserter between paragraphs in a continuous text block is difficult, as @youknowriad puts it:

It's just a hard task because we're mainly considering the Editable component (the TinyMCE wrapper) as a black box while this block means we'll need to figure when and how to get the inserter at the right place inside this component.

However this issue is likely going to come up again in context of other blocks, like the freeform and/or TinyMCE block,

Related:

• Block API: Block splitting, insert after #375
• Default Editable enter behavior to newline #374
• Make Core TinyMCE Block Type #365
• Idea: Smart Text Block #349

[youknowriad]

This block basically means we'll introduce some bits for the single instance prototype inside this block. We'll have to:

• Infer the sub-blocks from the block's content
• Attach controls "moving, switching and block/inline controls" to the currently focused block. These controls should have a similar UI to the higher level blocks but their behaviour is different, they apply the changes to the block content directly.
• We need a way to "disable" the block outer controls for this specific block.
• A good knowledge of TinyMCE is required to build this block.

This is also probably the same thing as the FreeForm block.

[jasmussen]

Infer the sub-blocks from the block's content

What if the block looked like this, when selected?

There would still be a challenge with putting the inserter in there, and deciding whether or not to split based on your choice here:

... but it would solve the problem of having sub-block switcher/mover headaches, wouldn't it?

[youknowriad]

but it would solve the problem of having sub-block switcher/mover headaches, wouldn't it?

Yes, if we stick to these mockups, it'd be easier to just add the inserter. My question regarding the inserter is whether all the blocks inserted via the inserter split the current block? Are there two types of blocks, text blocks that are included inside the current block and other blocks that splits the current block?

[jasmussen]

Are there two types of blocks, text blocks that are included inside the current block and other blocks that splits the current block?

This would be dependent on which blocks we decided were inside this block. As a first pass, it might be worth trying to keep it a "multiple paragraphs only block", and so anything that isn't a paragraph (or text) should split the block.

But if we find that it's a good experience for text, me might consider including headings and lists and quotes inside this block as well. In that case embeds, images, galleries, hero images, perhaps a separate pullquote block, and any future blocks would split it.

[youknowriad]

But if we find that it's a good experience for text, me might consider including headings and lists and quotes inside this block as well.

Do you expect the controls toolbar to change depending on the block we're currently focusing inside the continuous Text block? Which could mean we'll have to infer the focused block from the current selection (some of the points mentioned here

[jasmussen]

Do you expect the controls toolbar to change depending on the block we're currently focusing inside the continuous Text block?

Depends on what's easiest, and works well. We might find that we need to always show all the buttons available to you. Or we might find that it would be nice to show only contextual buttons. It also depends on where the split is made. We might decide to have permanent list and quote making buttons, for example:

That being said, it does seem like it would be nice to be able to infer the element the caret is focused on. For example if list becomes part of this block, it would be nice to be able to show the indent and unindent buttons only when the caret is in a list.

[nylen]

Different paragraphs are separate text blocks.

Pros: Most of the things we are trying to achieve in this issue (lists, quotes, inserting other blocks in the middle of a text flow) become a natural consequence of the implementation of blocks. We don't have to consider nested blocks or sub-blocks.

Cons: Under our current implementation, we break everything in #179.

Contiguous paragraphs are part of the same text block.

Pros: Under our current implementation, we get a much nicer writing experience.

Cons:

In the comments here we have some challenging design issues around surfacing the controls we need. There will be a lot of technical challenges as well - even the simple cases around block splitting are proving quite complicated (see #409, #453, #480 for a couple of examples).

We already have to consider nested blocks or "sub-blocks", and it's difficult to come up with a concept of how these should work that can be standardized across multiple block types. To me this points towards a fundamentally flawed approach.

[nylen]

Different paragraphs are separate text blocks.

Another con here: later down the road, a layout-level text widget block should be multiple paragraphs (#409 (comment)).

[jasmussen]

I see this block working very excellently in master now! So I'm closing as fixed 🎉

If I missed any edgecases that we still need to address, feel free to reopen.