-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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: Color Design Tools Consistency #43245
Comments
An overall update on progress towards design tools consistency has been added to the primary tracking issue, including our goals for WordPress 6.1. |
Update: I have added the Footnotes and Details blocks to the list. |
List item blocks have had color added via #59892 |
Update: I have updated the table with the latest specs. At the same time, I also added |
Thanks for updating the issue @t-hamano 👍 I've added links for PRs that merged adding block supports over on the border tracking issue. Given there are so many revisions on this issue description it might help if you could add links to the merged PRs given your knowledge of what needing updating.
Also, the heading and button columns aren't using the right emoji. That one states the block has explicitly opts out of the support. Not that the block is ineligible. The typography tracking issue uses 🚫 to denote when a block won't be given a particular support. It also includes a section to explain those decisions. I didn't spot any explicit opt-outs of those element colors, given they are opt-in by default, so I've switched the ❌ to 🚫 for the heading and button support columns and added a quick explanatory note. Let me know if I've missed something. |
Overview
This issue details the current state of color block support or design tool adoption across all blocks and tasks required to fill any gaps. Overall design tool consistency efforts are being tracked via the parent issue: #43241.
Legend
Known Issues
Recently the Color gradient settings dropdown was refactored. Part of this update made controls show by default unless explicitly flagged as optional.
This goes against the way all other block support controls work, isn't documented as such, and is counter to the design goal for reducing all unnecessary clutter and controls from the sidebar. It does however assist consistency. This should be removed so the controls show by default as instructed via the block.json file. We can update blocks to make the default controls consistent and will be done in Phase 2 as outlined in #43241.
When we address potentially defining a consistent set of default controls per block support, the code linked wouldn't be required as it would be handled elsewhere.
Block Support Adoption
Note: Deprecated blocks have been omitted from this table. e.g. Comment Author Avatar, Post Comment & Text Columns.
Merged PRs
The following list details all the PRs merged as part of this effort to increase color support.
PRs with pending questions, discussions, or concerns
Decisions
Possible Follow-Ups
The text was updated successfully, but these errors were encountered: