Search Block: Add border radius

[aaronrobertshaw]

Description

This PR contains changes to the search block for it to opt in to the new border radius support added in #25791.

The updates also handle adjusting the border radius when the search button is placed "inside" the search container. This allows the inner border radius to visually match the outer container without appearing to have "fat corners" as illustrated here.

How has this been tested?

Manually.

Testing Instructions.

1. Create a new post and add a Search block to it
2. In the inspector panel, drag the border radius slider and confirm the block reflects this
3. Type a border radius value into the text input and confirm that is reflected
4. Click the reset button and there should no longer be a border radius applied to the search block
5. Try setting various border radius values with different layout options selected for the search block e.g. button inside, only button etc.
6. Switch the search block to place the button "inside" and apply a border radius
7. Open dev tools and inspect the inner input and button, they should have an adjusted border radius so they visually match the radius of the outer container without having "fat corners"
   • Inner Radius = Outer Radius - Padding
   • Minimum inner radius is 1px when there is an outer radius present
   • Formula is only approximate as we don't yet have access to border width or padding settings
8. Save post and confirm border radius values are present on the frontend

Screenshots

Types of changes

New feature

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.

[aaronrobertshaw]

A CSS based alternative to this approach is available #27991

If it is acceptable, I think this PR can be closed.

[apeatling]

I think #27991 is a solid approach that I've tested and worked, and we can close this if others agree on that PR.

[oandregal]

Hey, I've taken a look at this and these are my notes for my future-self and anyone joining the thread.

The goal here is to add support for the borderRadius property in the search block. Under normal circumstances, this would be as easy as adding support for it via block.json. However, the approach in this PR does the following:

1. The block doesn't apply the style property to the root element of the block (form) but instead uses that value to calculate different inner values (padding and border) for the inner components (input, button, and intermediate wrapper).

2. The block wants to add the border for one of the elements conditionally, depending on a block attribute value. In the block toolbar this is surfaced with the options "inside"/"outside".

---

If we want to make the search block work with the current supports mechanism as it works today, this is a breakdown of what we'd need to do:

1. Add support for the border property in the block style engine (supports mechanism, theme.json).
2. Refactor the "inside"/"outside" button of the search block to set/unset the above property. As far as I could see, this ends up actually adding/removing the border, so we could do that directly instead.
3. Convert the search block to use inner blocks.
4. Make the search block & the inner blocks declare support for border individually. This approach comes with caveats, though, such as that the border needs to be set for each element individually (there will be an UI control for each element + the themes will have to target the different blocks individually in theme.json).

I've also seen the alternative using CSS Custom Properties at #27991. So far, we've avoided using them in the block markup & CSS, and I'd think we want to stay that way (see rationale at #22296).

Alternatively, this block could have a custom border control and let themes tweak it via CSS.

cc @youknowriad in case he wants to add thoughts to this.

[aaronrobertshaw]

@nosolosw I don't think I'm following what you are suggesting is the best path forward here. Could you expand on your comment further?

In case it helps, the goals of this PR include:

• Allowing the user to set a border radius easily on the search block
• Not forcing the user to have to edit multiple blocks to effectively make one change
• Not requiring the user understanding to avoid the "fat corners" problem they need to calculate a different radius value on inner blocks if the button is positioned inside
• Avoiding duplicating code to provide border radius controls, attributes etc.

Anything that ticks off that list is fine by me 🙂

I've also seen the alternative using CSS Custom Properties at #27991. So far, we've avoided using them in the block markup & CSS, and I'd think we want to stay that way (see rationale at #22296).

Are CSS variables off limits only for block supports and global styles? In other words, could a custom border radius control and attribute for the search block still leverage a CSS variable? It's a pretty clean approach in #27991 not involving heavy changes to the block's code.

Alternatively, this block could have a custom border control and let themes tweak it via CSS.

Initially this began with (#25553) an ad-hoc border radius control and attribute added to the Search block used the same way as this PR uses the border radius support value.

[oandregal]

👋 It looks like this block could certainly benefit from using ad-hoc UI controls. I'm not sure how to replicate that user experienc with the existing block supports mechanism. I've created #28518 so other people can chime in and offer a perspective on how blocks with ad-hoc controls work with patterns and global styles ― so this can be unblocked.

[aaronrobertshaw]

The next iteration of the block supports mechanism #28913 is beginning. This PR would benefit greatly from the ability to target which inner elements get the block support style applied to them. As such, I plan to revisit this PR whenever that progresses.

[aaronrobertshaw]

Closing in favour of #30227 which utilises the skip serialization feature. It was made as a separate PR to allow for easier comparison with this PR.