Search block : Match behaviour of global styling for border and color with local styling (inspector controls) to remove inconsistency

[dpmehta]

What?

Closes #42339

This PR ensures that Global Styles for border and color properties are correctly mapped to the Search block's internal sub-elements (input and button) instead of the outer container.

Why?

The Search block uses __experimentalSkipSerialization to handle its complex layout. However, this caused Global Styles (applied via the Styles panel) to target the root block container by default. This created a discrepancy with local Inspector Controls, which target the input and button. Users expected global styling to match the visual outcome of local styling.

Furthermore, we identified a specificity conflict where hardcoded CSS in a theme's theme.json (like Twenty Twenty-Five) could override these Global Styles because both are wrapped in :root :where() and the theme's custom CSS was winning via cascade order.

How?

1. Updated packages/block-library/src/search/block.json to add explicit selectors mapping for border and color.
2. The border selector now targets specific internal elements (.wp-block-search__content, .wp-block-search__input, and .wp-block-search__button) depending on the block configuration.
3. The color selector was updated to target the .wp-block-search__button ensuring that global background and text color settings apply to the button as they do in local settings.
4. Specificity was increased by explicitly including the .wp-block-search class in these selectors.

Screenshots or screencast

Before ( Border issue )

After ( Border issue )

Before ( Color issue )

After ( Color issue )

Below testing is done

• Tested all four button position modes (button outside, inside, no button, icon-only) with both global and local styles to confirm they match.

• Checked that resetting global styles properly clears the border/color from those inner elements.

• Verified there are no specificity conflicts where global selectors now override local ones unexpectedly (since these selectors are quite specific).

Testing Instructions

1. Open the Site Editor and navigate to Styles > Blocks > Search.
2. Set a global border (e.g., 5px solid red).
3. Add a Search block to a post and verify the border applies to the input/button area, matching the behavior of local block settings.
4. Set a global Background and Text color for the Search block.
5. Verify that the button colors update to match these global settings.
6. Verify that these changes do not break existing Search block layouts (e.g., button inside/outside/no button).

Use of AI Tools

Used AI assistance (Gemini 3.1 Pro) for code analysis, specificity debugging, and drafting PR text. All logic changes were manually reviewed and validated in a local environment.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dpmehta <mehtadev@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: vk17-starlord <vineet2003@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @dpmehta! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[mikachan]

Thanks for working on this 🙌

I've tested this with a couple of themes, and it tests as expected with the default Search block:

With Twenty Twenty-Three:

trunk	This PR

With Ollie (theme overrides the input border):

trunk	This PR

However, it doesn't look like this PR addresses the issue described in #62715, as the styles are not applied to the input in the "No button" setting:

Should this PR also apply these styles to the input?

[dpmehta]

@mikachan Thanks for your valuable feedback !  🙌 , I have again gone through #62715 and realised you are absolutely correct this PR does not resolve the issue mentioned in #62715 so i removed it from PR description.

[mikachan]

Thanks @dpmehta! I can confirm that this PR fixes #42339. I think we can bring this in, and work on a fix for #62715 separately.

[dpmehta]

Thank you so much @mikachan for confirmation , i just wanted to ask how can i merge this PR because currently it is showing merging is blocked though changes are approved. It would be great if you can help me out with this.

[mikachan]

I've merged it for you! I think the task that updates the Props comment was getting stuck, but I think it's already up to date, so it doesn't matter 😄

[dpmehta]

Thanks a lot ! 😄 @mikachan for guidance and help !