Create separate paragraph and text blocks

[aduth]

Related: #1078 (comment)
Related: #374 (comment)
Slack discussion: https://wordpress.slack.com/archives/C02QB2JS7/p1500483704729747

This pull request seeks to create two separate blocks for text behavior, for the purpose of testing and iterating improvements on each in parallel. The intention is not necessarily that both of these blocks would exist in a merged editor, reflected in lack of effort to reduce duplicate logic between the two implementations.

The text block has been reverted back to the behavior where a single Enter press creates a new paragraph within the same text block. The current behavior (single Enter press creates a line break) is preserved in a separate "Paragraph" block.

Testing instructions:

Verify that single enter and multiple enter behavior matches expectation for Text and Paragraph blocks:

• Single enter
  • Text: New paragraph in same block
  • Paragraph: Linebreak in same block
• Multiple enter
  • Text: Splits to new Text block
  • Paragraph: Splits to new Paragraph block

[nylen]

This should be editor-paragraph.

[aduth]

This should be editor-paragraph.

Done in a3562d3

[nylen]

Works well in my testing.

Should we also add the Paragraph block to the quick insert menu, and remember which one of our two text blocks the user has previously chosen? Should this be here or in a separate PR?

I plan to add stats tracking to this feature in a separate PR.

[nylen]

Today @iseulde and I discussed a number of tricky aspects of the behavior of the multi-paragraph text block. Here are a few:

• How can we resolve the inconsistency of a long section of text having multiple possible representations? (2 paragraphs could be any of text; text, text; paragraph, text; text, paragraph; or paragraph, paragraph)
• How can a user split e.g. the middle paragraph in a longer text block into a heading? How can we automatically test this and other related behaviors?
• What should happen when the user changes the alignment of one of the middle paragraphs in a text block? Are the paragraphs allowed to have different alignments, or should the block split? (Currently this state does not survive a serialization/parsing roundtrip; we need to make sure that it does.)

IMO, the significantly improved writing experience offered by the multi-paragraph block is well worth these trade-offs, and as stated in the PR description, we can continue to iterate on these fixes.

[aduth]

How can we resolve the inconsistency of a long section of text having multiple possible representations?

I think this depends on whether we care to keep both paragraph and text blocks. The expectation I had, and reiterated in the original comment, is that we care only to implement both behaviors until we decide which is "best", at which point we eliminate the other.

This could relate to your first question about remembering preference, i.e. do we care to go through the effort of implementing this? Of course, there's likely to be a bias toward whichever block is most convenient to access.

How can a user split e.g. the middle paragraph in a longer text block into a heading? How can we automatically test this and other related behaviors?

It should still be possible to split a block with two Enter presses. In other words, find point at which to break, press Enter twice, and insert Heading between.

What should happen when the user changes the alignment of one of the middle paragraphs in a text block? Are the paragraphs allowed to have different alignments, or should the block split?

We've flip-flopped a bit on this a few times already. I'm still inclined to keep alignment to be a per-block property. Currently it should be the case that applying an alignment affects the entire block. Aligning a single paragraph would need to follow similar instructions to above re: Heading block, or we could create separate behavior to automatically perform this split.

Admittedly this was always one of the less obvious flows with the multi-p-per-block approach, but I think the downside was overemphasized in context of the overall feeling and flow of the block behavior (alignment being a less common flow).

[nylen]

we care only to implement both behaviors until we decide which is "best", at which point we eliminate the other.

I would like to do this "decide which is 'best'" in an objective and organized way, by collecting usage data.

Another option would be to provide a couple of different block types that can reasonably serve as the primary text block, and allow users to pick the default they like best.

Of course, there's likely to be a bias toward whichever block is most convenient to access.

This is true. It's something we can (partially) alleviate by making it obvious there is a choice to be made between different possible "text" blocks.

do we care to go through the effort of implementing [user preferences and usage data]?

I think yes, as it's something that is quite likely to be useful in a number of other areas.

I'm still inclined to keep alignment to be a per-block property. Currently it should be the case that applying an alignment affects the entire block.

Currently, yes. If I recall correctly this and related cases were a bit broken the last time we had the multi-paragraph block.

[aduth]

Closing as superseded by #1989 and subsequent discussions. May want to revisit later.