Remove: Alignment options from button nested inside buttons

[jorgefilipecosta]

Fix: #19616

When a button block is inside a buttons block, we should not render alignment options for the button block. The alignment is controlled globally for all blocks on the buttons block.

This change is complex because we can not simply remove the alignment from the button block, as for existing "button" blocks outside buttons the alignment on the block should still be supported.

If the alignment toolbar was not being rendered in a popover hiding it with CSS would be an option but given the change to popover that is not an option.
I thought of adding another filter addFilter( 'editor.BlockEdit', 'core/editor/align/with-toolbar-controls', withButtonBlockAlignRemover );. The filter would remove the added alignment toolbar for button blocks whose parent is a buttons block. But, doing that would mean we would add a dependency on WordPress hooks in our block library.

So it seems with the current API's it was not possible to hide the alignment toolbar of a button block when nested inside buttons block.
I exposed an API component AlignmentHookSettingsProvider in block editor that allows parent blocks to provide settings for the alignment hook. The current setting we support is getContextualValidAlignments that allows changing what alignments are supported based on the expected valid alignments for a given block and the props a block receives.

I prefer a change that does not involve additions to the public API, but it seems it is something not possible. I'm open to other ideas.

How has this been tested?

I added a buttons block and some "button" blocks inside.
I verified it was not possible to change the alignment of a "button" block.
I verified I could change the alignment of a button block.
I pasted this code in the block editor to create a top-level button:

<!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link">Top Level Button</a></div>
<!-- /wp:button -->

I verified I could change the aligment of that button block.

[jorgefilipecosta]

This will be properly documented if we are fine with this approach. But I would prefer to have some feedback on the general mechanism before documenting and polishing it.

[youknowriad]

Did you consider migrating existing button blocks to buttons blocks. I know we don't have a way for deprecations to change the block name but we discussed several times whether we should add it.

[jorgefilipecosta]

Did you consider migrating existing button blocks to buttons blocks. I know we don't have a way for deprecations to change the block name but we discussed several times whether we should add it.

Hi @youknowriad, In this case, it is complex, because the button block still exists and is valid but now is inside the buttons block. We would need an API not only to migrate a block to another one but also to consider block invalid if it is not nested inside a specific block.

[youknowriad]

Mmm right, let's avoid it then.

[ellatrix]

So a button block outside the buttons blocks is possible? Why not force it to be in a buttons block?

[youknowriad]

So a button block outside the buttons blocks is possible? Why not force it to be in a buttons block?

It's not possible today but some existing posts already have it.

[ZebulanStanphill]

The whole Button block is a bit odd; technically, it's not even an actual button. It's a link; it's an <a> element.

I do think there is a need for parent blocks to be capable of controlling what alignments are considered valid inside them. For example, a flexbox container can't have floated children (alignleft, alignright), so any blocks that use flexbox styling would want to disable float alignments for their immediate children. (Note that this should not propagate to children of children.)

[jorgefilipecosta]

Hi Zebulan, thank you for sharing your thoughts. I guess the button block was named because button is more user-friendly but for accessibility reasons, we should use the "a" element.

so a button block outside the buttons blocks is possible? Why not force it to be in a buttons block?

It's not possible today but some existing posts already have it.

Exactly.

Hi @youknowriad, @ellatrix any additional thoughts regarding this solution? Unfortunately, we can not use make sure the alignment we are setting will only pass one level down, as react context passes multiples levels down. I guess an alternative would be to make alignment restrictions part of InnerBlocks but that option is more complex.
Also given that we are not totally aware of the best path here would it make sense to merge an experimental solution in this case (currently it is not experimental).

[youknowriad]

I believe the context can be simplified (instead of providing supported alignments, it could just tell that it's an embedded button). that said, no strong opinions against the solution, we should just make sure it's private API.

[jorgefilipecosta]

Hi @youknowriad, unfortunately, we don't have a way to communicate from a block to a hook in block editor privately. I made the API used as experimental and followed your suggestion to simplify and juts specify if we are in an embed button context.
Would you be able to provide a final review? Thank you in advance!

[youknowriad]

I guess my thinking was that it's the responsibility of the "buttons" to create the context and provide it while the "button" would consume it. And this is possible with the private API.

It seems the fact that we use the "align support" make this impossible.

[ZebulanStanphill]

@youknowriad Maybe we should implement a hook for alignment, similar to the useColors hook, and start using that everywhere instead of the supports flag. Would that make what you want to do possible?