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

The /apps page fits a 390 px phone: no sideways scroll, long app names and their actions wrap #9396

Merged opened this

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

Merged

The /apps page now fits a 390 px phone: long names and descriptions wrap inside the page instead of pushing it sideways.

shipped production is serving it deploy b2c98db

opened this

The /apps page now fits a 390 px phone: long names and descriptions wrap inside the page instead of pushing it sideways.

What changed

  • src/web/pages/apps.ts: the page body sits in a <div data-apps-page>, and the app list is a list setting-list, the same wrapping row list the milestones page uses. /apps previously drew a plain list.
  • src/web/style/content.ts: the existing overflow-wrap: anywhere rule now covers [data-apps-page]. I did not reuse [data-apps], because the forges and family pages already use that attribute for something else. The new rule is scoped to this page, so no shared rule changed.
  • test/apps-fit.test.ts seeds 25 apps. One has a 60-character name, three have a 250-character unbroken description, and the rest have long descriptions. It asserts:

- no inline width, and no shipped rule fixing a width over 390 px; - the wrap rule on [data-apps-page] and on .setting-list .row-title; - the list uses setting-list.

What I ran

  • The new test fails without the src/ change (2 of 3 static cases fail) and passes with it.
  • bun x tsc --noEmit, bun scripts/design-lint.ts and the neighbouring tests (milestones-fit, issues-fit, apps-archived, home-walk, hotkey-hints, asked-tab-count) pass.
  • scripts/gate.ts isn't in this clone, so I didn't run it.

Chromium case: it is written to load /apps at 390x844, assert scrollWidth <= innerWidth, and log the numbers. No Chromium starts in this sandbox, so it was skipped here and is unmeasured by me. The forge's check will run it and print the line starting apps 390x844:.

Left out: I did not touch the shelf row component or the New app form, since the issue names only the list page.

🤖 Generated with Claude Code

Closes #9371

commented

The /apps page now fits a 390 px phone: long names and descriptions wrap inside the page instead of pushing it sideways.

What changed

  • src/web/pages/apps.ts: the page body sits in a <div data-apps-page>, and the app list is a list setting-list, the same wrapping row list the milestones page uses. /apps previously drew a plain list.
  • src/web/style/content.ts: the existing overflow-wrap: anywhere rule now covers [data-apps-page]. I did not reuse [data-apps], because the forges and family pages already use that attribute for something else. The new rule is scoped to this page, so no shared rule changed.
  • test/apps-fit.test.ts seeds 25 apps. One has a 60-character name, three have a 250-character unbroken description, and the rest have long descriptions. It asserts:

- no inline width, and no shipped rule fixing a width over 390 px; - the wrap rule on [data-apps-page] and on .setting-list .row-title; - the list uses setting-list.

What I ran

  • The new test fails without the src/ change (2 of 3 static cases fail) and passes with it.
  • bun x tsc --noEmit, bun scripts/design-lint.ts and the neighbouring tests (milestones-fit, issues-fit, apps-archived, home-walk, hotkey-hints, asked-tab-count) pass.
  • scripts/gate.ts isn't in this clone, so I didn't run it.

Chromium case: it is written to load /apps at 390x844, assert scrollWidth <= innerWidth, and log the numbers. No Chromium starts in this sandbox, so it was skipped here and is unmeasured by me. The forge's check will run it and print the line starting apps 390x844:.

Left out: I did not touch the shelf row component or the New app form, since the issue names only the list page.

🤖 Generated with Claude Code

commented

The check failed because no commit on the pull had a "Try:" line, which the gate requires for changes to src/web/pages/apps.ts and src/web/style/content.ts. I added an empty commit carrying one and pushed it. I haven't run the gate or the check again myself, so the new push is untested.

The line reads: Try: open /apps on the preview at a 390 px width, with long app names; nothing scrolls sideways.

No code changed, so the /apps fix, the new test/apps-fit.test.ts and my earlier test results stand as described in the pull.

🤖 Generated with Claude Code

commented

I merged main into the branch and pushed it. The only conflict was the overflow-wrap: anywhere rule in src/web/style/content.ts.

I kept both sides in one rule: [data-apps], [data-apps-page], [data-bet-card], [data-milestone], [data-now]. [data-apps-page] is mine and [data-now] came from main.

bun x tsc --noEmit is clean and 16 tests pass across apps-fit, milestones-fit and apps-archived. I didn't run the gate or the rest of the suite here. The merge commit carries a Try: line (open /apps on the preview at 390 px with long app names).

🤖 Generated with Claude Code

Approved

Small, single-purpose, and it matches the milestones pattern: the page is scoped with data-apps-page, the wrap rule is extended rather than shared rules changed, and the list uses setting-list, which wraps row titles, meta and trailing actions. No new dependency, no JS, nothing for the terminal (layout only). The preview /apps serves data-apps-page with no apps seeded, so I could not see rows there. The wrap CSS is in the shipped stylesheet. Two things I would do next: 1) have the Chromium case run on a machine with Chromium and paste its apps 390x844 line into the pull, since it is still unmeasured; 2) give listCard a setting-list option instead of hand-building card(ul) in apps.ts, so the page keeps using the named component.

commented

Left #9371 open: 1 unticked item remain (Like test/milestones-fit.test.ts, a Chromium-measured case (skipped where no Chromium) loads the page at 390x844 and asserts scrollWidth <= innerWidth; the pull says in one line what it printed.).

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs