[EuiComboBox] Matching placeholder color to other form elements

[myasonik]

Summary

Closes #4703

ComobBox placeholder color was too low to follow WCAG guidelines and didn't match our other input placeholders.

Created $euiFormControlPlaceholderText and updated forms and combobox to use the new variable.

Checklist

• Check against all themes for compatibility in both light and dark modes
• [ ] Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• [ ] Props have proper autodocs and playground toggles
• [ ] Added documentation
• [ ] Checked Code Sandbox works for the any docs examples
• [ ] Added or updated jest tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately

[myasonik]

@cchaos In #4703 you mentioned making $euiColorDarkShade a global in this PR but it seems like it already is (it's available in global_styling/variables/_colors.scss).

Let me know if there's anything else that needs to be done to it.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4744/

[cchaos]

Yeah sorry, I didn't mean that $euiColorDarkShade needed to be a global, but that we could create a new one for placeholder text. Something like $euiFormControlPlaceholderText: $euiColorDarkShade that all the inputs then used so they never get out of sync again.

[myasonik]

While looking through all the instances of $euiColorDarkShade it seemed like this one never did anything. (Directly inside of this class is EuiText which overrides the color again so this color is never used.)

[myasonik]

Open considerations:

1. I went with $euiColorPlaceholderText rather than $euiFormControlPlaceholderText because it seemed to match the variable naming pattern a little better while I was looking at _colors.scss.
2. While looking through the instances of $euiColorDarkShade, it seemed like there was a pattern of using it for disabled values, an misc "help-like" text (e.g., "no results found") inside of complex form controls (e.g., filters). I thought about making this variable more generic and using it for all of those but that seemed like an unnecessarily big change... But maybe it would be good normalization?
3. I also noticed that Amsterdam's light theme redefines $euiTextSubduedColor as $euiColorDarkShade. I think having both $euiTextSubduedColor and $euiColorPlaceholderText is fine, but I wonder about actually using $euiTextSubduedColor as the placeholder color instead of introducing a new variable?

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4744/

[cchaos]

Here's how we think about global vs component level variables.

Global
Limited to a set of hard-coded hex values for brand and shades (grayscale). The use very generic names like $euiColorPrimary and $euiColorDarkShade. They are never named after their usage. With one exception for disabled because many things can be disabled.

Component level
All component variables should be start with a global variable, as-is or used in a calculation. This then should be named very specifically with their component name like $euiFormBackgroundColor. This ensures all form-specific components are displayed the same if we have to apply the styles differently per component. But it also says, hey this is very specifically a form color, you shouldn't use it for anything else.

The idea behind my suggestion is that we have a huge list of form specific colors, sizing, etc, variables. Like that variable above

eui/src/global_styling/variables/_form.scss

Line 29 in e6fd955

$euiFormBackgroundColor: tintOrShade($euiColorLightestShade, 60%, 40%) !default;

What you are trying to achieve is a consistent color across our form placeholder text colors. We previously, were manually using a shade color to apply placeholder text color in a mixin, but that mixin wasn't being used by all form inputs.

eui/src/global_styling/mixins/_form.scss

Lines 85 to 87 in e6fd955

	@include euiPlaceholderPerBrowser {
	color: $euiColorDarkShade;
	}

So my suggestion is, if you can't use the mixin, we should ensure we never get out of sync with our placeholder text colors by creating, specifically, a form-level variable to be added to that variables/_form.scss file as:

$euiFormControlPlaceholderColor: $euiColorDarkShade !default;

---

Sorry for the verbosness, but I wanted to take this as an opportunity to document systems thinking (specifically how we've done in historically within EUI). And I think it may be helpful to others more than just this PR specifically.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4744/

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4744/

[cchaos]

The new variable is 💯 . I tested in Chrome, Safari, and Firefox. Firefox seems to have an opacity problem...

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4744/

[cchaos]

🎉 Looks great to me. Firefox is fixed now and they all have the same color. Even the dark mode text is a better color too.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4744/

[sasgrw]

Looks good on both firefox and chrome. They both have the same color for the placeholder text (#69707D) and the input field's background (#FBFCFD) with a contrast ratio of 4.9:1. I looked at https://eui.elastic.co/pr_4744/#/forms/form-controls

Nice job.

I bumped up the font to 500% to make sure I snagged the right color in a vertical letter so as not to select an anti-aliased color