Configurable top header colors

[evamillan]

Description

Adds two new configs branding.colors.headerBackgroundColor and branding.colors.headerLinkColor in the yaml file to
make the top header background and link colors configurable.
Valid values are HEX and RGB color codes.

Issues Resolved

#1368

Check List

• New functionality includes testing.
  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
    • yarn test:ftr
• New functionality has been documented.
• Commits are signed per the DCO using --signoff

[kgcreative]

Hey @evamillan - Thanks for putting this together!

Have you considered being able to independently set bottom border, as well as background color? (I noticed in the code base you are setting the bottom border to equal the branding.colors.headerBackgroundColor)

Additionally, are there hooks for both Dark Mode AND Light mode themes? If users are providing two versions of the logo, they may want to provide two different header background colors.

@tmarkley - I think the behavior today is that the header is the same color regardless of dark/light mode. This something we should revisit if we're adding themeability to the header, and if that's the case, do we need to revisit the custom branding data structure?

cc: @opensearch-project/opensearch-ux

[evamillan]

@kgcreative I didn't take the dark/light mode themes into account because the header is currently hardcoded as "dark", but I can change that and add another config setting for the bottom border as well.

[kgcreative]

@evamillan That would make this much more future proof. If those configs are blank we can keep the behavior as-is, but if there is light and dark theme definitions, then we can take those into account, particularly if there is dark + light mode logos defined as well.

[kavilla]

Thanks for opening @evamillan!

Temporary blocking to ensure stability for 2.0.0-rc1

[evamillan]

I updated the PR to add configs for the default and dark modes and another one to set the border color.

2.x branch created

[ashwin-pc]

@evamillan Sorry for taking so long to get back to your PR. I had a few questions and concerns about the implementation:

1. If none of the config parameters are set for the header, it breaks the way the header looks today.
   

2. I am not sure this is the best way to customize the header colors. The header colors come from eui variables $euiHeaderBackgroundColor & $euiHeaderDarkBackgroundColor which are directly set on the eui header component. If we want to customize these colors, we should be overriding these variables as opposed to explicitly setting the value for the header. They are set in _header.scss in EUI.

3. The way branding is setup today is not ideal for theming which is similar to what this PR aims to do. There is an open issue to reduce code duplication for branding [Cleanup] Reduce duplication in code for Initial Custom Branding #895. If we decide to approach branding the header with the current approach, we should resolve that first so that we dont add technical debt to the repo.

I think this feature might need a little more thought/design before implementation. One such solution could be an scss overrides file that is imported before any of the eui styles. This will simplify a lot of the customization. I doubt that the header colors will be the only colors that someone will want to customize.

@kgcreative The dark and light headers are actually not the same. The dark mode header is slightly darker than the light mode one. And i do think we need to revisit the branding data structure. I also think we should separate theming from branding.

[evamillan]

Thanks for your comments, @ashwin-pc. If the idea is to reduce the branding code then this approach is probably not the best one.

Regarding the possible solution of an scss overrides file, I've made a small test and noticed the styles are loaded across several packages, with most of them coming from the osd-ui-shared-deps theme files. These are cached and only built with the bootstrap script. Would it make sense to change that and compile them at runtime like the osd-optimizer does?

[kavilla]

@joshuarrrr, @kgcreative could you comment on this with the re-design?

Also, #1368 I believe @ashwin-pc wanted to comment on the design as well.

[ashwin-pc]

@evamillan Yeah I think you make a good point. Let's have that conversation in #1368?

[ashwin-pc]

Closing this PR since this issue #1368 will require more work that what is covered in this PR.