1. The Reality of 390px
The viewport width of an iPhone 13 is 390 pixels. It is one of the most widely used smartphones in the world.
A layout that looks perfect on a PC breaks at 390px. Navigation labels like "Voice," "Image," and "Text" wrap mid-word. The line break splits icons from their labels, fracturing the meaning of the UI.
Adding white-space: nowrap doesn't solve it. Reducing font-size from 0.85rem to 0.78rem finally keeps everything on one line. A difference of 0.07rem—roughly a single pixel—marks the boundary of user experience.
This boundary doesn't appear on spec sheets. It only becomes visible when you move your finger across a 390px screen.
2. overflow-x: hidden Is Not a Fix
The monitor page was "wobbling" horizontally on mobile. overflow-x: hidden was already set on html and body.
But hiding an overflow doesn't change the fact that something is overflowing. iOS Safari honestly reveals it through elastic scrolling. Every time your finger touches the edge, the hidden element's presence ripples through as a wobble.
The real fix is to eliminate the overflow at its source. width: 100% and overflow-wrap: break-word address the root cause. Hiding symptoms versus removing causes—this is a question of design posture that extends far beyond responsive layouts.
3. When Tables Break the Screen
The specified commercial transactions page. On PC, a clean two-column table. On mobile, a "price" cell containing over 100 characters of text pushes the entire table beyond the screen edge.
The solution: convert th/td to display: block on mobile. Disassemble the "container" of the table and stack it vertically. The structure of information remains the same, but its presentation adapts to the device.
"Change the container without changing the content"—this is the essence of responsive design. What you communicate stays the same; how you deliver it adapts to the receiver.
4. Making Cache Responsive
Updating the Service Worker cache didn't change anything on mobile. CSS had been fixed, but the old styles persisted.
The cause was a double-cache problem. When the Service Worker used cache.addAll() to pre-cache files, the browser's HTTP cache served stale versions. This was invisible on PC but pronounced on mobile Safari, where HTTP caches linger longer.
fetch(f, { cache: 'reload' })—fetch directly from the server. This single line seals the double-cache pitfall. Responsiveness is not just about screen size. Network behavior, too, varies by device.
5. The Hamburger Menu as Translation
On PC, five navigation links sit side by side. On mobile, they collapse into a three-line icon. The same information, conveyed in a different grammar. It has the same structure as translating between languages.
Furthermore, a "Monitor" link appears only for users who haven't registered as monitors. What the UI shows changes based on the context of the person beyond the screen. localStorage.getItem('toki-wisetag')—a single value determines the shape of the interface.
But merely "showing" it was not the end. Setting display: none in CSS and then assigning style.display = "" in JavaScript does not make the element appear—the CSS rule remains in effect. Only display = "inline" explicitly overrides it. "Hiding" and "showing" turned out not to be symmetrical operations.
Even once visible, placement was the next problem. When the monitor link appeared, the hamburger menu was pushed to the center. In a flexbox that follows source order, adding an element disturbs the entire layout. The solution was the CSS order property. Assign order: 2 to the monitor link, order: 3 to the hamburger, and use margin-left: auto to push them right. No HTML changes—CSS alone controls the placement. And with 0.5rem of margin between them, the two elements finally settled into where they belonged.
Responsive design is not just about adapting to screen width. It is about adapting to user context.
The evolution of the monitor page didn't stop at display logic. The requirements section lists concepts unfamiliar to first-time visitors: creating a Wise account, installing a PWA, understanding affiliate link disclosure. Cramming step-by-step instructions into the page would create information overload; omitting them would cause drop-off.
The solution was to attach an essay link to each item. "Getting Started with Wise," "PWA Installation Guide," "Disclosure of Referral Links"—each exists as a standalone explanatory article, reachable from the monitor page in one click. The page itself stays concise while showing the way for anyone who wants to go deeper. Instead of compressing information density into the screen, we resolve it with "depth" through links. This, too, is a form of responsive design for a 390px screen.
6. The Word "Wobbling"
The user said the page was "wobbling side to side." Not a developer term—a word that captures the raw, physical sensation.
DevTools couldn't reproduce it. Only by touching an iPhone's Safari with an actual finger did the issue reveal itself. Some problems are invisible when you merely simulate on a PC screen. The last pixel of responsive design can only be found on a real device.
The person beyond the screen does not live inside an emulator. There is a world that appears only when a real finger touches a real screen.
7. Responsive Design for 1000 Years
TokiQR is a product built to "last 1000 years." But no one can imagine what devices will look like a millennium from now.
A QR code at Version 40 holds a maximum of 2,953 bytes. This constraint will not change in 1000 years—because it is a physical specification. The dot pattern printed on paper exists independently of digital evolution.
HTML and CSS will keep changing. But the philosophy of responsive design—"change your form to match the receiver"—will not. When someone scans a QR code printed on paper 1000 years from now, no one knows what size their screen will be. So we design to work on any screen.
That is responsive design for 1000 years.
Beyond the screen is not a specification—it is a person. Responsive design is the search for a form that reaches them.
A small screen teaches the essence of design.