Allow customizing navbar background with css variables.

[SebastianJL]

I use css variables as outlined here:
https://pydata-sphinx-theme.readthedocs.io/en/latest/user_guide/customizing.html#css-theme-variables

My customs.css looks like this

:root {
    --pst-color-navbar-link: 255, 255, 255;
    --pst-color-navbar-link-hover: 192, 192, 192;
    --pst-color-navbar-link-active: 203, 86, 40;
}

#navbar-main {
    background-color: #2f4858 !important;
}

i.fa-github-square:before {
    color: #ffffffff;
}

I wondered if you could add a css variable for customizing the navbar background.
It could be called --pst-color-navbar-background.

[jorisvandenbossche]

@SebastianJL Thanks for the issue report! I think that's a good idea, yes.

One thing I am wondering is if typically other variables will be linked to choosing a light or dark navbar. And so whether we might want a more clever way to opt in to a dark vs light navbar (although probably the basic variables for each element will be useful to have anymore, so the more clever logic could also be for later).
For example, the color of "hamburger" icon on mobile collapsed menu is dark, which should also get a light color when using a darker navbar.

[SebastianJL]

One thing I am wondering is if typically other variables will be linked to choosing a light or dark navbar. And so whether we might want a more clever way to opt in to a dark vs light navbar (although probably the basic variables for each element will be useful to have anymore, so the more clever logic could also be for later).
For example, the color of "hamburger" icon on mobile collapsed menu is dark, which should also get a light color when using a darker navbar.

I didn't even think about the hamburger menu. As you can see I also had to change the color of the fa-github-square.

So I think it would definitely make sense, to be able to choose between a dark and a light mode.
In my case, however, this wouldn't immediately help. Since we chose a light background for the website body and a dark background for the navbar. For me, it would be most helpful at the moment to add more variables that I could change individually. As you can see, it is still possible to achieve the look I want, but I have to resort to manipulating the css classes directly.

[12rambau]

In #659 we decided to reduce the number of css variable to make it easier to customize general things.

I personally think that what you did in the custom.css is just fine and more importantly, adding an extra variable will not prevent you from writing some custom css for the burger button or any of the icons.

#navbar-main {background-color: #2f4858 !important;}

VS

--pst-color-navbar-background: #2f4858

@choldgraf and @damianavila do you think this variable should be added to the _color file ?

[choldgraf]

I'd be +1 on adding this as a theme variable. The main question is whether to use it as an opportunity to begin adopting the standard "header" word instead of "navbar" (since navbar is somewhat ambiguous...the left sidebar and right sidebars are also navigation bars).

[12rambau]

A bit more explanation about why I think we shouldn't add this variable.

In the cuurent implementation of pydata-sphinx-theme, changing the navbar background color to let's say dark blue will lead to the following issues:

• the Title (if no logo is used) will have 0 contrast on dark blue as it's written in black
• the burger button will be invisible on small screen as it's also black
• the links that use the default color of theme will move from dark grey to prurple both colors will also be invisible
• if used both theme-switcher and version-switcher will be purple on top of blue
• finally if the links logo you've chosen in navbar-end have no color then we use the text color i.e. again black.

to have a working dark blue navbar you need at least to create:

--pst-color-navbar-background
--pst-color-navbar-muted
--pst-color-navbar-text-base
--pst-color-navbar-active
--pst-color-navbar-on-background 

So to customize the navbar without changing the display (and I'm pretty sure I'm forgetting something), this is not 1 but 5 variables that need to be added back to the list. It's going backward with respect to what was achieve in #659 (some if these vars were existing). We traded less flexibility on colors for easier maintenance and small customization.
That's why I think heavy cutomization should fall on in the user custom css.

[12rambau]

is there some feedback from other maintainers if I should reimplement the header variables in the _color files?
I explained why I'm not in favor of it but I'm happy to hear feedback from others

[drammock]

Well, we have to draw a line somewhere regarding how much complexity we're willing to maintain/support in order to make things easy for users. To me this is a good example of something that is already possible (through custom CSS) so I'd rather focus our maintenance/development efforts on things that users can't achieve without our help (like build time issues, etc)