fix(NcAppNavigationItem): Make active state darker than hover

[nfebe]

The selected nav item appeared lighter than the hovered one in the new NC34+ design. Use a semi-transparent darker overlay so the active state sits visually below hover, matching the mockup intent.

Resolves #8526

🖼️ Screenshots

🏚️ Before	🏡 After

[nfebe]

Pointing out this was what already existed before @susnux pushed against it via reviews in #8448 (NcListItem a11y concern) (#8448 (comment)) and #8448 (NcAppNavigationItem follow-up) (#8448 (comment)).

So reverted as it matches @kra-mo's request in #8526 ("darker and not opaque").

The argument about contrast not being guaranteed is not accurate because the active bg is 84% transparent over --color-main-background; what shows through dominates the visible surface, and the text is rendered with --color-main-text -- the NC-guaranteed contrast pair.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.85%. Comparing base (e22ee80) to head (fb9b34b).
⚠️ Report is 15 commits behind head on stable8.

Additional details and impacted files

@@           Coverage Diff            @@
##           stable8    #8533   +/-   ##
========================================
  Coverage    46.85%   46.85%           
========================================
  Files          195      195           
  Lines         4926     4926           
  Branches      1205     1268   +63     
========================================
  Hits          2308     2308           
+ Misses        2531     2529    -2     
- Partials        87       89    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kra-mo]

At least from the screenshot, with these colors, contrast does seem to check out. Is that not always the case @susnux?

[ShGKme]

Could you also provide screenshots on:

• Dark theme
• Custom primary color light theme
• Custom primary color dark theme

We now have more and more new/updated UI components with new colors that are dynamically computed with different formulas in different places.

It not only makes it hard for maintenance and keeping colors consistent across different places but also for testing (each time we need to make sure it is accessible and supports Nextcloud themes and Nextcloud theming).

@kra-mo Can we have a new palette with the new colors?

[kra-mo]

Can we have a new palette with the new colors?

I mean, I don't think more and more color variables would make sense.

Computing colors from each other is nicer, but they should be based on constraints and logic, especially when it comes to transparency, which I think we've been underutilizing in general in favor or solid colors.

Like a lot of hover and border colors right now are hardcoded solid ones, which start looking off as soon as you put them over anything other than the default background color (in this case, the sidebar).

I think this may warrant a bigger discussion, possibly also tying into OKLCH?

[ShGKme]

I mean, I don't think more and more color variables would make sense.

Computing colors from each other is nicer, but they should be based on constraints and logic, especially when it comes to transparency, which I think we've been underutilizing in general in favor or solid colors.

Like a lot of hover and border colors right now are hardcoded solid ones, which start looking off as soon as you put them over anything other than the default background color (in this case, the sidebar).

Computing colors doesn't conflict with having them in the theming palette. We already do it.

For example, we have --color-error as a static value, and --color-error-hover computed from the --color-error. We can use this --color-error-hover without creating a new formula or thinking what to do with it on hover.

What is missing is a specific semantic named value in the theme.

The problem is reinventing the computation/color in many individual places. It results in:

• Inconsistency - different computation in different places for similar elements
• Complexity - no value to use for a new place during development
• Issues - each new place with a new formula must be tested in different themes with different theming params

I think this may warrant a bigger discussion, possibly also tying into OKLCH?

My experience with OKLCH wasn't good. While in theory it should work better, the colors often looked worse than with simpler HSL manipulation.

But how exactly we compute (PHP, CSS, a-channel, OKLCH) doesn't matter.
If we have a named semantic value to reuse, we can change the computation later.

[kra-mo]

Ok, let's set aside the topic of computed colors broadly.

This hover color should be consistent across all elements that are neutral/derived from primary, which means we should find some color to consistently mix with everything.

Primary, secondary, as well as tertiary-colored, including transparent controls should all look similar when hovered, which means in this case, the hover color of tertiary elements (which should be without a background), which should be semitransparent instead of opaque.

Let's say that all hovered elements tend toward some mix of fg + primary. Maybe 70% fg, 30% primary (depends on the color space). Let's call this the hover "shade".

So all elements' hover color would be mixed with this shade. Let's say primary's hover color would be primary + 20% shade, secondary's would be secondary + 15% shade and transparent controls' would be transparent + 10% shade (so shade at 10% opacity).

Does that make sense? I'm not sure I explained it well.