The theme switch sits in the top-right corner, outside the account menu; the menu should be the corner and the switch needs a better place #197

New issue

Closed

opened 2026-09-13 08:13:24 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-13 08:13:24 +00:00

Owner

Observation

The last thing at the top right of every page is the theme switch, not the account menu.
The header's right-hand group (templates/base.html:80-117) runs, in order: the search
box, the account menu, then {% include "core/partials/theme_switch.html" %}. So the
corner a person reaches for their own name, their settings and Sign out — the corner
every application puts the account in, and the one the wiki's Getting started points at
("Your name, top right → Your details") — holds a sun-moon-monitor button, and the menu
sits one control in from the edge.

The account menu should be the outermost control at the top right, and the theme switch
needs a better place than beside it.

What the switch is, and where else it already lives

core/partials/theme_switch.html is one button with three states — light, dark, match
the operating system — posting to accounts:theme, applied by app.js (:179-205)
before the reply arrives. It is a convenience, and it is the second way to do the same
thing: Settings → Appearance is the explicit one, and the wiki says exactly that
("The switch at the top right of every page cycles through the same three; this is the
explicit version", Getting-started.md:26). Nothing depends on the switch being in the
header: the script finds it by data-theme-switch wherever it is, and the CSS picks the
icon from data-current on the form.

Where it could go

Three honest candidates, in the order they seem right:

Inside the account menu, as a row above the separator — Your details, Settings,
Theme: dark (press to cycle), Server settings. It is a preference of the person
whose menu it is, the menu is already the one disclosure on the right, and the corner
then holds one control. The row is a form, as Sign out already is (base.html:110),
so the menu already knows how to hold a POST. Cost: the switch is one click further
away, which for a three-state cycle nobody presses twice a day is nothing.
The footer, beside the version. Reachable on every page, out of the way, and where
a chrome-level preference sits on a good many sites. Cost: below the fold on a long
page — the same fold #195 is about.
Nowhere but Settings → Appearance. The explicit version exists and is one page
away. Cost: the "apply before the reply" immediacy is lost, and somebody on a shared
machine who wants the page dark now has to find the setting.

Whichever it is, the theme switch leaves the header row, and the account menu becomes the
last child of the ms-auto group.

What moves with it

tests/test_header.py says, in its docstring and in
test_the_right_side_holds_the_account_menu_and_the_theme_switch, that the right side
holds the menu and the switch, and test_signed_out_visitors_see_neither_menu_nor_switch
asserts the switch's absence for a visitor. Both change to say the new truth.
tests/e2e/test_accessibility.py:40 excuses the switch and the menu from the landmark
rule because of where they sit; inside the menu or the footer that excuse changes shape.
Getting-started.md:26 names the top right; the sentence moves with the button.
The narrow-screen header: below md the search box is hidden and the row is wordmark,
Menu, then the right group. The account menu becoming the corner control on a phone is
the same change and needs no separate treatment; the switch inside the menu is one row
fewer on a 320-pixel row that #165 already fought for.

Not in this issue: what the switch does, or the three states.

## Observation The last thing at the top right of every page is the theme switch, not the account menu. The header's right-hand group (`templates/base.html:80-117`) runs, in order: the search box, the account menu, then `{% include "core/partials/theme_switch.html" %}`. So the corner a person reaches for their own name, their settings and *Sign out* — the corner every application puts the account in, and the one the wiki's *Getting started* points at ("Your name, top right → Your details") — holds a sun-moon-monitor button, and the menu sits one control in from the edge. The account menu should be the outermost control at the top right, and the theme switch needs a better place than beside it. ## What the switch is, and where else it already lives `core/partials/theme_switch.html` is one button with three states — light, dark, match the operating system — posting to `accounts:theme`, applied by `app.js` (`:179-205`) before the reply arrives. It is a convenience, and it is the *second* way to do the same thing: *Settings → Appearance* is the explicit one, and the wiki says exactly that ("The switch at the top right of every page cycles through the same three; this is the explicit version", `Getting-started.md:26`). Nothing depends on the switch being in the header: the script finds it by `data-theme-switch` wherever it is, and the CSS picks the icon from `data-current` on the form. ## Where it could go Three honest candidates, in the order they seem right: 1. **Inside the account menu**, as a row above the separator — *Your details*, *Settings*, *Theme: dark* (press to cycle), *Server settings*. It is a preference of the person whose menu it is, the menu is already the one disclosure on the right, and the corner then holds one control. The row is a form, as *Sign out* already is (`base.html:110`), so the menu already knows how to hold a POST. Cost: the switch is one click further away, which for a three-state cycle nobody presses twice a day is nothing. 2. **The footer**, beside the version. Reachable on every page, out of the way, and where a chrome-level preference sits on a good many sites. Cost: below the fold on a long page — the same fold #195 is about. 3. **Nowhere but Settings → Appearance.** The explicit version exists and is one page away. Cost: the "apply before the reply" immediacy is lost, and somebody on a shared machine who wants the page dark *now* has to find the setting. Whichever it is, the theme switch leaves the header row, and the account menu becomes the last child of the `ms-auto` group. ## What moves with it - `tests/test_header.py` says, in its docstring and in `test_the_right_side_holds_the_account_menu_and_the_theme_switch`, that the right side holds the menu *and* the switch, and `test_signed_out_visitors_see_neither_menu_nor_switch` asserts the switch's absence for a visitor. Both change to say the new truth. - `tests/e2e/test_accessibility.py:40` excuses the switch and the menu from the landmark rule because of where they sit; inside the menu or the footer that excuse changes shape. - `Getting-started.md:26` names the top right; the sentence moves with the button. - The narrow-screen header: below `md` the search box is hidden and the row is wordmark, Menu, then the right group. The account menu becoming the corner control on a phone is the same change and needs no separate treatment; the switch inside the menu is one row fewer on a 320-pixel row that #165 already fought for. Not in this issue: what the switch does, or the three states.

tiagoagueda added this to the 0.3.0 milestone

2026-09-13 08:13:24 +00:00

tiagoagueda added the

enhancement

tier/4

interface

labels

2026-09-13 08:13:24 +00:00

tiagoagueda referenced this issue from a commit

2026-09-15 12:56:05 +00:00

Put the theme switch inside the account menu, and the menu in the corner

tiagoagueda closed this issue