Boloop-made explanatory illustration: content that overflows a narrow header and a layout that fits its available width.
At a viewport width of 719px, Boloop’s header stretched the page to 818px. The language button’s right edge was outside the screen, while the button for opening the mobile navigation had not appeared.
The site did not need a redesign. We needed to establish when the navigation stopped fitting, whether the popup obeyed its intended alignment, and whether the original theme and keyboard behavior still worked after the repair.
Choose the breakpoint from the content that has to fit
The old layout did not collapse the desktop navigation until 650px. Its contents, however, stopped fitting at a wider viewport. The 719px case fell into the gap: the desktop navigation was already unsuitable, but the collapsing rule had not started.
We changed the shared navigation to collapse at 1050px and below, with the full navigation appearing above that width. That value came from Boloop’s current header content and layout; it is not a universal tablet breakpoint.
Collapsing the header also cannot mean removing its useful actions. Home, search, language switching, theme switching, and keyboard access needed to stay available. The separate 650px styles for small-screen body content remained in place. Limiting the change to the shared header kept the repair focused on the actual failure.
A closed menu can fit while its popup overflows
After the navigation adjustment, the language popup exposed another problem. The component rendered select-menu-end, but the CSS targeted select-menu-align-end. An end-alignment rule appeared to exist, yet it matched none of the relevant rendered nodes.
Before that fix, the popup’s right edge reached 411px in a 390px viewport and 722px in a 719px viewport. A navigation container that no longer overflows cannot prove that its popup also stays in bounds.
The old regression checked only whether a particular string existed in the stylesheet, so it still passed. The revised check targeted the rendered listbox and the selector that actually matched it. We then opened the page and measured the popup’s real boundaries.
It is a small distinction worth keeping: having CSS in a test does not establish that anything on the page uses it.
A dark default still needs to respect a saved light theme
In the same round, Boloop set dark as the first-visit default while preserving a reader’s saved light or dark preference.
The theme bootstrap in the HTML head and React’s initialization had to agree. Different defaults could make the page render in one theme and switch after loading. Writing a default back to storage too early could also overwrite an existing light preference.
We aligned the initial server and client markup, then read and persisted preferences once initialization was ready. The theme button remained usable when browser storage was denied. Checking the default also required a fresh origin without a saved preference. Continuing to show light in a browser where the reader had already chosen light was the correct behavior.
Acceptance means more than shrinking a window once
Local checks covered English, Simplified Chinese, and Traditional Chinese; the home page, article directory, and an original guide; and light and dark themes at 390, 719, 1024, and 1440px. Together, these made 72 layout combinations. We also checked widths around the breakpoint—collapsed at 1050px, expanded at 1051px—and narrower entry points.
The actual interactions included opening navigation, visiting the article directory, closing menus with Escape, opening the language list with the keyboard, switching language, and checking theme retention and focus recovery. Visible header controls were also checked for targets of at least 44×44px. Static screenshots alone would have missed most of these states.
After publication was authorized, the production site received another set of three-language layout, popup, and theme-persistence checks. The October 21, 2026 release passed 918 release tests. The live checks found no header overflow or browser console errors in the observed cases. Their scope was the shared header across these page families, not every page on every physical device.
Measure other squeezed layouts in the same way
An earlier article-directory issue looked like another responsive failure: the metrics area had flex-basis: 100%, but its card was a horizontal flex container that did not wrap. The text container ended up squeezed to 0px.
That repair returned the typographic article card to normal block flow and placed the metrics after the text. It did not require deleting the metrics or successively reducing title sizes.
These two experiences gave me three measurements to take before editing styles: the viewport width, the container’s actual width, and the first child that crosses its boundary. Once the rule allocating that space is clear, the repair is usually more focused than rearranging the whole page—and easier to make without disturbing existing animation, text selection, or content hierarchy.