Custom branding colors

[evamillan]

Is your feature request related to a problem? Please describe.

We can already customize the logos and some of the titles using the opensearch_dashboards.yml file. It would be helpful if the theme colors could be customized in a similar way.

Describe the solution you'd like

Ideally, the entire theme would be customizable, but a starting point could be to target some of the most prominent elements like the header, which would already make a big difference.

Describe alternatives you've considered

A low impact way to style those elements could be to use the styled components library. For example:

# opensearchDashboards.branding:
#   theme:
#     headerBackgroundColor:  ""

// /src/core/public/chrome/ui/header/header.tsx

const StyledHeader = styled(EuiHeader)`
  background-color: ${(props) => props.branding.theme.headerBackgroundColor};
  border-bottom-color: ${(props) => props.branding.theme.headerBackgroundColor};
`;

export function Header() {
  return (
    <>
      <header className={className} data-test-subj="headerGlobalNav">
        <div id="globalHeaderBars">
          <StyledHeader
            branding={branding}
            // ...props
          />

[ahopp]

Thanks @evamillan! Linking some associated/related issues -

Custom branding v2: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1250 TSVB Color Mapping: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1165 Custom Colors in Visualizations: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1241

[ashwin-pc]

@ahopp I think this issue talks more about theming than branding.

@evamillan I'm not the biggest fan of using styled components to override theme values. Also if we are going to implement theming, its a good opportunity to allow theming to happen at a global level that can affect not just colors, but also other style properties such as border-radius and font-family.

My initial suggestion would be to use a scss file that defines the overrides to the defaults set. But we can also do better by separating theme from the styles all together and exposing what is essentially a theme service that can load multiple themes in which the default light and dark themes are just two of them. This has the added benefit that each theme does not have to provide both light and dark versions of it.

@kgcreative What are your thoughts on this?

[joshuarrrr]

+1 to the idea of extending the existing dark/light theming to support custom themes. However, one thing to consider is whether dark vs light is still a separate concept - whether it's possible for a custom themer to add a custom theme with both dark/light modes.

[kgcreative]

My preference here is that a theme should have a dark/light subvariant. This is because these days, many people just use their OS settings, so I'd like to provide 2 options to users: 1) Theme name; 2) Dark mode (On, Off, Match System). This may mean that some themes may be dark mode only, or light mode only. I would be ok with that.

This would also give additional flexibility for say, specific color blind-friendly themes, high contrast themes, or even specific branded themes.

[andy-mitchell-capgemini]

+1 to the feature request for custom themes.