Research: Mobile-Responsive UI

Feature: 006-mobile-responsive-ui
Date: 2026-04-10

Decision: Use position: sticky; top: 0 on .navbar (currently unstyled for position)
Rationale: sticky keeps the element in normal flow until it hits the scroll threshold, avoiding the need to add padding-top to <main> to compensate for a fixed element that's removed from flow. Simpler with fewer side effects.
Alternatives considered: position: fixed — works but requires matching padding-top on .main-content to prevent content from hiding under the navbar. More coupled.

Decision: Horizontal scroll on .navbar-links using overflow-x: auto; white-space: nowrap; -webkit-overflow-scrolling: touch
Rationale: User explicitly requested horizontal scroll ("button on the right need horizontal scroll to be accessed"). This is the simplest implementation — one CSS rule. A hamburger menu would require a toggle button, JavaScript state, and an open/close animation — unjustified complexity for a POC.
Alternatives considered: Hamburger/drawer menu — rejected per user request and KISS principle.

Decision 3: Book Reader Layout on Mobile

Decision: Stack reader and chat panels vertically on mobile (≤ 768px) using flex-direction: column on .chat-reader-split, remove fixed width on .reader-panel
Rationale: The current layout in BookReaderView.vue uses a flex row with .reader-panel at a fixed 420px. On a 375px screen this immediately overflows. Stacking vertically is the simplest fix — one media query, two CSS rules.
Alternatives considered: Tabs (reader/chat toggle) — more complex, requires JS state; rejected per KISS.

Decision: On ≤ 768px, change .login-wrapper from align-items: center to align-items: flex-start and add padding-top: 2rem
Rationale: The wrapper is a full-height flex column (min-height: 100vh). Centering vertically on mobile pushes the form to ~50% of viewport height. Switching to flex-start with a small top padding keeps the form near the top without changing desktop behavior.
Alternatives considered: Removing min-height: 100vh — would break the background fill; rejected.

Decision: Single breakpoint at max-width: 768px
Rationale: Covers all common phone widths (320px–430px) while leaving tablet/desktop untouched. Consistent with common mobile-first conventions. Adding a second breakpoint (e.g., 480px) would be premature for a POC.
Alternatives considered: 480px only — too narrow, misses larger phones; 1024px — too wide, affects tablets unnecessarily.