Update browser colors to use material static and dynamic color themes

aguscruiz commented 3 weeks ago

Description

I've remapped the whole browser design to take advantage of Chromium's material design color scheme. The color scheme now uses the same color mapping that Chromium for the most part.

It should also work with the new tri-color themes introduced with the material refresh, and accept any custom color the user may want to set up.

Note that every single color used in the browser needs to be updated to use the new tokens, including status colors (red/green/etc.), menues, including hamburger - right click menus, etc.

This update depends on the new color tokens being brought into Nala (check with me or @fallaciousreasoning to see if it's already done).

Check with me for details

The details are all here: https://www.figma.com/design/H11ZOl6JMYbCTW4ZJXqR5V/%F0%9F%A6%81-Browser?node-id=1386-11575&t=mViVLZtbKpYd3kFP-1

Steps to reproduce

Not applicable

Actual result

Not applicable

Expected result

Reproduces how often

Easily reproduced

Brave version (brave://version info)

Not applicable

Channel information

[ ] release (stable)
[ ] beta
[X] nightly

Reproducibility

[ ] with Brave Shields disabled
[ ] with Brave Rewards disabled
[ ] in the latest version of Chrome

Miscellaneous information

No response

aguscruiz commented 5 days ago

Leaving this here as a way to brainstorm the best way to handle this.

I was thinking that perhaps the best path forward, if our objective is to use as much as Chromium's standards without losing our identity, is maybe start fresh with just their color theming.

That way we can get all their full theming capabilities, and we can add just our exclusive styles, like our vertical tabs, split view colors, etc.

I'm saying this because:

The latest version of Nala uses the material design schemes already. So if we use those set of tokens, we would have to basically mimic Chromium's styles anyways (just using our palette colors, instead of theirs). 👆 Meaning I've transformed Nala to use material primitive palettes from 0 to 100, and the material naming scheme too.
I've been moving to match Chromium styles for the browser in Nala too, so the relationship there is already close.
For upcoming features, I'll also be using material colors exclusively, so having them available would be easier.

Of course I don't know anything about how intricate our implementation is, and how difficult it would be to undo a lot of the work that's been done over the years.

But I wanted to start the conversation here

simonhong commented 4 days ago

I think we're already handling colors in upstream's way. Let me explain briefly how upstream colors are replaced with ours and how it's used from UI.

For example, below UI code fill colors for top container(toolbar and etc) and it gets colors by using kColorToolbar color id. via color provider.

void TopContainerBackground::PaintBackground(gfx::Canvas* canvas,
                                             const views::View* view,
                                             const BrowserView* browser_view) {
  bool painted = PaintThemeCustomImage(canvas, view, browser_view);
  if (!painted) {
    canvas->DrawColor(view->GetColorProvider()->GetColor(kColorToolbar));
  }
}

and upstream sets that color in AddChromeColorMixer()

  mixer[kColorToolbar] = {dark_mode ? SkColorSetRGB(0x35, 0x36, 0x3A)
                                                                : SK_ColorWHITE};

As we want to use different colors for that color, we replace it in our mixer (AddChromeLightThemeColorMixer(). (below is light theme)

mixer[kColorToolbar] = {leo::kColorPrimitiveGray1};

As a result, UI code gets our leo::kColorPrimitiveGray1 instead of upstream's one.

This is how we replace upstream color with ours.

So, I think we could handle tri-state colors also like this.

aguscruiz commented 3 days ago

Ah, ok thank you Simon!

brave / brave-browser