Add color theme support to Search & Filter component

[jmuzina]

Done

Adds color theme support to Search & Filter component by using new color theme variables

• Color of the search and filter panel headers (it is slightly more contrasted from background now, using default text color rather than #666)
• Color of the overflow count - it now uses $colors--theme--link-default rather than $color-information which is unthemed and does not appear nicely on the dark theme
• Background color of opened search and filter panel (now supports dark theme using themed background color instead of hardcoded to light theme)
• Background color of the search prompt (now uses themed alt background color instead of hardcoded to #f7f7f7)
• Background color of the search clear button (now uses themed input background color instead of hardcoded whitesmoke/f5f5f5)
• Color of search and filter panel section bottom border (now uses low contrast border instead of mid-x-light)
• Enabled color theme switcher on search & filter examples
• Drive-bys:
  • Set chip border thickness to input border thickness
  • Adjusted the position of the chip overflow counter to align to the baseline (it was a bit too high).
  • Removes old blue background color of the aside navigation in the JAAS application layout example

Fixes WD-11868

QA

• Open all search and filter examples and verify that the changes above appear as expected in all color themes.

Check if PR is ready for release

If this PR contains Vanilla SCSS code changes, it should contain the following changes to make sure it's ready for the release:

• PR should have one of the following labels to automatically categorise it in release notes:
  • Feature 🎁, Breaking Change 💣, Bug 🐛, Documentation 📝, Maintenance 🔨.
• Vanilla version in package.json should be updated relative to the most recent release, following semver convention:
  • if CSS class names are not changed it can be bugfix relesase (x.x.X)
  • if CSS class names are changed/added/removed it should be minor version (x.X.0)
  • see the wiki for more details
• Any changes to component class names (new patterns, variants, removed or added features) should be listed on the what's new page.

Screenshots

[webteam-app]

Demo

Jenkins

demos.haus

[pastelcyborg]

• I notice there's a "+2" in-field helper on Dark and Paper themes that's not visible on Light theme. Is this possibly missing styles?
• Some crazy stuff occurs if you Tab while within the search field - a "Search" button is focused, but it's about half cut off on the right side of the input, and the "Search and filter" placeholder becomes unevenly vertically aligned
• In addition to the previous bullet, hitting Tab while focused within the default component shifts focus to the Search button, also hiding the chips pane; as it is, I don't believe a user would be able to use this component in an accessible manner due to this
• It's possible to get the search input/chips into a state where input doesn't turn into chips and will - seemingly randomly - remove field input; this is most obvious on the With Search Prompt example if you alternate between clicking the chip, typing into the input, clicking the Search for... link, and refreshing the page

I recognize most of the above aren't related to theming directly, but just wanted to capture them during this review.

[bartaz]

I recognize most of the above aren't related to theming directly, but just wanted to capture them during this review.

@pastelcyborg This is a weird component in Vanilla sense. It was originally built in React and its styling has been upstreamed to Vanilla, but there is way too much functionality to it to replicate it in full in plain JS here.

So all we did is create some static examples of different states the component can be to make sure all the styling is in place, but none of the examples is fully funcional (outside of React). So there certainly can be issues if you try to interact with the component.

If you are interested you could try similar tests in React examples and if there are any bugs report them in React components directly. At this point in Vanilla CSS we are only focusing on styling of it.

I don't know if there is a easy better way to approach such component. I guess ideally we should be able to just embed the React component, as this component has practically no use as pure HTML/CSS.

[pastelcyborg]

Good to know, thanks @bartaz. Optimally I think the first 2 of my bullets should still be fixed here, as they're related to visual presentation/theming and not any JS functionality.

[jmuzina]

• I notice there's a "+2" in-field helper on Dark and Paper themes that's not visible on Light theme. Is this possibly missing styles?

@pastelcyborg This also happens in production and seems to be fixed if you reduce page width slightly. It looks like a z-index issue where the "Search and filter" placeholder text is hiding the overflow hint behind it. You can fix it by manually setting the z-index of the p-search-and-filter__selected-count higher in dev tools.

EDIT: On second look, it appears to be intended behavior that this +2 is hidden, as it looks quite broken when overlaid on top of the "Search and filter" placeholder. I think I need to investigate the themes to make sure that it is hidden on dark and paper in this case. Or maybe it is an artifact of the example search and filter JS.

Screen.Recording.2024-06-13.at.11.44.30.AM.mov

CC @bartaz

[jmuzina]

The issue with seeing the +2 on dark and paper is because light theme background for the search input p-search-and-filter__input is completely opaque, while dark & paper have slight transparency. This causes the +2 to be visible behind the search input.

The issue comes from these variables having transparency added:

vanilla-framework/scss/_settings_colors.scss

Line 177 in 0803fee

$colors--dark-theme--background-inputs: rgba($colors--dark-theme--text-default, $input-background-opacity-amount) !default;

Results in rgba(255, 255, 255, 0.04)

vanilla-framework/scss/_settings_colors.scss

Line 225 in 0803fee

$colors--paper-theme--background-inputs: rgba($color-x-dark, $input-background-opacity-amount) !default;

Results in rgba(0, 0, 0, 0.07)

Whereas light theme inputs background does not have transparency:

vanilla-framework/scss/_settings_colors.scss

Line 118 in 0803fee

$colors--light-theme--background-inputs: adjust-color($color-x-dark, $lightness: 100% * (1 - $input-background-opacity-amount)) !default;

Results in rgb(238, 238, 238)

[jmuzina]

I've attempted to fix the chip overflow indicator problem by introducing an opaque version of the inputs background for each color theme and setting the background of p-search-and-filter__input to it. This appears to solve the issue, but please review and let me know what you think @bartaz @lyubomir-popov @pastelcyborg

As for @pastelcyborg 's second bullet point:

Some crazy stuff occurs if you Tab while within the search field - a "Search" button is focused, but it's about half cut off on the right side of the input, and the "Search and filter" placeholder becomes unevenly vertically aligned

Maybe we should make a new issue for this and solve it separately, since it isn't related to the theming.

[bartaz]

What was the +2 showing up behind the input? I woudn't expect anything to be behind it if it's covered - maybe that's something we can fix in the component itself rather than by introducing new colours?

But it is another situation when we have issues caused by transparent backgrounds. I think we need a clear direction on this. And I believe that if we address it, it should be the other way around - backgrounds should be opaque by default, and only if transparent version is needed for any reason there would be a specific transparent version and it would be clear that it is transparent (in all themes).

[jmuzina]

@bartaz

What was the +2 showing up behind the input?

It was the p-search-and-filter__selected-count from the chip overflow example. In the example, it is always in the DOM and set to visible, but covered by p-search-and-filter__input when it is visible. However this only works on light theme, as dark & paper input background colors have transparency that makes the chip overflow count visible.

backgrounds should be opaque by default, and only if transparent version is needed for any reason there would be a specific transparent version and it would be clear that it is transparent (in all themes).

I agree; I suppose we may need to adjust the values used for the inputs backgrounds on dark & paper. I wonder if there are any apps/sites that are relying on that transparency... I hope not.

[jmuzina]

@lyubomir-popov When you have some time, please look through the conversation in this PR and let me know your thoughts on best direction forward for this

[lyubomir-popov]

Color of the search and filter panel headers (it is slightly more contrasted from background now, using default text color rather than #666) - I think these should use the muted text colour
Color of the overflow count - just the normal link colour should work fine
Background color of opened search and filter panel (now supports dark theme using themed background color instead of hardcoded to light theme) - can we use the input background?
Background color of the search prompt can we use the input background?
Background color of the search clear button (now uses themed input backgroundcolor instead of hardcoded whitesmoke/f5f5f5)
themed input sounds ccorrect, same as the two above.
Color of search and filter panel section bottom border - any borders on non-interactive elements should either use the default or low-contrast border styling

As a drive-by, added the global variable $border-high-contrast and replaced all usages of $input-border-thickness solid $colors--theme--border-high-contrast with $border-high-contrast. don't we already have that at the theme level?

[jmuzina]

Need to adjust so the overflow count is on the baseline

[jmuzina]

Inline-commenting where to switch to input background color for my own sake

[jmuzina]

@bartaz I've updated this to remove the custom color from the JAAS aside navigation in the application layout example, as requested.