Option to extend blocks, remove parts of their UI, and/or update its behaviour in some cases.

[jorgefilipecosta]

Is your feature request related to a problem? Please describe.

There may be cases where we want to remove specific parts of the UI of a block in the editor. E.g., In #7414 we want to remove alignment options from blocks nested inside the media area. Alignment options don't make sense in that case.

This issue is also relevant from an Accessibility point of view.
Every paragraph block contains aria-label="Block: Paragraph" but in paragraphs nested inside another block, its rule may be more specialized e.g: the paragraph may be a tittle of something, a caption, or an author name.
Having an options API that allows changing blocks when they are nested in a specific context would allow the aria labels of the blocks to correctly refer to what they are in the specific context where they are nested.

Props to @afercia for referring the necessity of updating aria labels depending on the nesting context in #9416 (comment).

With the evolution of nesting and to customization phase similar cases may appear.

Some examples:

• It may make sense to hide the background color option from paragraphs nested inside a block that already has some background color.
• We may want to have an image block where we use the image options like resize, alignment, class, textual alternative etc... But we don't allow the user to change the image we use a predefined image set by the parent block or a plugin. E.g: an author block with a fixed user image.

Describe the solution you'd like

I'd like an option that allows removing a UI part from a specific blocks instance.

Describe alternatives you've considered

Option 1:

Currently, we can extend a block using blockEdit filter plus the slot and fill of the toolbar or the inspector. Removing fills is not an option currently. One alternative to add this feature is to allow the removal of fills. To do that we can for each fill have an id and then we can add a new filter that receives the slot and each fill with some information e.g: the id of the fill, the bock id that causes it to render etc... This filter would be able to discard a given fill.

The option I described seems like a complex option where we are mixing the filters and the slot and fill concepts. If we find an efficient&better way to allow removal of fills, it may be a powerful concept.

Option 2:

The other alternative is for each block to specify the options they support. Similar to the supports object, but supports is set per block type while options would be specific for each block instance.
Image blocks would have an option like canAlignImage, canChangeImage, canResize etc...
The paragraph could have options like canChangeBackgroundColor, canChangeAlignment, canChangeTextColor.

Blocks would set their default options, but the options may be changed on templates and by plugins using our data module. Parent blocks would also be able to change the options of the child blocks using the data module.

The options concept seems similar to the supports object, but they are complementary and should exist in parallel.
A block may support align, which adds an align attribute and some UI. But an option like canChangeAlignement may be changed to false because the block is aligned at the center by the parent block and we don't want to allow the user to change that because it would break the design. The block is still supporting align and using the align hooks but we are disabling the UI because in a specific case it does not makes sense.

The paragraph placeholder is currently set as an attribute, the placeholder is not needed to compute the output of a block, so if we add options to blocks the placeholder seems like a good fit to be an option. This would make sure we don't serialize the placeholder.

[danielbachhuber]

Related to the second option, if there was a declarative abstraction for controls, it would be much easier to filter which controls are available.

A declarative abstraction would be advantageous over a naming system because it would offer more flexibility (e.g. custom blocks could implement the same system). https://github.com/rtCamp/gutenberg-fields-middleware is an earlier attempt at such a system and could provide prior art.

[jorgefilipecosta]

Adding the accessibility label because this functionality may be very important from an accessibility standpoint.
Every paragraph block contains aria-label="Block: Paragraph" but in a paragraph nested inside another block, its rule may be more specialized e.g: they may be a title of something, a caption, or an author name.
Having an options API that allows changing blocks when they are nested in a specific context would allow the aria labels of the block to correctly refer to what they are in the specific context where they are nested.
More context in the comment #9416 (comment) by @afercia.

[afercia]

Thanks @jorgefilipecosta. Anything that helps clarify the purpose and nature of a block (in a short label) is very welcome.

[afercia]

Right now, the "Media & Text" block accessibility is less than ideal, see #9416 (comment)

In that PR it was mentioned there are higher order limitations with templates / nested blocks that, at that time, prevented to fully address the accessibility concerns. This PR is meant to solve one of those issues. However, there's no milestone set and the "Media & Text" block is still not accessible. We're now at less than a week from the scheduled Release Candidate.

Are there any plans to help this issue move on? /Cc @mtias @youknowriad @jorgefilipecosta @tofumatt

Adding the label "bug" as "Media & Text" is not accessible.