(Important): This is marked as important because the "success" color has changed. Things that were meant to appear as teal previously will appear a dark vibrant green. This will likely cause unexpected results.

success and successText have been updated to use a semantic green color, rather than a more subtle teal color.

We would like to reserve the usage of success and successText for semantic use cases, meaning cases that are meant to convey something positive.

We are asking teams to review their usage of the success and successText colors to ensure that they are only using it to convey positive meaning.

Some possibilities to consider:

• There were cases where success was used simply because it was teal, and teal is one of our brand colors. If that is the case, consider switching to accentSecondary, which is a new token that uses a similar teal. However, accentSecondary should be used sparingly, so consider taking it a step further and switching to something like primary.
• For buttons, you're likely bet is to switch to primary, or text (gray). accentSecondary should generally not be used on a button.
• Semantically, components like EuiHealth are never meant to convey anything other than health. Do not switch EuiHealth to use colors like accentSecondary

An example of an affirmative meaning would be this confirmation dialog. This would use the success color:

An example of a non-affirmative meaning would be the background of the "Security" badge. This would use the accentSecondary color, for the teal brand color.

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

(Important): This is marked as important because these colors are now theme aware. Not pulling them from the current them may cause bugs when switching between themes.

All usage of color palette tokens and functions should now be accessed from the EUI theme.

These were not previously part of the theme. This means that they would not change when the theme was changed, they were static. They are now part of the theme and should change when the theme is changed.

This includes any of the color tokens and functions mentioned here: https://eui.elastic.co/#/utilities/color-palettes

A simple test would be to locate your usage of these and use the provided Amsterdam/Borealis toggle to test this whether or not they change.

Vis color tokens (euiColorVis0, euiColorVis1, etc.) are now available through the EUI theme as tokens: euiTheme.colors.vis.*. Please update references to these variables to pull from the theme.

NOTE: _behindText variants of these tokens are no longer included in Borealis. For Borealis you can use the regular vis colors instead now. But for Amsterdam you should use the respective color from euiPaletteColorBlindBehindText() to ensure color parity.

The default visualization colors have been improved in Borealis to ensure the regular vis colors provide enough color contrast, which removes the need for _behindText variants.

theme.eui.euiColorVis0_behindText  -> isAmsterdam ? euiPaletteColorBlindBehindText()[0] : euiTheme.colors.vis.euiColorVis0

If you were using any of our color palette functions:

• either ensure the color palette function is called inside a React component under the EuiProvider context and is hence connected to rerender (called on rerender or connected to a state)
• otherwise if it’s used outside of the EuiProvider context you can use the new EUI_VIS_COLOR_STORE.subscribe() function to listen to changes and update usages manually

const storeId = EUI_VIS_COLOR_STORE.subscribe(
  VIS_COLOR_STORE_EVENTS.UPDATE,
  () => {
    setPalette(euiPaletteColorBlind());
  }
);

(Important): This is marked as important because the visualization colors have changed. If you were using these colors for things outside of visualizations, you will likely now have unexpected results. For example, these are commonly used to show severity levels, if you had been doing this previously, your UI will no longer appear as expected.

Data visualization colors provided by EUI should be reserved for just that, data visualization. It is important to limit their usage so that we can iterate on these colors in the future without unintentionally affecting other UI.

https://eui.elastic.co/#/utilities/color-palettes

euiColorVis0
euiColorVis1
euiColorVis2
euiColorVis3
euiColorVis4
euiColorVis5
euiColorVis6
euiColorVis7
euiColorVis8
euiColorVis9

For example: A number of places in Kibana use euiColorVis0 to style something with a teal color. Please discontinue doing this and use accentSecondary instead. If you are using vis colors like this, please change to use another color token from EUI.

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

(Important): This is marked as important because there is a high likelyhood that custom colors will no longer look correct in relation to the new Borealis color palette.

We are asking all teams to remove all hardcoded color values (i.e., any CSS color defined explicitly rather than using an EUI token) when adopting the color changes defined in this document. This could be a hex, rgb, hsl, etc.

To facilitate detecting instances where custom colors are used within the code an eslint rule as been prepared for this, it is currently set to provide warning to developers during development, this same rule can however be leverage to detect occurrences that declare custom colors at a go, by run lint targeting the directory of interest and setting the rule to raise it's report as an error like so;

yarn lint:es <path/to/directory/to/evaluate> --rule '@kbn/css/no_css_color: error'

This would return a familiar output of files that contain code that declares custom colors that needs to be attended to.

It's worth mentioning that instances where some component receives a prop that is then passed as a custom color will not be caught by this lint rule, the onus is on the developer to deter from such patterns.

Note that there are certain cases where it's totally acceptable to have custom color values. SVG source that you paste into a file, for instance.

NOTE: Kibana will soon include a lint rule for this: #200703

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

For some additional context on this change -- The EUI team hopes to iterate on color faster in the future. In order to do so, it is imperative teams strive to use EUI tokens for colors exclusively.

Hardcoded colors create issues when we iterate on the Kibana UI as a whole -- they break the system. By consistently using color tokens from the EUI library, we enable seamless updates and iterations on colors without requiring additional work from Kibana teams. With this approach, we can update a single token in EUI, and the color change will automatically apply across all of Kibana.

The EUI team is fundamentally changing the library by adding a comprehensive suite of Semantic Tokens. A semantic token is defined as such:

Semantic tokens in design systems are a type of design token that provide context and guidance on how to use them. They are named based on their purpose or meaning within the user interface (UI), rather than their appearance.

A practical example of this can be seen by looking at our shade colors. The naming of these tokens is based on their appearance -- dark. light, darkest, etc. We have deprecated many of these tokens in favor of tokens that are based on usage -- "border", "background", etc. This will be a key concept that allows us to iterate and evolve the Kibana UI over time -- cleanly and easily.

This same concept flows through to component customizations as well. In order for the EUI team to modernize UI at an atomic level (buttons, inputs, forms, layout, etc.), we will be asking teams to clean up CSS customizations to these elements as well. We realize that this is a big ask, but it is an important one. Simply put, if you are applying custom styles to our components, we are not able to update them without breaking UI.

(Important): This is marked as important because there is a high likelyhood that these color calculation functions will no longer produce a result that will look correct in relation to the new Borealis color palette.

EUI provides color utility functions. Please discontinue use of these and replace them with an EUI color token. These will be deprecated as they create unpredictable results.

shade()
tint()
shadeOrTint()
tintOrShade()
transparentize()

Currently, This doc(Elastic Internal) is the best source for choosing a new token. Scroll down to the "Applying color tokens in product" table. This table can serve as a more comprehensive reference of what colors exist in Borealis: #199715 (comment)

The intent is to use "tokens" that match your intended use case. So rather than selecting an arbitrary color that matches what you had previously, select a "token" that matches how that color is used.

So for instance -- is the color used as a border? You can switch that to something from the borderBase or borderStrong collection -- i.e., euiTheme.colors.borderBase, euiTheme.colors.subdued, etc.

If you give us some more context on the colors you're trying to replace we can help ya pick.

Many of our old tokens have been renamed, and we're asking folks to simply update their usage to use the new names.

Realistically, we could probably do one big find/replace PR, but if you're able to handle these while you're making other changes, that would be great. Otherwise, we'll probably do a follow up to catch everything in bulk afterwards.

# previous color token -> new color token
primaryText -> textPrimary
accentText -> textAccent
between this and textSuccess.
warningText -> textWarning
dangerText -> textDanger
text -> textParagraph
title -> textHeading
subduedText -> textSubdued
disabledText -> textDisabled
successText -> textSuccess

JSON tokens exported by EUI are being deprecated for usages in React components, and we need to start replacing them with semantic tokens from the EUI theme. We would appreciate it if teams could spend some time migrating away from these.

Please discontinue use of these and replace them with a token from our theme context.

ℹ If you're using the JSON tokens in a static non-react context (e.g. server-side), it is expected to keep using the JSON tokens and no update is needed.

JSON tokens are anything from:

@elastic/eui/dist/eui_theme_amsterdam_light.json
@elastic/eui/dist/eui_theme_amsterdam_dark.json
@elastic/eui/dist/eui_theme_borealis_light.json
@elastic/eui/dist/eui_theme_borealis_dark.json
import { euiThemeVars } from '@kbn/ui-theme'

For example:
https://github.com/elastic/kibana/blob/main/packages/kbn-visualization-ui-components/components/dimension_buttons/palette_indicator.tsx#L32

Before:

import { EuiIcon, EuiCode, EuiText, useEuiTheme } from '@elastic/eui';
...
height: ${euiThemeVars.euiSizeXS} / 2;

After:

import { useEuiTheme } from '@elastic/eui'
....
const { euiTheme } = useEuiTheme();
...
height: ${euiTheme.size.xs} / 2;

[!IMPORTANT]
See the tables in this comment when mapping from old tokens to new. (e.g. from euiSizeXS to size.xs)

A note for folks using the styled syntax

If you are replacing usage of euiThemeVars within the styled syntax from @emotion/styled, it may look something like this:

Before:

const LogStreamContainer = styled.div`
  display: flex;
  background-color: ${euiThemeVars.euiColorEmptyShade};
`;

After:

const LogStreamContainer = styled.div`
  display: flex;
  background-color: ${props => props.theme.euiTheme.colors.emptyShade};
`;

If you see type errors related to props.theme, you may have to set up an emotion.d.ts

Here's some guidance related to that, plucked from our Emotion FAQ:

Please note, that if you encounter type errors with the theme parameter inside of the css function, you'll need to make your Plugin is set up to use Kibana's emotion.d.ts file.

To do this, add in the aforementioned emotion.d.ts with it's path relative to location of the typings directory as the value of the include property for the tsconfig.json file that exists within your plugin.
file for your Kibana plugin for the parameter in css functions to be properly typed as EUI's theme. See the osquery plugin for an example of their tsconfig setup.

[!IMPORTANT]
Please use this table as point of reference when migrating import { euiThemeVars } from '@kbn/ui-theme' to the useEuiTheme() theme hook.

If a token might be missing or unfitting for your use case, please reach out to the EUI team in the #eui slack channel.
We'll update this list as needed.