Description
Overview
This issue will outline and track efforts toward increasing consistency across all our blocks and their design tools.
Goal
- To ensure as few gaps in design tools and block supports across blocks as possible.
- For any omission of support to be a deliberate and documented choice.
Opportunities to Improve Consistency
- Adopt all block supports for all blocks (with exceptions where a deliberate choice is made and the reason why is documented)
- Move all related controls within relevant panels e.g. width or height controls moved into the Dimensions panel.
- Display the same controls by default for each block support or for each related set of blocks e.g. image-related blocks.
- Ensure all non-block-support, bespoke controls use the same components and styling
- Leverage feature level selectors or the elements API to ensure functionality across theme.json, global styles, and individual blocks.
General Approach
An initial audit of blocks vs block supports/design tools has already been conducted to assist in identifying gaps in our support. This current state of our design tools will be outlined per block support in sub-issues tracking them.
Phase 1 - Adopting all supports, for all blocks
This involves creating a suite of PRs to opt into any missing supports for all blocks.
As with most things, there will be edge cases adopting various supports that might slow down the process. Given the time remaining before the 6.1 code freeze, we'll need to be fairly pragmatic here to ensure we get the design tools added in time. We can refine the UX and smooth out some edge cases as "bug fixes" after the initial beta is cut.
Low hanging fruit in this phase will be any support that can simply be opted into and works out of the box. Essentially, supports where the resulting styles can be applied to the block's wrapper. Anything that involves skipping serialization of block support styles will likely take longer to ensure compatibility with theme.json and global styles.
An approach to addressing a missing block support might be:
- Identify a gap you'd like to fill via the individual block support tracking issues (linked in section below)
- Search GitHub for existing PRs that might expedite or inform your efforts.
- Terminology used in this area is often extremely varied so you might need to get creative with your searches.
- Create PR to adopt missing support (updating block.json, edit.js/index.php etc if skipping serialization).
- Double check similar or related blocks and make the default controls exposed by the block support match.
- Update the block support's tracking issue, linking the PR within the block supports table
- Ping for review
Phase 2 - Consistent Default Controls
Once we have all blocks adopting all block supports that are viable for them, we'll need to make which controls are shown by default as consistent as possible.
This might involve updating each block support to define a set of default controls. Once that is available we can remove default control specification from individual block.json files unless there is a glaring need for a given block to override things. In such a case, that should be discussed in its own dedicated issue/PR.
Alternatively, we might wish to display different sets of default controls for related groups of blocks. The difficulty here is that some blocks might span multiple "block groups" leading to some of the inconsistencies we are trying to avoid.
Phase 3 - Stabilization, Follow-ups, and Documentation
By now, the vast majority of gaps should be filled, and we can revisit any blockers that prevented block support adoption, refine edge cases, refactor blocks etc.
Given the widespread adoption of supports, now is also the time to stabilize the block support APIs.
Now might also be the time to pursue new block supports that may replace ad hoc or bespoke controls. For example, several blocks have width, height, or size-related controls.
In addition to the follow-ups, we should have a clearer view of how many exceptions there are to the "all supports, all blocks" goal and their reasons. This will help inform us of how best to document these exceptions to reduce the occurrence of users feeling that something is "missing".
