Plan for removing euiColorGhost and euiColorInk

[ryankeairns]

With the transition to Emotion complete, do we have a plan for fully deprecating euiColorInk and euiColorGhost from EUI?
Further, if not already done, guidelines should be provided for consumers of EUI on removing these variables and, if applicable, use Emotion theming at a UI level.

[JasonStoltz]

Just dropping in here to +1

[cee-chen]

Unless there's a very compelling reason to (e.g. the new theme, etc) I think my vote at this point would be to just leave those 2 tokens alone and not remove them. My two reasons for saying this:

• It doesn't feel worth the time/effort spent to hunt down existing usages in both our own codebase and Kibana/Cloud and convert/remove said usages (vs. spending time elsewhere)
• From my recent work in implementing high contrast modes in EUI, ghost and ink actually came in use once or twice there, particularly when working with Windows' high contrast themes which forces specific colors and tends to be very white/black

The above are not super strongly held opinions and I'd be open being argued against this vote.

[ryankeairns]

Maybe we take a half step, don't change any code, but add this topic to the color guidelines:

1. When to use ink, ghost
2. When to use textInverse, and
3. When/how to use Emotion to make a section always dark, for example

[kyrspl]

Adding to what @cee-chen mentioned:
I noticed a few occasions where euiColorGhost / euiColorInk are used for background colors, rather than text. It will require some digging to understand whether other tokens would be more fit for purpose.

[ek-so]

Hey folks! As we had a recent discussion around this, I wanted to revive this topic a bit.

Problem

We used to have (and currently still have) tokens colors.ink and colors.ghost. Their purpose is essentially to preserve "white" or "black" (in quotes, because it's not pure white and black, but I'm calling them so for simplicity) across the modes. Another words, ghost remains always white, ink remains always black, regardless the mode. The problem is, that these tokens are quite generic (are applied to anything — text, background etc.), while in our new color system we tried to bind tokens to the specific use case to have more control and understanding of those. Therefore, we wanted to deprecate these old tokens and replace it with smth (to be defined, what).

To illustrate the difference between those 2 and potentially text-inverse or just text-paragraph better, here is a picture.

Usage

I looked into current use cases of those, and it seems that we use them mostly for text (see the image above). However, as it was mentioned — they are also used in high contrast mode even for borders and backgrounds.

Potential solutions

Currently I have 2 options in mind that we could use, given the purpose and usage of those 2 tokens and our new color system "philosophy":

Option 1. Leave them to be rather generic.
In this case imo we need to "go down" to a 2nd level of abstraction of our color system (aka shades) and replace colors.ghost with plain.light, and colors.ink with plain.dark, because:

• They function exactly the same way we want (don't change while switching modes)
• They belong logically to this 2nd level in our new system, and won't confuse people
• They don't add up to a list of 3rd level tokes (simply put, we remove 2 redundant definitions).

The downside to that is — well, they are too generic. And in genral, we don't want to apply generic tokens directly to the interface, because we lose control over their exact usage.

Option 2. Create respective 3rd level tokens.
This needs to be done for each category of usages then. E.g. text-ghost, background-base-ghost, border-strong-ghost etc.

Option 3. Hybrid
If the background and border are only relevant for the contrast mode, which is a quite specific use case (afaik, it is, but we'll need to check), we could map those usages directly to the plain.dark and plain.light, and only introduce 3rd level text-ghost and text-ink, because they are used for links or custom badges in product, for example.

Additional consideration: modes switch

For components that might (even potentially) include multiple elements, like bottom bar or a tooltip, I would suggest we keep using mode enforcement (e.g. bottom bar is always in a dark mode — even though the rest of the page is in light). I think we should keep this as it is, because if we start doing this inversion with tokens, we'll need to introduce a respective "inverted" token for each and every color, for example blue, green, red etc. button backgrounds etc. This doesn't seem feasible ands sensible.

[mgadewoll]

@ek-so Thanks for the detailed ideation!

🗒️ tl;dr

I think adding text-ghost and text-ink might be sensible. The use cases are generally text or icons. But those tokens have to be static colors (not changing per color mode), so they are in reality just re-mappings of plainLight and plainDark.

💭 The longer version, based on some insights from dev side:

1. In code we already have static tokens plainLight and plainDark

   • The mapped values are the same as for ghost and ink and could replace them (if anything at least in Borealis)

2. Create respective 3rd level tokens

   • I think this might not fulfill all requirements. At least not if they are connected to the color mode, they would need to be static.
     • We have use cases where it's programmatically checked if we require ghost or ink (e.g. in EuiBadge or EuiToken) depending on the background color (and some background colors might be custom). For those we can only use white/black because we don't distinguish based on color mode but on background color. Meaning that using a semantic color like text-ghost would not work if they change the color between color mode (unless it's defined with the same color value per color mode, making it the same as a static color).

3. Mode switches

   • This is generally the preferred usage, yes. But it's an approach that works well for scoped parts/components that should be locked into a color mode. It wouldn't really be useful for style specific adjustments (like states or variants like e.g. Badges that determine text color based on background color for color contrast).
   • An issue we're currently facing with this is also that we still need to support Amsterdam and adding a EuiThemeProvider will apply the default textParagraph color which for some usages (e.g. EuiToolTip) will result in a color change for Amsterdam (from pure white ghost to off-white textParagraph). If we don't mind, then this will become easier. Otherwise we'd either need to disable the default text color on the theme provider, stick with static tokens (plainLight/plainDark) or use component tokens to have separate mappings per theme.

4. High contrast mode (HCM)

   • we can override tokens for HCM specifically (CSS-in-JS usage only), we're currently doing that for ghost/ink to set them to true white/black. We're also doing that for all border colors to set them to white/black.

[ryankeairns]

I think adding text-ghost and text-ink might be sensible. The use cases are generally text or icons.

+1 ... this seems practical and including the text- prefix makes clear its purpose.

[ek-so]

Thank you both! So, it looks like we decided:

• Create text-ghost and text-ink which will be used for text and icons; use those as often as possible and sensible (meaning in all cases that are not background or border; we don't envision a lot of usages of those as bg or border, so we're not willing to introduce 3rd level tokens for those)
• Rely on plainLight and plainDark instead in all other cases, when we need colors to be static.
• Enforce dark mode for components (I'd say, we are fine with using regular text color for tooltips as well — contrast is fine; no need to make a difference with Amsterdam I think... nobody will see the difference, and we have a high contrast mode for those who might)

[ek-so]

I created a task for EUI here (to triage later, but now just to track). I also added respective tokens in Figma library.

[ek-so]

Ooofff... Now I'm sorry but I'm tagging you @ryankeairns @JoseLuisGJ @mgadewoll to read this poem 😁
Please share what you think? Ideally, we decide on the approach and replace those leftovers in Borealis while we go through usages 😊

[JoseLuisGJ]

Thanks for driving this change @ek-so I'll start changing the assigned values in Figma pointing to the new tokens at the same time when this EUI task will start in order to be in sync what we have in Figma and code.