Add initial block support for width

[stacimc]

Description

Issue #26368: This adds a dimensions block support providing a width selector with default options for 25%, 50%, 75%, and 100% width.

This is an alternative to implementing width as a selector directly on the Button block, implemented here: (#25999)

Changes

• Adds a new dimensions block support
• Provides default width options using CSS variables, allowing for preset options through theme customization
• Updates the Button component to use the new block support

Notes

• The width options are nested under dimensions settings and could be expanded to include additional block support options for height
• This is a first iteration and could be iterated on to include custom percentage widths as a text entry, or px width support similar to what's implemented in the search block
• The support for Button sets the width of the entire component -- no adjustments were made for margins in this iteration, so for example you will find that a 25% width button does not fit on the same line as a 75% width button.

How has this been tested?

Manual testing using the Button block.

Test instructions

1. Add a Buttons block to a post, with one or more Buttons.
2. Select a Button
3. You should see a Width Settings section under the Inspector Controls, with options for 25%, 50%, 75%, 100%.
4. Toggle a width option and verify that the selected button updates to the correct width. You should see an inline-style added to the block using var(--wp--preset--width--<the width you selected>).
5. Save the post and view on the frontend.
6. The same inline styling should be applied in the saved post.

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Next Steps

• Update tests

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[stacimc]

One consequence of implementing the block support with CSS variables in this way is that the style attributes end up getting applied to the outermost element of the block. This causes issues when any block support of this type* is added to the Button block, because the background-color and color styles were previously only applied to the inner anchor tag.

This causes block invalidation errors for Button, and also a bug when a user selects a custom background-color and also applies a border radius to a button. The border-radius is applied to the inner component, and the background-color to the wrapper, causing the color to exceed the lines of the border. I handled this in the Button block by stripping color props from blockProps before applying it to the wrapper.

• I tested adding the text-decoration block support (Block Support: Add text decoration block support using CSS variables #26059) and experienced the same issue

[aaronrobertshaw]

✨ Nice work @stacimc

This is working as advertised for me.

I have a few minor suggestions that I'll add as inline comments. I also have some thoughts on the stripping of color props before applying the block props to the wrapper but I'll write those up separately.

[aaronrobertshaw]

Appreciate all the hard work on this @stacimc it is coming along nicely! 🎉

After taking this for a test drive my suggestions fall under three banners:

• Trivial comments or wording tweaks
• Restructuring it a little to be consistent with the existing Typography tools
• Addressing the issue regarding stripping the color props before applying to the wrapper
  

One consequence of implementing the block support with CSS variables in this way is that the style attributes end up getting applied to the outermost element of the block.

I wonder if we would be better served by moving the application of the button styles and classes to the actual button block itself. This obviously might lead to some failed tests and needing a deprecation. I'm happy for others to weigh in on this one.

• At the moment, some of the block's props (border radius and colors) are retrieved and then applied to the inner link component.
• We could just apply these to the button component itself and use a couple of CSS styles to inherit these values as needed (overriding the default button link styles)
• Once the border radius block support PR is merged that could be opted into for the button block leading to its styles being applied to the button block itself for free.
• The button block could be updated to leverage the useColors hook and block support. This would again apply the colors to the button block.
• Using the border radius and colors block support would mean we could remove all that code applying those styles manually from the button edit and save scripts.

I've played around with the suggestion above and it worked pretty well for me. It could do with some further exploration though. I'd be happy to help if we all decide to go down that path.

[paaljoachim]

I do believe we use Width Settings percentage for only images.

Here is an example with using width for columns:

I am thinking the columns approach in relation to width might be better to use with buttons.

Btw did you create a Gutenberg issue so that we can explore to figure out the best approach. It should also have feedback from design? Thanks.

[apeatling]

I do believe we use Width Settings percentage for only images.

We also use width percentages on the search block. Also on the Jetpack form block there is a similar setup. I think it's useful for when you want to use a flexbox based arrangement to align buttons into columns using percentages.

[mcsf]

Hi, thanks for your PR. However, implementing this feature as a wide-reaching block-supports feature is premature. Instead, I strongly suggest implementing width control directly in the Buttons block — which is a clear worthwhile use case — and seeing from there if more compelling use cases arise that would then have us generalise this feature.

[apeatling]

@mcsf We've been doing a lot of work on adding this kind of support to blocks, and have been directed towards making them "block support" features, see our other PRs:

#26060
#26050
#26059

I'm wondering why width would be different in this case? I can see a number of initial block uses for this, the search block, image and gallery blocks (with expanded options), buttons, and separator blocks off the top of my head.

[mtias]

@apeatling the typography tools in the examples above have a better defined shape (the typography object). Width and other dimension controls don't yet, and it's not clear how it might be apply to different blocks, which makes it a bit trickier. We should be using the same components for sure but we can wait a bit until theme.json gives us proper structure to absorb the support. It's fine to add this one just to buttons initially as we collect more use cases.

[apeatling]

Thanks for the context! @stacimc Let's push forward with #25999 that adds it only to the buttons block, and we can leave this one on the back burner and see if it helps down the line when things have matured more.

[stacimc]

Thanks, that's very helpful. I'm going to update Issue #26368 with that context and further discussion about dimension controls can happen there.

Closing this branch in favor of #25999.