Your details, Settings and Server settings sit in a narrow column: they should use the full width of the page #198

New issue

Closed

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

tiagoagueda commented

2026-09-13 08:16:18 +00:00

Owner

Observation

Your details, Settings and Server settings sit in a narrow column in the middle of
a wide screen. Each is a sidebar beside a page, and on a monitor wider than a laptop's the
pair is capped well short of the screen, with the sidebar taking a good share of what is
left. They should use the full width of the page, as the tables, the board and the
dashboard do since #188.

What caps them, in layers

base.html:135 caps <main> at max-w-7xl (1280 pixels) unless a page empties the
main_width block. Fourteen templates do — every table, list and grid — and none of these
three. Then each of the three adds a tighter cap of its own inside that:

Page	Frame	Cap inside `<main>`	Sidebar
Your details	`accounts/profile.html:7`	`mx-auto max-w-4xl` (896 px)	`lg:w-56` at `:23-28`
Settings	`settings/base.html:9`	`mx-auto max-w-5xl` (1024 px)	`lg:w-56` at `:10`
Server settings	`server/base.html:7`	`mx-auto max-w-5xl` (1024 px)	`lg:w-56` at `:8`

So Your details — nine parts down one page since #180, with its sidebar — draws its
form in roughly 640 pixels on a 2560-pixel screen. Three server pages narrow further
still on their own (person_delete.html:5 and person_username.html:5 at max-w-md,
person_recovery.html:5 at max-w-2xl), which is fine for a one-question form and is
not what this issue is about.

The rule this touches

#188 drew a line and wrote it into the changelog: grids use the whole screen;
everything else keeps its measure, because "a wide page is not a wide paragraph". These
three pages are mostly forms and prose, which is exactly what that rule keeps narrow. The
request is to widen them anyway, and there are two honest readings of why that is right:

The frame is not the paragraph. A sidebar-plus-page layout is a grid at the top
level even when the page inside it is a form: the sidebar wants its column, the page
wants the rest, and capping the pair at 1024 pixels starves both. The measure that
matters for reading is the width of a field or a paragraph, and that can be kept on the
field (field-input already has widths of its own in places) or on a text block,
rather than on the whole frame.
Server settings holds tables. People, Plugins and Logs are lists with several
columns, and the plugins page is the one #184 and #186 have been adding tags and
sentences to; at 1024 pixels minus a sidebar they wrap the way the tables did before
#188.

What a fix has to settle

Empty main_width in the three frames (profile.html, settings/base.html,
server/base.html) and drop the inner max-w-4xl / max-w-5xl, so sidebar and page
share the screen with the 16-pixel gutters <main> already keeps.
Where the reading measure then lives, so a form field does not stretch to 2,000
pixels: a cap on the content column inside the frame, or on fields and paragraphs, or
a decision that these pages' cards may be wide. The #188 comment in base.html says why
the line is where it is and should say the new line.
The Settings pages allauth renders (email, password, MFA — reached through
settings/base.html's panel block) inherit whatever the frame does; check them, they
were the reason the panel block exists.
The one-question server forms keep their own max-w-md; that is a different question.
The browser suite walks all three areas at several widths and languages
(tests/e2e/test_accessibility.py), and #165 and #167 found overflows precisely when
widths changed; that is the check to keep green.

## Observation *Your details*, *Settings* and *Server settings* sit in a narrow column in the middle of a wide screen. Each is a sidebar beside a page, and on a monitor wider than a laptop's the pair is capped well short of the screen, with the sidebar taking a good share of what is left. They should use the full width of the page, as the tables, the board and the dashboard do since #188. ## What caps them, in layers `base.html:135` caps `<main>` at `max-w-7xl` (1280 pixels) unless a page empties the `main_width` block. Fourteen templates do — every table, list and grid — and none of these three. Then each of the three adds a tighter cap of its own inside that: | Page | Frame | Cap inside `<main>` | Sidebar | | --- | --- | --- | --- | | *Your details* | `accounts/profile.html:7` | `mx-auto max-w-4xl` (896 px) | `lg:w-56` at `:23-28` | | *Settings* | `settings/base.html:9` | `mx-auto max-w-5xl` (1024 px) | `lg:w-56` at `:10` | | *Server settings* | `server/base.html:7` | `mx-auto max-w-5xl` (1024 px) | `lg:w-56` at `:8` | So *Your details* — nine parts down one page since #180, with its sidebar — draws its form in roughly 640 pixels on a 2560-pixel screen. Three server pages narrow further still on their own (`person_delete.html:5` and `person_username.html:5` at `max-w-md`, `person_recovery.html:5` at `max-w-2xl`), which is fine for a one-question form and is not what this issue is about. ## The rule this touches #188 drew a line and wrote it into the changelog: *grids use the whole screen; everything else keeps its measure*, because "a wide page is not a wide paragraph". These three pages are mostly forms and prose, which is exactly what that rule keeps narrow. The request is to widen them anyway, and there are two honest readings of why that is right: - **The frame is not the paragraph.** A sidebar-plus-page layout is a grid at the top level even when the page inside it is a form: the sidebar wants its column, the page wants the rest, and capping the pair at 1024 pixels starves both. The measure that matters for reading is the width of a field or a paragraph, and that can be kept on the field (`field-input` already has widths of its own in places) or on a text block, rather than on the whole frame. - **Server settings holds tables.** *People*, *Plugins* and *Logs* are lists with several columns, and the plugins page is the one #184 and #186 have been adding tags and sentences to; at 1024 pixels minus a sidebar they wrap the way the tables did before #188. ## What a fix has to settle - Empty `main_width` in the three frames (`profile.html`, `settings/base.html`, `server/base.html`) and drop the inner `max-w-4xl` / `max-w-5xl`, so sidebar and page share the screen with the 16-pixel gutters `<main>` already keeps. - Where the *reading* measure then lives, so a form field does not stretch to 2,000 pixels: a cap on the content column inside the frame, or on fields and paragraphs, or a decision that these pages' cards may be wide. The #188 comment in `base.html` says why the line is where it is and should say the new line. - The Settings pages allauth renders (email, password, MFA — reached through `settings/base.html`'s `panel` block) inherit whatever the frame does; check them, they were the reason the `panel` block exists. - The one-question server forms keep their own `max-w-md`; that is a different question. - The browser suite walks all three areas at several widths and languages (`tests/e2e/test_accessibility.py`), and #165 and #167 found overflows precisely when widths changed; that is the check to keep green.

tiagoagueda added this to the 0.3.0 milestone

2026-09-13 08:16:18 +00:00

tiagoagueda added the

enhancement

tier/4

interface

labels

2026-09-13 08:16:18 +00:00

tiagoagueda referenced this issue from a commit

2026-09-15 12:35:31 +00:00

Let Your details, Settings and Server settings use the whole screen

tiagoagueda closed this issue