One window width proves nothing

What went wrong

We fixed the same headline bug three times. Each time we reported it fixed. Each time it was still there on the screen of the person who had reported it.

The reason was not the fix. It was the measurement. Every check had been run in a window 1440 pixels wide, and that turned out to be the single width where the layout happened to be correct.

Why 1440 is a bad default

1440 is a design tool habit. It is the artboard width people reach for, so it is the width that gets checked. It is not the width people actually browse on. We work on a MacBook, which means 1512 or 1728. Neither of those was ever measured.

A layout bug that depends on width will hide from you if you only ever look at one width. It will not hide from the person using the site.

The rule

Measure across at least four window widths before calling anything fixed. We use 1280, 1440, 1512, 1728 and 1920 on desktop plus 390 on mobile. Measure every state at every width, not only the one you were working on.

Two things that cannot share an element

The same session produced a second rule. A width-fitting script and a per-letter split cannot sit on the same element. The split wraps every letter in its own div. After that the element width no longer follows the font size, so the fitting loop never converges on a value.

We removed the split. The letter reveal on those two lines is gone for now. If it comes back it will animate the line as a whole.

What to do

Write the measuring loop once and keep it. Ours drives the browser through every width and every state, then prints only the deviations. A full run costs two minutes. Reporting a fix that is not a fix costs a great deal more, and it costs it twice, because the next report is trusted less.