Last time we fixed the phone. This time it is the iPad.
It looks fine on a desktop. The phone is sorted. So what about the sizes in between? Opening the site on one, nothing was broken — but there was nowhere for the eye to land.
We were switching in “steps”
First, we turned what was happening into numbers. At seven widths we measured headings, body text, spacing and icons, one by one.
This is what came out:
iPhone iPad(P) iPad(L) PC
body text 13px 13px 16px 16px
section heading 22px 26px 34px 34px
section padding 52px 60px 88px 88px
Sizes were changing in steps. iPhone and iPad portrait were the same; iPad landscape and PC were the same. Any width in between got pushed to one side or the other.
Worse, there were nine different widths at which something switched: 560, 600, 700, 768, 860, 900, 1024, 1200… Type switched at one, spacing at another. On an intermediate size like the iPad, you got big text with narrow spacing — the combinations never lined up.
That was the “somehow it looks wrong”.
Change smoothly instead
The fix is to stop stepping and use one formula that scales with the screen width. CSS has clamp(), which lets you write “minimum, a value tied to the width, maximum” in a single line.
--fs-h2: clamp(24px, 1rem + 1.7vw, 38px);
With that, from a 375px iPhone SE up to a 1600px desktop, each size differs from its neighbour by only a few pixels.
iPhone iPad(P) iPad(L) PC
section heading 22px 28px 31px 38px
section padding 60px 73px 81px 96px
Re-measured, the same table now has no steps.
The iPad is a two-column screen
Evening out the numbers was not enough. In the 768–1100px band, the layout itself was wrong.
Set it as a single phone column and the iPad gets far too tall — the hero illustration slides down off the first screen, leaving only a heading in view. Set it as the desktop’s three or four columns and each card is too thin, the text cramped.
For that band alone, we made two columns the default.
- Hero: heading and illustration side by side
- The four “problems” cards: 4 across → 2×2
- “Our way”: heading on top, items in two columns
- Footer: 4 columns → 2
The 2×2 for the problems cards ended up applying on desktop as well. At four across, each card was only 257px wide, and a short line like “No word on how the site is going” was breaking into three or four lines. Two across, and it fits on one. Fitting on one line matters more than lining four up in a row.
There was no contrast
Laying the numbers side by side revealed one more thing. The difference between headings and body text was small.
The main headline was 56px, the lead paragraph 18.5px, the little English labels (PROBLEMS and so on) 14.5px. Everything was “medium”. There was no lead actor.
We committed to the difference.
| Before | After | |
|---|---|---|
| Main headline | 56px | 68px |
| Lead paragraph | 18.5px | 16px |
| PROBLEMS-style labels | 14.5px | 12px |
| Tags and captions | 14.5px | 12px |
The lead is big. The supporting cast is deliberately small. What can afford to be small should be small. Put another way: by trying to make everything “big enough not to be a problem”, we had made everything the same size.
Japanese breaks mid-word
The last one. It took the most work.
Headings are written with their line breaks decided in advance: “退去した部屋を、/次に貸せる状態まで” (a vacated room, / to the point where it can be let again). But the browser will break wherever it likes, even in the middle of that. On iPad landscape it became “次に貸せる/状態まで”. On desktop, the seven-character heading “私たちのやり方” (Our way) split as “私たちの/やり方”. A seven-character heading on two lines is hard to look at.
The cause is the same as last time: word-break: auto-phrase, which breaks Japanese at phrase boundaries, is not supported by Safari. iPhone and iPad are both Safari, so on Apple devices it does nothing.
In English there are spaces between words, so the browser can break there. Japanese has no spaces. To a browser it is a string that can be broken anywhere.
Make each phrase a solid block
CSS alone could not stop it, so we changed how the headings are written.
Each phrase of a heading is wrapped in a marker that says “never break inside this.” “退去した部屋を、” is one block; “次に貸せる状態まで” is another. Breaks can only happen between blocks.
Where there is room, the heading breaks where the author decided. On a screen too narrow to fit even a single block, the marker is released and the text wraps normally. Nothing overflows.
For the short single sentences — the four problems cards, the “Our way” items — we used a different rule: word-break: keep-all, which breaks only at punctuation. “報告が/来ない” and “連絡が来/ない” are gone; you get “現場がどうなっているか、/報告が来ない” instead.
What we could not fix
Article card titles we left alone. Long free-form text like “Why a small company chose Supabase — what was good, and what we are careful about” has no perfect way to break at every width.
Apply keep-all and one word becomes too long to fit, so it now snaps as “理/由” (rea/son) — worse than before. For long free-form text, ordinary wrapping is the right answer. We kept the rule that a line may not begin with “、”, and otherwise left it to the browser.
Do not try to control everything. That is one of today’s lessons too.
What we checked
Last time we said that “look at every width” would go into the pre-launch routine. This time we added checking the line breaks.
For headings and card text, we pull out exactly where each line breaks, and lay them out at five widths.
Problems (iPhone)
現場がどうなっているか、/報告が来ない
工事が始まってから、/追加費用の話が出てくる
予定が押しているのに、連絡が来ない
入居者が外国籍で、/説明がうまく伝わらない
Lined up like this, a break like “来/ない” jumps out. Far more reliable than trying to spot it by eye.
What we learned
Last time it was “the person who builds it only ever looks at their own desktop.” This is the sequel.
Once you have fixed the phone, look at what lies between. Both ends being right does not make the middle right. The nine breakpoints were things we had added one at a time while fixing the phone and the desktop separately.
And decide sizes by proportion, not by steps. Decide by steps, and there will always be a hole at the boundary.
There will still be places we have not noticed. We will look at it on a real iPad, and fix those too.
In this series
- The phone was the only way in
- Building it alongside an AI
- Cut, cut, and cut again
- What is still unfinished
- On a phone, it was a mess
- For two and a half years, the internet thought we were in Shibuya
- On an iPad, this time it was the “steps” (this post)
