go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.75k stars 5.46k forks source link

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

Open clarfonthey opened 3 years ago

clarfonthey commented 3 years ago

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:

light theme dark theme

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 dark theme

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.

noerw commented 3 years ago

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".

clarfonthey commented 3 years ago

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.