-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to extend blocks, remove parts of their UI, and/or update its behaviour in some cases. #7931
Comments
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. |
Adding the accessibility label because this functionality may be very important from an accessibility standpoint. |
Thanks @jorgefilipecosta. Anything that helps clarify the purpose and nature of a block (in a short label) is very welcome. |
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. |
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? |
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. |
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. |
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. |
@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. |
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. |
#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. |
@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? |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: