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.

[tofumatt]

I'm not very familiar with the code/implementation details on that block, but your comments make sense to me. @jorgefilipecosta: are there still issues preventing the comments mentioned above from being fixed?

[jorgefilipecosta]

Hi @tofumatt, I'm sorry I missed your ping. Some of the issues with the Media & Text accessibility were addressed meanwhile, but the problem of changing the aria-label of paragraphs inside it is still pending. I don't think we have a blocker to implementing this feature, it is something possible from the technical point of view.
We just need to discuss the details of how this mechanism/API looks like.
How the blocks define and document the options they accept?
How to externally query the options a block has available?
How to externally change options of a block?
How to make it easy for a parent block to change the options of its child?

[noisysocks]

Being able to customise the UI would be helpful for many, e.g. this user who wants to be able to disable the block alignment buttons.

[jorgefilipecosta]

Users need to customize placeholders of other blocks besides the paragraph as specified in #13013. Getting a solution to this issue would solve that problem.

[mcsf]

@jorgefilipecosta and @gziolo: how much overlap is there with some other issues, such as #15450 or some other? It's been over a year since the issue was opened and we may have more baggage to look at the problem broadly than before.

[gziolo]

I personally see it as one of the requirements for #15450. The question is whether we are fine with closing all smaller issues and breaking down #15450 into action items that are executed as independent PRs.

[jorgefilipecosta]

Given the title of issue #15450 I expected it was referring to sharing standard functionality across blocks, e.g., anchors, colors, etc... But not necessarily changing how a specific block behaves from the outside.
But issue #15450 also refers to things like #10791 "Limit number of columns in Columns block" and #15682 "Can't filter allowedBlocks option on blocks using InnerBlocks in edit". We can see these two issues as updating block behavior in some cases. So, I think this issue and #15450 and very related, and I agree this issue can be seen as a step of #15450.

[talldan]

#18913 also suggests that particular block functionality could be removed as part of a template. A use case is a template for a custom post type that has a heading, but the heading level shouldn't be allowed to be changed.

[gziolo]

@jorgefilipecosta, is there anything missing in the proposal shared by @youknowriad in https://make.wordpress.org/core/2020/01/23/controlling-the-block-editor/ and filed under #20588? I mean technically, alignment is not on the list of the block editor features, but we can always include it. Do you think we should still keep this issue open?

[youknowriad]

Yes let's close this in favor of #20588 and once the API is there we can open specific issues for specific keys to discuss.