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

A phone shows one whole column, not one and a sliver: a width breakpoint, snap, and a header that stays #95

open not picked up yet opened this
opened this

On a phone the board should rest on a whole column, not on one column and a sliver of the next.

What it is like today. The stylesheet in src/pages/board.ts has exactly two media queries and both are prefers-color-scheme — there is no width breakpoint anywhere in the app. .board is display: flex; overflow-x: auto, .column is a fixed width: 16rem; flex: none, and body has padding: 1rem 1.5rem. On a 390px phone that is one 256px column, a 16px gap, and about 100px of the next one, with nothing to snap to: every swipe leaves the board parked between two columns. Scroll down a column with a dozen cards and its name, its count and its controls are off the top of the screen, so you cannot tell which column you are dropping into. The app is keyboard-first and touch-draggable (#21) and it has never been told how wide a phone is.

Done looks like

  • [ ] One narrow breakpoint (@media (max-width: 40rem)): a column takes the content width with a small peek of the next, so it is obvious the board continues, and the horizontal gutter shrinks so a snapped column is not clipped.
  • [ ] The board snaps: scroll-snap-type: x proximity on .board, scroll-snap-align: start on .column and .new-column, and scroll-padding-inline-start matching the gutter. Proximity, not mandatory, so a wide drag and keyboard focus are not fought by the scroller.
  • [ ] A column's header stays put while you read its cards at phone width: position: sticky; top: 0, over an opaque backdrop (canvas, not the translucent #8881, which lets cards show through), with no layout shift at first paint.
  • [ ] Above the breakpoint nothing changes — same widths, same behaviour, checked against a desktop picture.
  • [ ] Moving a card with the arrow keys at phone width scrolls the card back into view (scrollIntoView({ block: "nearest", inline: "nearest" }) in static/board.js where the move already lands focus), so a keyboard move never leaves the focused card off-screen.
  • [ ] A test in src/pages/board.test.ts asserts the page ships the breakpoint and the snap rules (the stylesheet is rendered into the page, so it is assertable the way the rest of this page is tested), and the pull carries a picture at 390px wide: three columns, one of them scrolled past its first cards.

Files

src/pages/board.ts (the styles block only), static/board.<hash>.js plus its content-hashed name and the BOARD_JS constant if the scrollIntoView line lands, src/pages/board.test.ts.

Risks

  • Sticky headers over a translucent column are exactly where this looks wrong; check light and dark, and check a card dragged under the header.
  • scroll-snap-type: mandatory would trap a drag that crosses columns — proximity is the deliberate choice, not a weaker one.
  • #25 edits the same styles block at the same phone width, so this waits for it. If #25 is closed as already built (its own comment reads that way), this is ready immediately.

Waits for #25.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs