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
Tracking: Addressing Design Tooling Consistency #43241
Comments
Update: 5 September 2022Current StatusWork towards completing Phase 1, as outlined in this PR, is still ongoing. We have several contributors from the wider WordPress community assisting in these efforts, which is greatly appreciated 🙇 If there are particular block supports you wish to ensure land in time for 6.1, please feel free to jump in and create or review relevant PRs. If you submit a PR, it would be great if you could also update the relevant block support tracking issue or comment on them (see links at bottom of this issue's description). We'd like to keep these as up-to-date as possible, so anyone can quickly identify gaps and contribute without overlapping the efforts of others. Rough guide to current Phase 1 completion:
* Not all blocks will be candidates for adopting layout support. As such, the available blocks number reflects eligibility. The figures above don't yet acknowledge any blocks we determine should not in fact opt into a particular block support. As a result, these numbers will tend to be conservative. What's planned for WordPress 6.1The current plan is to achieve as much as possible towards completing Phase 1. Given the large number of blocks and the potential for tricky edge cases, we won't be able to complete phase 1 across all block supports. As such, we'll be approaching them in general order of priority: Typography > Spacing > Layout > Color > Border Beyond 6.1WordPress 6.1 will only be the start of our efforts to achieve consistency across our design tools. The immediate goal post 6.1 will be to complete Phase 1 for all block supports. From there, we should be well positioned to complete phases 2 & 3 for WordPress 6.2. |
Update: 16 September 2022This update is a little late as I was AFK for a few days recently but here goes 🙂 Current StatusIn the lead up to the 6.1 feature freeze, we focused primarily on Typography and Spacing supports. The majority of blocks requiring typography design tools received them. There were of course several exceptions such as captioned blocks e.g. Image, Embed, Video etc. While these blocks could have benefited from typography supports, the potential in the near future for them to be refactored to use an inner standalone Caption block made it worth holding off here to avoid any backwards compatibility issues. Phase 1 is continuing however the pace here might slow in the short term as we shift focus to help iron out kinks for the 6.1 beta. Phase 1 completion so far:
* Not all blocks will be candidates for adopting layout support. As such, the available blocks number reflects eligibility. |
Quick comment to drop a link to a PR aiming to extend and stabilize our block.json selectors API. It will offer the ability to specify CSS selectors for individual styles (e.g. font size), not just features (e.g. typography). In turn, that extra flexibility might help smooth out edge cases and make adoption of block supports easier. |
It would be great with an update in regards to the upcoming WordPress 6.2. Beta 1 is 7th of February. |
Hi @paaljoachim 👋 There hasn't been much progress on further block support adoptions for this release. Most of the low-hanging fruit (especially for typography supports) has been picked. Those remaining have some trickier edge cases requiring greater control over CSS selectors to ensure we don't create a disjoint between individual blocks and theme.json/global styles (more on this in a moment). We also ran into some issues with margins being broken by the new layout supports, which became a blocker to adopting spacing supports. With any luck that will be resolved later this week. You can follow progress there on #47399. With the rapid adoption of block supports adding more and more controls to our sidebar, we've needed to switch focus a little this release to refining the sidebar. A big part of that was the sidebar tabs experiment #45005. Back to the CSS selectors mentioned earlier, I've been working on stabilizing and extending the block.json selectors API. This will provide blocks with greater control over the selectors used for each block support feature (e.g. color, typography) and subfeature (e.g. background color, font size). The combination of these efforts should help reduce the friction in adopting missing block supports. Hopefully, allowing for this issue to regain some of its lost momentum. |
A new "Post Time To Read" block has been merged with #43403. This is an experimental block, but please add it to each table if needed 🙏 |
@aaronrobertshaw would be great to update the stats. What's planned for 6.3 ? |
@t-hamano, I think it can be added once it's no longer experimental. That said, if anyone feels differently, anyone can update the tracking issues with up-to-date information.
@Marc-pi I can provide another stat update soon. Focus generally shifted away from filling design tool gaps toward higher priority issues for 6.2, and wrapping up Gutenberg Phase 2. In addition, we needed to address the crowded sidebar (#45005) and provide more flexibility in how Global Styles for different design tool features could be applied to blocks (#46496). In terms of what's planned for 6.3, we'll continue to chip away here although my understanding is that more focus will be given to laying groundwork for improved workflows, collaboration, and Gutenberg Phase 3 in general. Anyone is welcome to submit PRs adopting design tools for blocks they feel are missing them. The more contributors that can help here the better, as it will be a slow process otherwise. |
Update: 30 March 2023Current StatusThe adoption of specific design tools for individual blocks became a lower priority as the proliferation of tools in the sidebar became a usability issue. For 6.2, the organisation of the Block Inspector has been updated with the introduction of tabs within the sidebar. The initial rush of design tool adoption was anticipated to slow naturally as easier adoptions were cherry-picked. What we began to find after that was that we were facing an increasing number of blocks that had edge cases we couldn't quite resolve e.g. ensuring that the application of global styles matched the styles provided by individual block supports. It's expected that with Gutenberg 15.5, we'll have access to a stabilized and extended block selectors API. This will provide us with much greater control over the application of global styles and should unblock further design tool adoption. Over the last couple of WordPress releases, we've also had new layout supports introduced. These caused an unfortunate regression with margins which blocked several blocks from adopting more spacing supports. A fix for this is almost ready to land. While the adoption of design tools across blocks hasn't progressed rapidly in the last few months, a lot has been done to position the project for another push. Anyone with the bandwidth to submit PRs filling design tool gaps is encouraged to do so. Phase 1 completion so far:
* Not all blocks will be candidates for adopting layout support. As such, the available blocks number reflects eligibility. |
I also added Time To Read block to Tracking Issues for Individual Block Supports since the experimental Table Of Contents block was already present in the listing. |
Overview
This issue will outline and track efforts toward increasing consistency across all our blocks and their design tools.
Goal
Opportunities to Improve Consistency
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:
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".
Further Follow-ups
Tracking Issues for Individual Block Supports
The text was updated successfully, but these errors were encountered: