Theme-based label colors (accessibility/aesthetic) #7713

New Issue

GiteaMirror · 2025-11-02T07:34:23-06:00

GiteaMirror commented

2025-11-02 07:34:23 -06:00

Originally created by @clarfonthey on GitHub (Aug 19, 2021).

Right now, issue label colors are based upon raw RGB colours, and it's basically impossible to make sure that they look legible on all themes. Although the existing, hex-based colour options can be kept (with the option to enable/disable via app.ini), it would be nice to allow theme-based colours which will simply output classes that can be styled per-theme. This way, if you want a label to be "red," for example, it would mark the issue with a .label-red class which can be configured using CSS, so that the theme can choose a suitable red that looks good for the theme. Alternatively, if we're fine requiring browsers that have CSS variables support, we could use those instead. Ideally, the default label sets would use these colours instead of raw RGB colours.

We could probably add some kind of metadata to themes to list what colours they offer, then simply allow users to choose the colours that are available for all themes. This way, themes can add custom colours and they're usable as long as all themes that a user can pick have those colours.

This would also help for acessibility-focused themes, as they could adjust the colours on the labels for people who might not easily be able to read the existing colours or have colour blindness.

For a more concrete example, let's say that #16729 is merged and the user chooses #FF0000 as a label color. Here's what it looks like on both default themes:

Imagine that instead the colour was listed as "red," which can be configured based upon the theme. I'll choose the a suitable red from both themes:

If you tell someone to look for the red label, it's still red; it just fits in with the theme better. And, more importantly, if someone has some form of colourblindness that makes certain colours difficult for them to distinguish, they can opt to use a different theme which modifies the colour to one they can more easily distinguish. Saying "look for the red label" for these people already would have not been helpful, so losing that colour information is acceptable in exchange for accessibility.

Originally created by @clarfonthey on GitHub (Aug 19, 2021). Right now, issue label colors are based upon raw RGB colours, and it's basically impossible to make sure that they look legible on all themes. Although the existing, hex-based colour options can be kept (with the option to enable/disable via `app.ini`), it would be nice to allow theme-based colours which will simply output classes that can be styled per-theme. This way, if you want a label to be "red," for example, it would mark the issue with a `.label-red` class which can be configured using CSS, so that the theme can choose a suitable red that looks good for the theme. Alternatively, if we're fine requiring browsers that have [CSS variables](https://caniuse.com/css-variables) support, we could use those instead. Ideally, the default label sets would use these colours instead of raw RGB colours. We could probably add some kind of metadata to themes to list what colours they offer, then simply allow users to choose the colours that are available for all themes. This way, themes can add custom colours and they're usable as long as all themes that a user can pick have those colours. This would also help for acessibility-focused themes, as they could adjust the colours on the labels for people who might not easily be able to read the existing colours or have colour blindness. ---- For a more concrete example, let's say that #16729 is merged and the user chooses #FF0000 as a label color. Here's what it looks like on both default themes: ![light theme](https://user-images.githubusercontent.com/15850505/130178922-d6946d1f-686d-4c36-a5bb-1617fe48f64f.png) ![dark theme](https://user-images.githubusercontent.com/15850505/130178921-c4b68bf1-86ce-4f1e-b4eb-8ee44d4d69f9.png) Imagine that instead the colour was listed as "red," which can be configured based upon the theme. I'll choose the a suitable red from both themes: ![light theme](https://user-images.githubusercontent.com/15850505/130179573-23abb8bc-364b-4cfd-8a23-d4802fc17f9e.png) ![dark theme](https://user-images.githubusercontent.com/15850505/130179571-e0e5b25b-ce8f-47ab-9555-3b0e9fcd6f70.png) If you tell someone to look for the red label, it's still red; it just fits in with the theme better. And, more importantly, if someone has some form of colourblindness that makes certain colours difficult for them to distinguish, they can opt to use a different theme which modifies the colour to one they can more easily distinguish. Saying "look for the red label" for these people already would have not been helpful, so losing that colour information is acceptable in exchange for accessibility.

GiteaMirror added the topic/theme type/proposal labels 2025-11-02 07:34:23 -06:00

GiteaMirror commented

2025-11-02 07:34:23 -06:00

@noerw commented on GitHub (Aug 19, 2021):

So essentially you are proposing to introduce a new concept of 'label categories', expose those via CSS classes, and make the builtin themes map these categories to colors?

We could probably add some kind of metadata to themes to list what colours they offer,

I think doing a deeper theme - UI logic integration requires ridiculous amounts of new infrastructure for such a simple feature.
I think going with 10 fixed label categories would be totally fine.
Users could then go ahead and override colors via .label.cat10 { background-color: foobar; }

Thinking more about this, this might be a bad idea as it makes communication about labels ambiguous: users can have different themes and mean different things when talking about "we aim to close all red issues within this week".

@noerw commented on GitHub (Aug 19, 2021): So essentially you are proposing to introduce a new concept of 'label categories', expose those via CSS classes, and make the builtin themes map these categories to colors? > We could probably add some kind of metadata to themes to list what colours they offer, I think doing a deeper theme - UI logic integration requires ridiculous amounts of new infrastructure for such a simple feature. I think going with 10 fixed label categories would be totally fine. Users could then go ahead and override colors via `.label.cat10 { background-color: foobar; }` --- Thinking more about this, this might be a bad idea as it makes communication about labels ambiguous: users can have different themes and mean different things when talking about "we aim to close all red issues within this week".

GiteaMirror commented

2025-11-02 07:34:24 -06:00

@clarfonthey commented on GitHub (Aug 20, 2021):

I think you're misunderstanding what I'm suggesting. The goal isn't to have a completely flexible palette of 10 colours, where each theme can set whichever colour to whatever they want. The goal is that these colours are still defined by name, but the theme has the option of choosing what specific RGB value to use.

I updated the description with screenshots that maybe will help.

UI logic integration requires ridiculous amounts of new infrastructure for such a simple feature.
I think going with 10 fixed label categories would be totally fine.
Users could then go ahead and override colors via .label.cat10 { background-color: foobar; }

I disagree; adding a manifest format for themes which provides information about them would be useful outside the scope of this feature. However, I agree that if we're planning to just implement this specific feature, it would be a bit overkill.

@clarfonthey commented on GitHub (Aug 20, 2021): I think you're misunderstanding what I'm suggesting. The goal isn't to have a completely flexible palette of 10 colours, where each theme can set whichever colour to whatever they want. The goal is that these colours are still defined by name, but the theme has the option of choosing what specific RGB value to use. I updated the description with screenshots that maybe will help. > > UI logic integration requires ridiculous amounts of new infrastructure for such a simple feature. > I think going with 10 fixed label categories would be totally fine. > Users could then go ahead and override colors via `.label.cat10 { background-color: foobar; }` > I disagree; adding a manifest format for themes which provides information about them would be useful outside the scope of this feature. However, I agree that if we're planning to just implement this specific feature, it would be a bit overkill.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7713