Alignment is handled inconsistently across blocks

[bradyvercher]

Issue Overview

The implementation of the alignment toolbar is inconsistent between blocks. Aside from not setting a good example for third-party blocks, it exhibits a few bugs, and causes unexpected behavior that's confusing for users.

Attribute Defaults

Some blocks register a default value for the align attribute, while others don't. The button, gallery, and pullquote blocks set a default value of none; latest posts uses center; and the categories block doesn't set a default, but the PHP render method forces the value to center.

For blocks that implement alignment, these are the registered defaults:

Block	Default
Audio	null
Button	'none'
Categories	null (defaults to 'center' in the PHP render method)
Cover Image	null
Embed	null
Gallery	'none'
Heading	null
Image	null
Latest Posts	'center'
Paragraph	null
Pullquote	'none'
Quote	null
Table	null
Text Columns	null
Video	null

Unaligning Blocks

When unaligning many blocks (deselecting an alignment button), a class of alignundefined is applied instead of either removing the alignment class altogether or replacing it with the registered default.

Using the button block as an example:

1. Insert a button block (the class is alignnone)
2. Align it left (the class is alignleft)
3. Unalign it (the class is alignundefined)

At this very least, I believe this happens for buttons, galleries, and pullquotes.

Aside from applying an alignundefined class, many blocks also throw validation errors when unaligning them.

1. Insert a paragraph block
2. Align it
3. Unalign it
4. Save the post
5. Refresh

This affects buttons, headings, paragraphs, pullquotes, and quotes.

Edit Wrapper Data Attribute

Most of the blocks apply a data-align attribute to the edit wrapper with the alignment value similar to this:

getEditWrapperProps( attributes ) {
    const { align } = attributes;
    if ( 'left' === align || 'right' === align || 'wide' === align || 'full' === align ) {
        return { 'data-align': align };
    }
}

Center aligning never seems to change the value of the data attribute for the edit wrapper despite it being a valid value for most blocks. It seems like this should be applied consistently in case themes treat aligncenter different than alignnone or an empty value.

Toolbar onChange Callback

Some blocks define a class method (requires binding in the constructor), others define a local function, and some use an inline arrow function. They all do the same thing. I'd like to see this be more consistent across blocks.

Considering how simple it is, I think using an inline arrow function would make things more concise and easier to read:

<BlockAlignmentToolbar
    value={ align }
    onChange={ value => setAttributes({ align: value }) }
/>

Miscellaneous Alignment Issues

Audio Block

Aligning an audio block left or right, then deselecting the block makes it almost invisible in Chrome.

Button Block

Full and wide alignments aren't applied to the edit wrapper in getEditWrapperProps():

getEditWrapperProps( attributes ) {
	const { align, clear } = attributes;
	const props = {};

	if ( 'left' === align || 'right' === align || 'center' === align ) {
		props[ 'data-align' ] = align;
	}

	if ( clear ) {
		props[ 'data-clear' ] = 'true';
	}

	return props;
}

Categories

The PHP render method forces an aligncenter class to be applied even when an alignment button isn't selected in the toolbar.

Cover Images

Alignment classes aren't applied in the save() method at all.

Latest Posts

Unaligning the block doesn't work; aligncenter is reapplied when saving. If this is how defaults are handled, then it shouldn't be possible to deselect the alignment button in the UI.

Paragraph Block

The attribute name for the block-level alignment is width, which doesn't seem to make much sense. Naming this something like blockAlign would be a little more clear, especially since the width attribute is a number in some other blocks.

Or the inline alignment attribute could be named textAlign since that's the property used when applying the inline style.

Text Columns

Uses the width attribute for alignment.

[danielbachhuber]

Thanks for the detailed report, @bradyvercher. This seems like it will need to be addressed with several pull requests.

[bradyvercher]

Some of the bugs in this report have already been fixed, but it still feels like the way alignment is handled was written by several different developers in different ways. I've also noticed third-party blocks have started implementing alignment incorrectly since there isn't really any consistency to the way it's handled in the core blocks.

I haven't dug into #4069, but it looked like that would solve a lot of issues and make it easier for plugin developers to support alignment in their blocks.

[jeffpaul]

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

[jeffpaul]

May be addressed by #5099

[designsimply]

Because this issue was originally filed ~6 months ago and some parts of it were outdated, I have tested each part and moved anything still valid to new issues.

Bugs

• Alignment: adding and removing alignment results in an alignundefined class instead of alignnone #7907 - unaligning results in alignundefined class.
• Alignment: categories block forces aligncenter regardless of what is selected in the toolbar #7910 - categories block forces aligncenter.
• Alignment: latest posts block reapplies aligncenter on save even if it was deselected #7911 - latest posts block reapplies aligncenter on save even if it was deselected.
• Alignment: paragraph and text columns block alignment attribute name is width #7912 - Paragraph and Text Columns block alignment attribute name is width.

Needs Decision

• Alignment: blocks using alignment should apply data-align consistently #7908 - apply data-align consistently.
• Alignment: setting alignment attributes should be consistent across blocks #7909 - make setting alignment attributes consistent.

Could not reproduce or wontfix:

• Validation errors after unaligning.
• Audio block left or right alignment becomes invisible in Chrome.
• Button block full and wide alignments aren't applied: answered at Blocks: Refactor blocks to use supports align #5099 (comment).

^{Tested using WordPress 4.9.7 and Gutenberg 3.2.0.}

Need help testing:

• Cover Image alignment classes aren't applied in the save() method at all.

Closing in favor of newer issues to make some of the issues raised more approachable and this issue (although closed) will remain as a good reference point. Also removed the Good First Issue label due to size and because some decisions were still needed.