-
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
Tracking: Border Design Tools Consistency #43247
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. |
Why have border radius on the details block and border style on images specifically been excluded? These make sense. |
There's a fairly lengthy history regarding the details block and adopting border-radius on the original PR that implemented the block (#49808). The TL;DR from memory is that adopting border-radius on some blocks can lead to a UX issue where the inline block inserter gets clipped and end users can no longer easily add blocks. The Column block is another example of this. I believe border radius was being only sparingly adopted until an overall solution can be found. Regarding border-style on images, it was decided to be removed here. As we have recently had the merged global styles data added to the block editor, I think a lot of the poor experience around default border-style behaviour can now be avoided and this decision is worth revisiting. |
Update: I have updated the table with the latest specs. |
I've updated the merged PRs list so people following along can see what's landed easier. The revisions for the issue description aren't the easiest to grok, so if you get the chance to make sure I linked the correct PRs @t-hamano, that would be appreciated 🙏 |
I've rechecked all the core blocks and added all the PRs that added border support to the merged PRs list 👍 |
As we gain more contributors helping out with these efforts (thank you!), it's become harder to find the bandwidth to keep on top of these tracking issues. For the record, that's a good problem to have 🙂 If you spin up or merge a PR adding border support, please feel free to update this issue's description and tracking table 🙏 The same offer goes for the tracking issues around other design tools e.g. spacing, typography etc. |
Hello @aaronrobertshaw I don't think the following blocks need border support. Please share you thoughts on it.
|
I disagree and would love to see the design tools on as many blocks as possible. There are always designs where all controls are handy. |
Appreciate the discussion here 👍
It would help if you could explain why each block in that list might not be a great candidate for particular block supports.
To me, this makes sense as our "default" position. If a block can support borders (or any other block support), it probably should. This improves consistency and reduces friction for users who might otherwise be confused as to why one block selection has some controls and others don't. Unfortunately, every block is its own case, so I don't see a one-size-fits-all rule we can apply. Often, it might come down to creating a PR or issue specifically for a block and discussing the pros and cons there. |
Well, For starter, The
I agree. |
is it possible to add the wrapper?
I don't think that only because they were initially used for those use cases we should limit the ability to use them otherwise. |
I appreciate your explanation @hanneslsm, I guess you are right.
If so, I believe we should adopt the strategy that @aaronrobertshaw has recommended. That would be beneficial. |
I'm not sure it would be desired and it would also cause some backwards compatibility wrinkles. I think we can make the call that the HTML block shouldn't be eligible to receive border support (or just about any block support for that matter). I'll update this issue in a moment.
The Spacer perhaps but the Separator is a decorative block. In fact, it uses bespoke border styles as it is. The Separator could be a special case though given the various block styles it has had in core across the default themes e.g. 2020 etc. As discussed, this sort of thing would be worthy of a dedicated issue should people desire the block support for that block.
It makes sense, as it's really just the standard way of approaching anything in Gutenberg. To this end, though, let's keep this issue specifically for comments related to the overall tracking issue, its progress, etc., and move anything else to a standalone issue that can be linked here. Otherwise, we risk a lot of good conversation being lost in the void. |
#66845 has been filed to add the radius support to the Details block. I understand why radius is explicitly disabled, but maybe it could be reconsidered. |
Update: Added the Query Total block to the list. |
Overview
This issue details the current state of border 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
Block Support Adoption
Note: Deprecated blocks have been omitted from this table. e.g. Comment Author Avatar, Post Comment & Text Columns.
Merged PRs
The text was updated successfully, but these errors were encountered: