aaronrobertshaw
commented
2 years ago An overall update on progress towards design tools consistency has been added to the primary tracking issue, including our goals for WordPress 6.1.
Open aaronrobertshaw opened 2 years ago
aaronrobertshaw
commented
2 years ago An overall update on progress towards design tools consistency has been added to the primary tracking issue, including our goals for WordPress 6.1.
t-hamano
commented
1 year ago Update: I have added the Footnotes and Details blocks to the list.
markhowellsmead
commented
4 months ago Why have border radius on the details block and border style on images specifically been excluded? These make sense.
aaronrobertshaw
commented
4 months ago There's a fairly lengthy history regarding the details block and adopting border-radius on the original PR that implemented the block (https://github.com/WordPress/gutenberg/pull/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.
markhowellsmead
commented
4 months ago Regarding border-style on images, it was decided to be removed here
Perhaps @mtias can suggest whether it's appropriate to revise this: the linked comment is getting on for three years old, and there have been so many editor improvements in the mean time.
t-hamano
commented
4 months ago Update: I have updated the table with the latest specs.
aaronrobertshaw
commented
4 months ago 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 🙏
t-hamano
commented
4 months ago I've rechecked all the core blocks and added all the PRs that added border support to the merged PRs list 👍
aaronrobertshaw
commented
1 month ago 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.
cc/ @akasunil, @shail-mehta, @karthick-murugan
akasunil
commented
1 month ago Hello @aaronrobertshaw
I don't think the following blocks need border support. Please share you thoughts on it.
hanneslsm
commented
1 month ago 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.
aaronrobertshaw
commented
1 month ago Appreciate the discussion here 👍
I don't think the following blocks need border support. Please share you thoughts on it.
It would help if you could explain why each block in that list might not be a great candidate for particular block supports.
would love to see the design tools on as many blocks as possible
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.
akasunil
commented
1 month ago It would help if you could explain why each block in that list might not be a great candidate for particular block supports.
Well, For starter, The HTML block lacks the front-end wrapper element to which we apply border CSS. Spacer and Separator block are just for creating spacing, i don't see any point on applying border there. Read More and Page Break doesn't have any style support, i sense there must be reason that i'm not aware of.
every block is its own case, so I don't see a one-size-fits-all rule we can apply
I agree.
hanneslsm
commented
1 month ago The HTML block lacks the front-end wrapper element to which we apply border CSS.
is it possible to add the wrapper?
Spacer and Separator block are just for creating spacing, i don't see any point on applying border there.
I don't think that only because they were initially used for those use cases we should limit the ability to use them otherwise. For example, you could apply a border to an existing separator to stylize it (e.g. making it thicker). Or apply borders to a spacer to create a custom separator or decorative elements. Random examples i just found: a) Wireframe design - I can imagine using the spacer with a border for image placeholders b) Recreating this design. A group with background image, a spacer with a bottom thick red border with opacity, groups below with text.
akasunil
commented
1 month ago I appreciate your explanation @hanneslsm, I guess you are right.
it might come down to creating a PR or issue specifically for a block and discussing the pros and cons there.
If so, I believe we should adopt the strategy that @aaronrobertshaw has recommended. That would be beneficial.
aaronrobertshaw
commented
4 weeks ago is it possible to add the wrapper?
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.
Spacer and Separator block are just for creating spacing, i don't see any point on applying border there.
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.
If so, I believe we should adopt the strategy that @aaronrobertshaw has recommended. That would be beneficial.
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.
t-hamano
commented
2 weeks ago
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: https://github.com/WordPress/gutenberg/issues/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