Hey everyone, I’d like to propose a change to the background color of the menus beneath the main header. This comes as a result of XWIKI-15629
Current Issue:
The menu shares the same color as the header, which creates a visually confusing style as the visual hierarchy is difficult to be perceived (both elements have the same visual weight), as shown below:
Additional issues:
The menu has an inner shadow that isn’t used anywhere else in the interface, making it stand out unnecessarily.
Without editing CSS directly, it is impossible to customize the navigation background and header background separately.
Proposed Solution:
I suggest creating a new color variable called @header-default-bg, which would be applied only to the header. The existing @navbar-default-bg would then be used exclusively for the menu. By default, this menu color could be 10% less saturated and bright compared to the header color, maintaining a subtle differentiation. @header-default-bg should also be exposed on the admin interface for easy customization (Global Admin > Look and Feel > Themes > Iceberg > Customize > Navigation bar).
Another change would be to reduce the height of the navbar. Currently, it’s the same height as the header, but as a secondary element, it doesn’t need to be that tall. Shortening it slightly would improve visual hierarchy.
As a user of XWiki, I am really interesting in this feature as it would avoid a lot of CSS customization for menu (below the navbar-header), used through the Menu Application.
But in the Navigation bar section of the administration section, there are alll these variables: @navbar-default-color, @navbar-default-bg, @navbar-default-link-color, @navbar-default-link-hover-color, @navbar-default-link-hover-bg, @navbar-default-link-active-color, @navbar-default-link-active-bg, @navbar-height.
Should all variables be available also for the menu ?
Hi @LucD, good point. Yes, for the sake of consistency, I think that these variables should be available as well. In practice, we should have all of them in @navbar- and @header- prefixes.
So if I understand well, we should probably add a new section to the colorTheme admin UI.
Side note: This UI is getting larger and larger with time. Maybe it could be interesting to give further details on what’s the main element for each section (it could get confusing for someone not very knowledgeable to differentiate between dropdown, navbar and header for example).
For the idea of using color to differentiate those elements. Note that even on xwiki.org we do use a stylesheet extension to have both of these colors different, so there’s definitely a use case for this
I assume this default you’re talking about is using the Iceberg colorTheme. Note that we cannot extend the rule you described to all colorThemes. Here is an example with Charcoal, where the color is pretty much black and we cannot reduce saturation and brightness.
I agree, and the naming for the variables also does not help. For less technically inclined users it can be scary to mess with “@navbar-default-link-hover-color” but not so much with “Link hover color” inside a section named “Navigation Bar” (this also would need to be translated as well).
On a side note, we seem to have a bug in the color picker. It didn’t open for me sometimes, but I could not find the pattern in the error, sometimes it worked, sometimes it didn’t.
Indeed, we can have two rules based on the general lightness of the color theme, if it is a dark one we can ADD 10% brightness to the navbar and get something like this:
I would update every color theme, but following the same rule. It shouldn’t be too difficult if the main rule is simple enough.
Light themes: reduce saturation and brightness by 10%
Dark theme: add brightness by 10% (maybe we can do with less, like 5%)
In HSL color model, it is easy to find the corresponding hex values and I can add them to the final proposal for each Theme. What do you think?
I didn’t see it this solution yesterday, but if the rule is simple enough, we can just use LESS color functions to set the default value of this color from the @header-default-bg. I don’t think it’s worth your time to find and note down hex values for every colortheme
We could, but then we would rely a little bit more on LESS functions, and it will be harder to go LESSless in the future. It’s really no trouble for me to do it manually for the default themes.
I just found a blog post about it, there’s a feature that’ll be fully supported soon and should map pretty well to LESS color functions
So we should not restrain our use of LESS color functions in regards to this move