Use oklch for the Jenkins UI

[janfaracik]

I've really wanted to do this one for a while, combination of waiting for tooling and browser support to catch up. This PR uses oklch for colours to ensure that our palette is consistent (e.g. colours used for tables, cards, buttons all inherit from the same colour and only have to be defined once).

This change won't have much visual impact on Jenkins, but it will ensure that things are consistent in a way that wasn't easy to do so before. You'll notice slight hue changes here and there across the UI, and actual colours will pop a little bit more depending on if your display supports it.

This change also makes it easier for theme developers, say if a developer wanted to develop an 'Accent colour' plugin they'd only need to update one variable (--accent-color) and Jenkins would reflect that across the UI.

Changing the accent colour property can have quite an impact on the overall interface now

Why oklch?

• OKLCH frees designers from the need to manually choose every color. Designers can define a formula, choose a few colors, and an entire design system palette is automatically generated.
• OKLCH can be used for wide-gamut P3 colors. For instance, new devices (like those from Apple) can display more colors than old sRGB monitors, and we can use OKLCH to specify these new colors.
• Unlike hsl(), OKLCH is better for color modifications and palette generation. It uses perceptual lightness, so no more unexpected results, like we had with darken() in Sass.
• Further, with its predictable lightness, OKLCH provides better a11y.
• Unlike rgb() or hex (#ca0000), OKLCH is human readable. You can quickly and easily know which color an OKLCH value represents simply by looking at the numbers. OKLCH works like HSL, but it encodes lightness better than HSL.

From https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl

Testing done

• Tried in Safari + Chrome
• Tried in Firefox + Firefox ESR

Proposed changelog entries

• Use oklch for the Jenkins UI

Proposed upgrade guidelines

N/A

Submitter checklist

Preview Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@jenkinsci/sig-ux

Before the changes are marked as ready-for-merge:

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[timja]

does dark theme need a similar PR?

(I haven't run this yet but the comparison screenshots look identical to me

[janfaracik]

does dark theme need a similar PR?

It doesn't need one (e.g. still looks fine), but I want to create one to bring over oklch + one for jenkins.io for consistency.

(I haven't run this yet but the comparison screenshots look identical to me

Yeah the hue of the UI is very slightly different, not intended to be noticeable by the user but it does make our UI's theme more consistent.

[timja]

Looks like unsupported by HTMLUnit 😢

https://ci.jenkins.io/job/Core/job/jenkins/job/PR-10078/1/testReport/jenkins.bugs/Jenkins14749Test/linux_jdk21___Linux___JDK_21___Build___Test___manage/

Oh nice: HtmlUnit/htmlunit-cssparser#82