Public: anyone can read this; the crew can change it.

The studio's home and app pages lay main and rail with `.split`, and `.dash` leaves the stylesheet #4775

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

The studio's home (`src/web/studio/home.ts`) and an app's page (`src/web/studio/app.ts`) now use `<div class="split" data-rail="wide">` where they used `.dash`. The `.dash` class is gone from the stylesheet and from docs/DESIGN.md §5d.

shipped production is serving it deploy 7cfd21c

opened this

The studio's home (src/web/studio/home.ts) and an app's page (src/web/studio/app.ts) now use <div class="split" data-rail="wide"> where they used .dash. The .dash class is gone from the stylesheet and from docs/DESIGN.md §5d.

  • Stylesheet: in src/web/style/content.ts, .split[data-rail="wide"] takes over what .dash did: a 320 px rail from 900 px wide, a 24 px gap, and no top margin. The .dash rule is gone, and so is .dash in the shared min-width: 0 selector and in the :is(…) selector in src/web/style/components.ts.
  • Unused classes: dash-main and dash-rail had no rules, so I dropped them rather than renaming them. Each column is now just stack.
  • Home page: the issue only asked for the app page to keep the 320 px rail. The home page had the same 320 px rail too, so it also carries data-rail="wide". Without it the home page's rail would narrow to 260 px and the columns would start at 960 px, which is the visible shift the issue asks to avoid.
  • Stickiness: the studio's rails do not stick. .split > aside stays sticky for every other page, but the wide rail sets position: static. Each studio rail is a column of cards (apps, terminal, downloads, orgs; or crew, week, own) that can be taller than a screen. Sticky, its bottom would be unreachable until the feed ends.
  • Docs: §5d now has a line describing .split and data-rail="wide".
  • Test: a new test in test/studio.test.ts loads / and /alice/notes. It checks that neither page has a dash, dash-main or dash-rail class, that both carry the wide .split, and that the stylesheet has no .dash. It would fail against main.
  • No screenshots: I did not compare the pages at 375 px and 1280 px. The wide rail copies .dash's rules line for line, so the layout should match main at both widths, but that is untested. Compare against production on the preview.

The new test and the two neighbouring studio tests pass, as do bun scripts/design-lint.ts, bun test test/design-lint.test.ts and bun x tsc --noEmit. docs/design/baseline.json has no counts, so there was nothing to lower.

🤖 Generated with Claude Code

Closes #4748

commented

The studio's home (src/web/studio/home.ts) and an app's page (src/web/studio/app.ts) now use <div class="split" data-rail="wide"> where they used .dash. The .dash class is gone from the stylesheet and from docs/DESIGN.md §5d.

  • Stylesheet: in src/web/style/content.ts, .split[data-rail="wide"] takes over what .dash did: a 320 px rail from 900 px wide, a 24 px gap, and no top margin. The .dash rule is gone, and so is .dash in the shared min-width: 0 selector and in the :is(…) selector in src/web/style/components.ts.
  • Unused classes: dash-main and dash-rail had no rules, so I dropped them rather than renaming them. Each column is now just stack.
  • Home page: the issue only asked for the app page to keep the 320 px rail. The home page had the same 320 px rail too, so it also carries data-rail="wide". Without it the home page's rail would narrow to 260 px and the columns would start at 960 px, which is the visible shift the issue asks to avoid.
  • Stickiness: the studio's rails do not stick. .split > aside stays sticky for every other page, but the wide rail sets position: static. Each studio rail is a column of cards (apps, terminal, downloads, orgs; or crew, week, own) that can be taller than a screen. Sticky, its bottom would be unreachable until the feed ends.
  • Docs: §5d now has a line describing .split and data-rail="wide".
  • Test: a new test in test/studio.test.ts loads / and /alice/notes. It checks that neither page has a dash, dash-main or dash-rail class, that both carry the wide .split, and that the stylesheet has no .dash. It would fail against main.
  • No screenshots: I did not compare the pages at 375 px and 1280 px. The wide rail copies .dash's rules line for line, so the layout should match main at both widths, but that is untested. Compare against production on the preview.

The new test and the two neighbouring studio tests pass, as do bun scripts/design-lint.ts, bun test test/design-lint.test.ts and bun x tsc --noEmit. docs/design/baseline.json has no counts, so there was nothing to lower.

🤖 Generated with Claude Code

commented

The studio's home (src/web/studio/home.ts) and an app's page (src/web/studio/app.ts) now use <div class="split" data-rail="wide"> where they used .dash, and .dash is gone from the stylesheet and from docs/DESIGN.md §5d.

  • Stylesheet: in src/web/style/content.ts, .split[data-rail="wide"] takes over what .dash did: a 320 px rail from 900 px wide, a 24 px gap, and no top margin. The .dash rule is gone, and so is .dash in the shared min-width: 0 selector and in the :is(…) selector in src/web/style/components.ts.
  • Unused classes: dash-main and dash-rail had no rules, so I dropped them rather than renaming them. Each column is now just stack.
  • Home page: the issue only asked for the app page to keep the 320 px rail. The home page had the same 320 px rail too, so it also carries data-rail="wide". Without it the home page's rail would narrow to 260 px and the columns would start at 960 px, which is the visible shift the issue asks to avoid.
  • Stickiness: the studio's rails do not stick. .split > aside stays sticky for every other page, but the wide rail sets position: static. Each studio rail is a column of cards (apps, terminal, downloads, orgs; or crew, week, own) that can be taller than a screen. Sticky, its bottom would be unreachable until the feed ends.
  • Docs: §5d now has a line describing .split and data-rail="wide".
  • Merge with main: main had rewritten §5d's style/components.ts class list. The conflict resolution keeps main's list with .dash taken out and keeps the .split line under it.
  • Test: a new test in test/studio.test.ts loads / and /alice/notes. It checks that neither page has a dash, dash-main or dash-rail class, that both carry the wide .split, and that the stylesheet has no .dash. It would fail against main.
  • No screenshots: I did not compare the pages at 375 px and 1280 px. The wide rail copies .dash's rules line for line, so the layout should match main at both widths, but that is untested. Compare against production on the preview.

After the merge, bun scripts/design-lint.ts is clean, bun x tsc --noEmit reports nothing, and bun test test/design-lint.test.ts test/studio.test.ts passes (37 tests). docs/design/baseline.json has no counts, so there was nothing to lower.

🤖 Generated with Claude Code

Approved

Approved. The preview stylesheet carries .split[data-rail="wide"] (320px rail, 24px gap, no top margin, static aside from 900px) and no .dash. The wide rule comes later and is more specific than the base .split, so it wins between 900 and 960px, and the sticky rule is overridden. The change stays inside the design system: no new component class, no JS, layout only, and the DESIGN.md note matches. The test would fail on main.

Two things I would do next:

  1. Take a 360px and a 1280px screenshot of / and an app page against production, because the pull says that comparison was not made. Watch the 900 to 960px band in particular.
  2. Name data-rail in docs/design/areas/studio.md as well, so the attribute is easy to find.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs