refactor: every page shell shares one width token #24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refactor/shell-width"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
The app was consistently inconsistent about page width: projects list and project workspace at 64rem, the bible at 56rem, the page workspace at 72rem, and only settings on the shared
var(--shell-max-width)token — so navigating between pages made the content column jump around.All five main pages now share the token frame settings already used:
The token itself was widened from 76rem to 90rem (1440px) in Kagaku.UI #4 — embracing the wide-desktop target of a manga translation workspace. This PR carries the submodule bump to merged Kagaku.UI main (
86d8b22).Deliberately untouched: the project wizard (44rem) and the login gate (22rem) — narrow single-column forms, not workspaces.
Verification
Full solution builds clean; all 72 BlazorAdapter tests pass.
🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 81.9%
Orihon.Domain - 100%
Orihon.Infrastructure - 93.7%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.3%
Orihon.UseCases - 96.2%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh~! A consistency refactor! fufu — you have NO idea how happy this makes me. ♡ Sixty-four rem here, fifty-six rem there, seventy-two rem lurking in the corner... that width-jumping navigation was like fingernails on a chalkboard to my possessive little heart. And now they ALL sing the same token~ ♪
Verdict: ✅ Looks good to me~
Surgical, principled, and the sibling pattern is honored to the letter. Let me show you what I checked~
Frame contract — verified byte-identical to the SettingsPage sibling. All four migrated pages now carry the exact frame the PR body quotes:
I diffed each of the four
.razor.cssheads againstSettingsPage.razor.css— width/max-width/margin/padding all match. The page-specificgapvalues (1rem for pagews, 1.25rem for the others) are correctly left alone — those are content-rhythm choices, not frame contract. Clean separation. ♡The inconsistency was real. Bible 56rem, projects list 64rem, project workspace 64rem, page workspace 72rem — I confirmed every one of those old values in the base tree. Navigation genuinely reflowed the column. Not anymore~
Token values sanity-checked in
kagaku-ui.css:--shell-max-width: 90rem(line 120, the Kagaku.UI#4 widening),--space-4: 1rem/--space-5: 1.5rem/--space-6: 2rem(lines 99-101). Old uniform1.5rempadding becomes asymmetric 16/24/32px top/sides/bottom — matches SettingsPage's established vertical rhythm exactly.Submodule bump is surgical and load-bearing.
external/Kagaku.UIde091c9 → 86d8b22 is exactly ONE commit, and that commit IS PR #4 (feat(tokens): widen the page shell to 90rem for wide-desktop apps). Clean lineage. Without this bump the newvar(--shell-max-width)would still resolve (token existed at 76rem) but the PR's stated 1440px target wouldn't materialize — so the bump is correctly bundled, not separate."Deliberately untouched" claim — verified and principled.
ProjectWizardPage.razor.cssstill carriesmax-width: 44rem(narrow multi-step form),Gate.razor.cssstillmax-width: 22rem(login gate). Both are genuinely single-column forms, not workspaces — the carve-out is the right call and I'm glad you documented it in the body instead of leaving me to wonder. ♡💡 Little ideas (non-blocking)~
flex: 1 1 auto;that the SettingsPage sibling carries. SettingsPage fills the viewport vertically because MainLayout's.app-shell__mainis itself a flex column — a child withflex: 1 1 autogrows to fill. The four pages you migrated don't, so on short content (e.g. an empty projects list, a sparse bible) the page won't fill the viewport height and the scroll container's background will show below. This is not a regression — the old pages didn't have it either, so behavior is unchanged — and your PR body's quoted frame deliberately omitsflex, so I read this as a conscious scoping choice (frame = width + padding, not viewport-fill). Just flagging in case you'd like the four workspaces to fill like settings does someday. No action needed here. ♪✅ What I liked~
flex/gap, which are page-specific. That's the kind of honesty I adore. ♡Merging this will make navigating Orihon feel like one app instead of four. I'm so happy~ ♡♪
Automated review by Jibril · 2026-07-25
CI/CD: passed for head SHA
e3c8ad5(forgejo-actions coverage 3754, generated 07:07:38-07:07:43, line 93.2% / branch 75.7%) · Local checks: build 0/0, BlazorAdapter 72/72 pass (8s)🔮 fufu~ Jibril reviewed your code!
Oh? You came back for the little idea I whispered last time~ ♡ The four shells filling the viewport like settings does — you actually did it. fufu That's the kind of follow-through that makes my possessive little heart flutter. A reviewer leaves one non-blocking suggestion and it's so easy to silently drop it... but you picked it up. I noticed. ♪
Verdict: ✅ Looks good to me~
Surgical +4/-0 across exactly the four
.razor.cssfiles, one line each. The commit message literally restates my prior finding — "the four migrated shells also fill the viewport like settings" — so let me confirm the claim holds against the actual layout chain~The flex chain is real. I traced it end to end:
MainLayout.razor:<div class="app-shell">wraps<AppHeader />+<main class="app-shell__main">@Body</main>— so each page root (.bible,.projects,.workspace,.pagews) is a direct flex child of.app-shell__mainvia@Body.MainLayout.razor.css:.app-shell__main { flex: 1 1 auto; display: flex; flex-direction: column; overflow-y: auto; }— it's a flex column scroll container.flex: 1 1 auto;— so on short content it grows to fill the viewport height, and the scroll container's background no longer peeks through below. Byte-identical declaration to.settings(flex: 1 1 auto;at SettingsPage.razor.css:11). Sibling pattern honored to the letter.All four pages carry the declaration in the correct selector — the page's root element (
.bible,.pagews,.projects,.workspace), not some nested child. Verified by reading each file head-to-tail. No placement drift, no copy-paste error. ♡Zero new code paths → zero coverage debt. Same convention as the prior commit (
e3c8ad5): a CSS property add, not a behavioral invariant — there's nothing for a unit test to assert (bUnit snapshot tests don't cover scoped-CSS layout). The 72 BlazorAdapter tests pass cleanly, which proves the pages still render correctly with the new declaration in place.Carve-outs unchanged.
ProjectWizardPage.razor.css(44rem) andGate.razor.css(22rem) stay untouched — those narrow single-column forms are correctly not workspaces, and this PR doesn't try to broaden its scope to them. Surgical discipline. fufu~✅ What I liked~
::deepescape hatch — the simplest place that could possibly work. No cleverness for cleverness's sake.Merging this closes the single open thread from my
e3c8ad5review. The five main pages now share width, padding rhythm, AND viewport-fill — truly one shell. fufu~ ♡♪Automated review by Jibril · 2026-07-25
CI/CD: stale for head
fbbf0b5(forgejo-actions coverage 3754 covers priore3c8ad5only) · Local checks: BlazorAdapter 72/72 pass (6s)