Skip to content

UI Components: Add theme support for FormTokenField and ComboboxControl #69638

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

Merged

Conversation

yogeshbhutkar
Copy link
Contributor

@yogeshbhutkar yogeshbhutkar commented Mar 20, 2025

What?

Part of #69646
Follow up to #69621
Related: #69593 (comment)

This PR introduces theming support for the FormTokenField and ComboboxControl components.

Why?

Previously, these components lacked dynamic theming, causing visibility issues in dark mode. This update ensures proper theme adaptation for improved readability and user experience.

How?

The corresponding SCSS files have been updated to use theming.

Testing Instructions

  1. Run storybook locally. (npm run storybook:dev)
  2. Navigate to the FormTokenField component.
  3. Change the theme and confirm that there are no visibility issues.
  4. Navigate to the ComboboxControl component, and repeat step 3.

Testing Instructions for Keyboard

Same

Screenshots

Combobox

Before After
combobox-default-before combobox-default-after
combobox-dark-before combobox-dark-after

FormTokenField

Before After
formtoken-default-before formtokenfield-default-after
formtoken-dark-before formtokenfield-dark-after

@yogeshbhutkar yogeshbhutkar marked this pull request as ready for review March 20, 2025 07:10
Copy link

github-actions bot commented Mar 20, 2025

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: yogeshbhutkar <yogeshbhutkar@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

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

@yogeshbhutkar
Copy link
Contributor Author

Hi @ciampo, following our previous discussions, here's a PR adding theming support to both FormTokenField and ComboboxControl.

@ciampo ciampo requested review from a team, Mamaduka and t-hamano March 24, 2025 15:02
@ciampo ciampo added [Type] Bug An existing feature does not function as intended [Package] Components /packages/components labels Mar 24, 2025
@@ -12,6 +12,8 @@ input.components-combobox-control__input[type="text"] {
margin: 0;
line-height: inherit;
min-height: auto;
background: inherit;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should use $components-color-background instead?

Comment on lines 39 to 42
border-color: $components-color-accent;
box-shadow: 0 0 0 0.5px $components-color-accent;
outline: 2px solid transparent;
outline-offset: -2px;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving away from shared mixins is not great (especially since we're using the input-control mixing just a few lines above) but I understand that input-style__focus() doesn't support components theme colors.

A few ideas to consider:

  • re-define the --wp-admin-theme-color CSS variable only in the scope of this specific CSS class, and re-use the mixin;
  • tweak existing mixins to support custom accent colors

Otherwise, if really need to resort to custom code, let's at least add comments:

  • explaining that this code mirrors the input-style__focus() mixin;
  • explaining the reason for the 0.5px box shadow
  • explaining that the invisible outline is for Windows High Contrast mode

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review, @ciampo.

tweak existing mixins to support custom accent colors

It made more sense to go with this approach, and I’ve implemented it in the latest commit. Thanks!

@@ -151,10 +151,10 @@
}


@mixin input-style__focus() {
border-color: var(--wp-admin-theme-color);
@mixin input-style__focus($accent-color: var(--wp-admin-theme-color)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should expose the same $accent-color argument in the input-control mixin too (in the same file) (also cc @mirka for a quick check about this idea making sense)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit conflicted, now that you bring it up. I'm looking at how these generic mixins are used in the repo, and it's mostly just the components package. Almost as if these shared styles should be internal to the components package now and deprecated from base-styles — I assume they were once used more in other packages, and we've been able to remove them as we've consolidated our component usage better.

However, I like what @yogeshbhutkar is doing here, and I think it's fine to do it in the input-control mixin too, like you suggest. I'm just not sure if that scales to "let's do it for all the base-style mixins with accent colors".

I don't have a strong preference either way, given that I want to eventually overhaul these bits.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. In a perfect world, @wordpress/component would offer a set of input components that can satisfy all usecases in Gutenberg, allowing us to move the mixing to the component package.

At the same, we need to consider whether the base-style package should exist as a lower-level (even lower that the components package) for literally any UI build in Gutenberg, even when the components from the @wordpress/components package can't be used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the great discussions!

I think it's fine to do it in the input-control mixin too.

Following this, I've updated the PR to expose the $accent-color argument in the input-control mixin and made some adjustments to the codebase.

cc: @ciampo @mirka

@yogeshbhutkar yogeshbhutkar force-pushed the enhance/theme-support-combobox branch from 84a459a to 4c9319b Compare March 31, 2025 06:16
@yogeshbhutkar yogeshbhutkar requested review from ciampo and mirka March 31, 2025 06:46
Copy link
Contributor

@ciampo ciampo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀 Thank you for the work!

@ciampo ciampo merged commit 502f4a3 into WordPress:trunk Apr 3, 2025
64 checks passed
@github-actions github-actions bot added this to the Gutenberg 20.7 milestone Apr 3, 2025
chriszarate pushed a commit to chriszarate/gutenberg that referenced this pull request Jul 1, 2025
…ntrol` (WordPress#69638)

* feat: add dark theme support for `form-token-field`

* feat: add dark theme support for `combobox-control`

* chore: add CHANGELOG

* chore: use consistent spacing

* refactor: update `input-style__focus` to support custom accents

* feat: enhance `input-control` mixin to accept custom accent colors

* chore: move `CHANGELOG` to unreleased section

---

Co-authored-by: yogeshbhutkar <yogeshbhutkar@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Components /packages/components [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants