I purpose we first define variables for colors, the same way that bootstrap does, so we could end up with something like:

--white
--black

--grey-100
--grey-200
...
--grey-900

--blue-100
...
--blue-900

Then we use this colors to construct the variables for the other elements:

--body-bg: var(--white)
--link-color: var(--blue-200)
--form-bg: var(--gray-100)

Also, I used css-color-extractor on all admin CSS files, and this is the list of every color used, we can group the variables based on this:

Some of them look really close to each other (like #f6f6f6 and #f9f9f9) should we merge them into a single variable?

Thanks!

Re. defining colors first. There's a different accepted issue for adding a dark mode here https://code.djangoproject.com/ticket/31259 – I think defining colors first isn't a big help in this case, except if we started to calculate colors from other colors. I have been experimenting a bit with this approach (see the base.html file) but this may be too much for a single pull request. Maybe colors should be redefined in 3rd party projects anyway, which should be much easier once we get good names down...

... which brings me to the second point: Naming is very hard. And it gets harder the more names we have to define. I experimented with using the same color for borders everywhere but that does not look right on different backgrounds. Other colors can be merged easily and I'd certainly propose we should try to merge those. Otherwise this PR wouldn't help at all with addressing the accessibility issues and with theming.

Fresh eyes on the code are always helpful, thanks again for your inputs!

Btw, I scrolled through the list of pull requests and found #13409 – merging was straightforward without many conflicts. A merge of the current branch tips is here https://github.com/matthiask/django/tree/mk/admin-css-31986-merge

I really like this PR, I was going to work on this myself at some point 👍

This may or may not be a good idea, I'm just wondering if you've thought about it:

Have you considered putting the variables definitions in a new file (theme.css, colors.css, or similar) that is loaded before anything else? That way changing to dark theme or users customising colours and so forth can be done very easily. Of course, it's also another request to the server...

I'd also be in favour of moving some of the more similar colours together to improve consistency and maintainability - I think it should be in another ticket / PR though.

@knyghty Thanks! Yes, I've thought about that. However, I don't think it's necessary since overriding those values also works when it happens when loading the theme CSS last since CSS works that way. Or even like this, with a project-specific templates/admin/base.html override:

{% extends 'admin/base.html' %}

{% block extrahead %}{{ block.super }}
<style>
/* Purple, just as an experiment to see what's missing */
:root {
  --primary: #9774d5;
  --secondary: #785cab;
  --link-fg: #7c449b;
  --link-selected-fg: #8f5bb2;
}
</style>
{% endblock %}
```

Oh, you mean you can override the CSS variables after they are set? That's very good to know, I had no idea, thanks.

So then a dark or other alternate theme could just implement the same vars in a new file that's loaded whenever?

If that's the case, it sounds good. It might be nice to just have the colours in one place so you know what you can override, but I think having them all together in base CSS file is good enough 👍

Regarding:

I'd also be in favour of moving some of the more similar colours together to improve consistency and maintainability - I think it should be in another ticket / PR though.

Doing this in a different ticket may be fine but either we first convert everything to use CSS variables (meaning we have to find names for all those colors which we'll drop again anyway) or we standardize colors first. Both sound like good approaches but since contributor and reviewer time isn't an endless resource I'd strongly prefer moving forward with the approach outlined here. Killing two birds with one stone and all that.

So then a dark or other alternate theme could just implement the same vars in a new file that's loaded whenever?

Yes, exactly.

I've imported https://github.com/matthiask/django/tree/mk/admin-css-31986-merge into https://github.com/matthiask/django-variable-admin and published this to https://pypi.org/project/django-variable-admin/ so that I can use this in projects and find any remaining problems with the pull request.

Hello,
I was considering using CSS variables or SASS when I opened #12444. I feared that CSS variables wouldn't be accepted because of a possible (?) performance impact or browser support, but that is not bad: https://caniuse.com/css-variables. SASS had even bigger issues because it would either require compiling it on every change in code or compiling it when uploading to pypi, etc.

I think that using variables makes it much easier to make theme changes in Django and add other themes like the dark theme. I hope that this PR will be merged soon and I will rebase #12444 on it.

Also, I think that dedicated and designed dark themes are nicer than calculated dark themes from light ones.