Surface alignment toolbar as block control

[aduth]

This pull request effectively reverts behavior introduced in #533 . It serves as a first step toward considering text blocks as individual paragraphs.

Implementation notes:

These changes identified a few pain points:

• Related to Standardize on children value as array (step 1) #689, treating the text block's content as a single tree blob has the disadvantage of needing to map children when serializing the block. I see this being resolved by either (a) enforcing single paragraph per text block or (b) parsing the text block's content as an array of paragraphs. In both cases we'll need significant refactoring for existing transforms (ideally for the better, not considering paragraph children prop access directly).
• Related to Implement front-end styling for blocks #963 and concerns over duplicating attributes beginning from Remove and prevent DOM access in block attributes matchers #624, block alignment is another case where we'll want to consider patterns for eliminating duplication between serialized attributes and the markup itself. I'm very tempted to use data- attributes for this (both in styling and sourcing attributes), but did not include this as part of the changes here because this seems better addressed by a formal styling proposal or attributes extraction enhancements (Block parsing and serialization/deserialization #391).

In changes, alignment controls were removed from the list block. I'm not really certain I understand the purpose of list alignment, but could restore the behavior if it's considered desirable.

Testing instructions:

Ensure tests pass:

npm test

Verify that alignment behavior continues to work without regression, except that it applies to an entire block now. Serializing should encode the alignment attribute in block comments, and should be preserved when loading an existing post.

[youknowriad]

we probably should make controls optional and avoid including this if no controls are provided

[aduth]

Technically it is optional, and <Toolbar /> will not render itself when omitted:

https://github.com/WordPress/gutenberg/blob/97ee1a3/components/toolbar/index.js#L13-L15

Example: Included Text and Quote block changes render <BlockControls /> without controls prop.

[youknowriad]

I was thinking about the focus check, I guess we could avoid it by hiding the controls using CSS instead of removing them completely from the DOM.

[aduth]

I've grown more okay with it. Seems reasonable to expect that the render logic should be responsible for deciding if controls should be shown depending on whether the block currently has focus.

[youknowriad]

LGTM 👍

I have some notes that could be resolved separately though.

• Should we keep the alignments when splitting a text block?
• Should we keep the alignments when transforming blocks (text 2 quote, quote 2 text)

[youknowriad]

Oh I just noticed the alignment is not working on quotes (working only on the cite)

[aduth]

Oh I just noticed the alignment is not working on quotes (working only on the cite)

Good catch. I had styles on the block's Editables reversed (intended for text, not cite). Fixed in 17c066b.

[ellatrix]

Works great.