Automatic theme switching based on 'prefers-color-scheme' media query #5172

New Issue

GiteaMirror · 2025-11-02T06:16:48-06:00

GiteaMirror commented

2025-11-02 06:16:48 -06:00

Originally created by @septatrix on GitHub (Apr 2, 2020).

Gitea version (or commit ref): 1.11.3
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
  1. Go to Settings > Account > Select default theme
  2. There is no automatic mode or similar
- No
- Not relevant

Description

Gitea currently includes a dark and a light theme, however there is no way to automatically switch between these themes based on the (prefers-color-scheme: dark) media query.
I would like to propose the addition of an additional automatic theme which would switch between these two themes based on said media query similar to what StackOverflow implemented this week and maybe event set this automatic theme as the default mode.

Originally created by @septatrix on GitHub (Apr 2, 2020). - Gitea version (or commit ref): 1.11.3 - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) 1. Go to Settings > Account > Select default theme 2. There is no automatic mode or similar - [ ] No - [x] Not relevant ## Description Gitea currently includes a dark and a light theme, however there is no way to automatically switch between these themes based on the `(prefers-color-scheme: dark)` media query. I would like to propose the addition of an additional automatic theme which would switch between these two themes based on said media query similar to what StackOverflow implemented this week and maybe event set this automatic theme as the default mode.

GiteaMirror added the issue/duplicate label 2025-11-02 06:16:48 -06:00

GiteaMirror closed this issue

2025-11-02 06:16:48 -06:00

GiteaMirror commented

2025-11-02 06:16:49 -06:00

@silverwind commented on GitHub (Apr 2, 2020):

It can be done, but first we need to rework theming which currently is a whitelist-based config option that only allows configured themes to be selected. I want to change it to a blacklist or remove the config option completely. Then we can introduce new themes like this "auto" knowing that users will actually be able to select them.

Also, I'm not sure arc-green is a worthy default theme, it has quality issues. I plan to work on that as well.

@silverwind commented on GitHub (Apr 2, 2020): It can be done, but first we need to rework theming which currently is a whitelist-based config option that only allows configured themes to be selected. I want to change it to a blacklist or remove the config option completely. Then we can introduce new themes like this "auto" knowing that users will actually be able to select them. Also, I'm not sure `arc-green` is a worthy default theme, it has quality issues. I plan to work on that as well.

GiteaMirror commented

2025-11-02 06:16:49 -06:00

@septatrix commented on GitHub (Apr 2, 2020):

Is there already an issue tracking the theming overhaul?
Maybe we could group them into dark and light and let users choose a default for each group. Then "auto" could switch between these like VS Code does on Windows and MacOS (I think)

@septatrix commented on GitHub (Apr 2, 2020): Is there already an issue tracking the theming overhaul? Maybe we could group them into dark and light and let users choose a default for each group. Then "auto" could switch between these like VS Code does on Windows and MacOS (I think)

GiteaMirror commented

2025-11-02 06:16:49 -06:00

@silverwind commented on GitHub (Apr 3, 2020):

No issue I think, but my plan is at least 3 themes:

gitea (default light)
gitea-dark (default dark)
arc-green
auto

The steps are:

remove THEMES config option (the whitelist)
add auto-generation for arc-green
add gitea-dark (also autogenerated)

@silverwind commented on GitHub (Apr 3, 2020): No issue I think, but my plan is at least 3 themes: - gitea (default light) - gitea-dark (default dark) - arc-green - auto The steps are: - remove `THEMES` config option (the whitelist) - add auto-generation for arc-green - add gitea-dark (also autogenerated)

GiteaMirror commented

2025-11-02 06:16:50 -06:00

@guillep2k commented on GitHub (Apr 4, 2020):

@silverwind I'm not well versed in modern web UI tools, so forgive me if I speak nonsense, but is it possible to structure our .less files so that font and color rules can be automatically extracted to a .css file the users can override without requiring node/webpack? Of course I say color but I actually mean things that are not structural, likely to customize in a theme (fonts, etc.). The rest of the rules (general sizes and behaviors) would remain in a "first-level" CSS.

I think it would be cool to have some make theme-template command as part of our builds, and distribute the css for users to edit as they please. The most common theme customization is just the color palette, that's why my first thought went there.

@guillep2k commented on GitHub (Apr 4, 2020): @silverwind I'm not well versed in modern web UI tools, so forgive me if I speak nonsense, but is it possible to structure our `.less` files so that _font and color_ rules can be automatically extracted to a `.css` file the users can override without requiring node/webpack? Of course I say color but I actually mean things that are not structural, likely to customize in a theme (fonts, etc.). The rest of the rules (general sizes and behaviors) would remain in a "first-level" CSS. I think it would be cool to have some `make theme-template` command as part of our builds, and distribute the `css` for users to edit as they please. The most common theme customization is just the color palette, that's why my first thought went there.

GiteaMirror commented

2025-11-02 06:16:50 -06:00

@silverwind commented on GitHub (Apr 10, 2020):

@guillep2k possible, yes, but hard.

I think the best option for user-based customization will be CSS Variables which users then could override in their own CSS file without the need that we introduce any additional build steps. Supporting this means dropping IE11 and requires a big refactor and some discipline on our side to not use bare color/font values, but I imagine linting may be able to help there.

@silverwind commented on GitHub (Apr 10, 2020): @guillep2k possible, yes, but hard. I think the best option for user-based customization will be [CSS Variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) which users then could override in their own CSS file without the need that we introduce any additional build steps. Supporting this means dropping IE11 and requires a big refactor and some discipline on our side to not use bare color/font values, but I imagine linting may be able to help there.

GiteaMirror commented

2025-11-02 06:16:50 -06:00

@silverwind commented on GitHub (Apr 10, 2020):

Still there's the issue with third-party CSS (fomantic) not using said variables, so it's not a complete solution. It may be possible to extract certain rules by using a CSS parser and parsing all files in public.

@silverwind commented on GitHub (Apr 10, 2020): Still there's the issue with third-party CSS (fomantic) not using said variables, so it's not a complete solution. It may be possible to extract certain rules by using a CSS parser and parsing all files in `public`.

GiteaMirror commented

2025-11-02 06:16:50 -06:00

@guillep2k commented on GitHub (Apr 10, 2020):

@silverwind I really like the CSS variables alternative. That would be a good enough reason to leave IE11 behind, I think; we didn't remove support from it until now because it didn't impose an actual limitation I believe, but if users will get a sizeable benefit from moving on, I would back the move.

Does fomantic force many colors in its rules? Can they be overriden without resorting to !important? (i.e. a rule with the same weight should just override the previous one).

We could do that with the color theme first. And later on we could include fonts and relative sizes.

@guillep2k commented on GitHub (Apr 10, 2020): @silverwind I really like the CSS variables alternative. That would be a good enough reason to leave IE11 behind, I think; we didn't remove support from it until now because it didn't impose an actual limitation I believe, but if users will get a sizeable benefit from moving on, I would back the move. Does fomantic force many colors in its rules? Can they be overriden without resorting to `!important`? (i.e. a rule with the same weight should just override the previous one). We could do that with the color theme first. And later on we could include fonts and relative sizes.

GiteaMirror commented

2025-11-02 06:16:51 -06:00

@silverwind commented on GitHub (Apr 10, 2020):

I think Fomantic uses Less variables but those are dropped during the Less -> CSS conversion. Maybe there is a Less compiler out there that can produce CSS variables from Less variables, that would be the only option I see besides a custom theme generator script.

Manually overriding any sizable CSS is a no-go. I think to properly override fomantic alone would require something like 200kB of CSS which will change with every update.

@silverwind commented on GitHub (Apr 10, 2020): I think Fomantic uses Less variables but those are dropped during the Less -> CSS conversion. Maybe there is a Less compiler out there that can produce CSS variables from Less variables, that would be the only option I see besides a custom theme generator script. Manually overriding any sizable CSS is a no-go. I think to properly override fomantic alone would require something like 200kB of CSS which will change with every update.

GiteaMirror commented

2025-11-02 06:16:51 -06:00

@guillep2k commented on GitHub (Apr 11, 2020):

I think I follow. Maybe this answer from SO is relevant?

@guillep2k commented on GitHub (Apr 11, 2020): I think I follow. Maybe this [answer from SO](https://stackoverflow.com/a/56288809/225979) is relevant?

GiteaMirror commented

2025-11-02 06:16:51 -06:00

@silverwind commented on GitHub (Apr 11, 2020):

That's the manual way, I want it happen automatically during Less compilation. I found this, maybe worth trying but we'd probably need to hack up fomantic's build process to integrate that. Also, that plugin seems to have issues with media queries, so will likely not work.

@silverwind commented on GitHub (Apr 11, 2020): That's the manual way, I want it happen automatically during Less compilation. I found [this](https://github.com/miyamarisubs/less-plugin-custom-properties), maybe worth trying but we'd probably need to hack up fomantic's build process to integrate that. Also, that plugin seems to have issues with media queries, so will likely not work.

GiteaMirror commented

2025-11-02 06:16:51 -06:00

@pat-s commented on GitHub (Apr 19, 2021):

Given that GitHub has automatic theme switching now and I really like it, I am curious what the plans / status is on this one? 🙂

@silverwind

@pat-s commented on GitHub (Apr 19, 2021): Given that GitHub has automatic theme switching now and I really like it, I am curious what the plans / status is on this one? 🙂 @silverwind

GiteaMirror commented

2025-11-02 06:16:51 -06:00

@pat-s commented on GitHub (Apr 19, 2021):

Possible duplicate: https://github.com/go-gitea/gitea/issues/8183

@pat-s commented on GitHub (Apr 19, 2021): Possible duplicate: https://github.com/go-gitea/gitea/issues/8183

GiteaMirror commented

2025-11-02 06:16:52 -06:00

@techknowlogick commented on GitHub (Apr 19, 2021):

Yup, closing as dupe per above.

@techknowlogick commented on GitHub (Apr 19, 2021): Yup, closing as dupe per above.

GiteaMirror commented

2025-11-02 06:16:52 -06:00

@septatrix commented on GitHub (Apr 20, 2021):

Alas I would have preferred closing the other one as there is a lot more discussion under this one already

@septatrix commented on GitHub (Apr 20, 2021): Alas I would have preferred closing the other one as there is a lot more discussion under this one already

GiteaMirror referenced this issue

2025-11-02 14:58:10 -06:00

[PR #5174] [MERGED] Kill testing processes if the test takes too long #17679

GiteaMirror referenced this issue

2025-11-02 14:59:45 -06:00

[PR #5178] [MERGED] Disable sqlite test #17682

Sign in to join this conversation.