← All posts
Deep dive

The 21-pixel email field: how small CSS bugs kill mobile conversion

·7 min read

This week our mobile signup email field rendered 21 pixels tall. It should have been 52. On the single most important input on the marketing site — the one gate between a visitor and an account — the field had quietly collapsed to a third of its size on every phone-width viewport. Desktop was flawless. Nobody on the team saw it in review, because at desktop widths there was nothing to see.

The cause was one property doing exactly what it was told. The fix took a minute. Finding it was the whole problem — and it hid so well because this bug isn't a one-off. It's a category: the small responsive-CSS interactions that pass every desktop review and only exist between 285 and 480 pixels wide.

What actually happened

The form was a flex row on desktop: an email input and a submit button side by side. The input carried flex: 1 to stretch and fill the space next to a fixed-width button. Standard, correct, boring.

.signup-form {
  display: flex;
  flex-direction: row;
  gap: 12px;
}
.signup-form input {
  flex: 1; /* fill the remaining horizontal space */
}

At the mobile breakpoint, a media query stacked the two controls vertically:

@media (max-width: 480px) {
  .signup-form { flex-direction: column; }
}

That one line is the bug. flex: 1 is shorthand for flex-grow: 1; flex-shrink: 1; flex-basis: 0%. In a row, "grow along the main axis" means grow horizontally — the width. Flip flex-direction to column and the main axis rotates ninety degrees. Now flex-grow governs height, and flex-basis: 0% sets the starting main size to zero. The input's height stopped being "however tall a text field is" and became "whatever the flex algorithm distributes" — which, with a zero basis and nothing else growing, collapsed to the input's minimum content height. Twenty-one pixels, no more.

The field still worked. You could tap it, type in it, submit it. It just looked broken and hit like a 21px target on a surface where Google's guidance puts the minimum comfortable tap target at 48×48 CSS pixels — well below that, on the single most conversion-critical control the site has.

Why it sailed through review

Three reasons, and every one of them generalizes.

Desktop review is width-blind by construction. The person approving the change looked at the form on a laptop. The media query that breaks it never fired. There was nothing wrong to notice, because the wrongness is a function of viewport, and the viewport in the room was 1440px. Humans review at the width of the machine they're holding.

DevTools spot-checks aren't systematic. "I'll just toggle the device toolbar" is not coverage. You check the two or three widths you think to check, on the two or three pages you're actively editing, and you move on. The 21px field lived at phone widths on a page nobody had open in responsive mode that day. Manual emulation catches the bug you go looking for; it stays silent about the one you don't. We wrote more about where mobile emulation helps and where it lies — the short version is that a resized viewport is a strong proxy for layout and a weak one for whether anyone actually looked.

Functional tests wouldn't flinch. A test that fills the email, fills the password, and clicks submit passes against a 21px field exactly as it passes against a 52px one. The DOM is correct, the accessible name is correct, the form submits. Nothing in the functional contract encodes "and the input is tall enough to see." This is the seam between functional and visual verification: functional tests assert the app works, and this one did. It just looked broken doing it.

The trap catalogue

Once you know the shape, you see the whole family — the responsive-CSS interactions that pass desktop review and only manifest in the 285–480px band:

Every one is invisible at desktop width, and every one lives on the surfaces that convert: signup, checkout, the field a first-time visitor has to clear.

How to actually catch this class

You don't fix a category with one more careful reviewer. You fix it with three layers that each cover what the others miss.

Run the suite across real viewport configurations, not one. The functional flow you already have — land, fill, submit — gets far more valuable when it runs at mobile-portrait widths as well as desktop: the same flow that proves the form submits also proves it renders where most of your traffic lives. Tier it so the wide matrix only hits flows where responsive behavior is the point. Signup and checkout earn the full sweep; a static docs page does not.

Add visual baselines on the conversion-critical surfaces at mobile widths. This is the layer that would have caught the 21px field outright. A visual snapshot of the signup form at 375px captures the rendered pixels, so a field that collapses from 52px to 21px is a diff, not a silent pass. With the Visual plugin enabled, a generated test can call page.visual.matchSnapshot({ name: 'signup-mobile' }); the first run stores a baseline in the Asset Library, and a later regression fails the scenario and attaches expected, actual, and diff images. Mask the parts that legitimately change — a rotating testimonial, a timestamp — with page.visual.ignoreRegion({ selector }). These are the highest-stakes forms you own, so they're where a pixel baseline pays for itself; the case for testing forms as the flows that carry your revenue applies doubly at mobile widths.

Let production telemetry tell you about the traffic you never exercised. No test matrix covers every path real users take. Production telemetry captures the errors your live app throws, with the context around each one, and surfaces them next to your test results — the backstop for the failure that only fires under real usage. Be honest about its limits, though: a silent visual collapse like the 21px field won't throw an error, which is exactly why the pixel baseline above is the real catch. Telemetry earns its keep on the failures that do fire — the exception that only trips when a real request pattern you never wrote a test for hits your server shows up where your test results already live, instead of in a support ticket a week later.

The point

Mobile conversion still trails desktop even after a decade of mobile-first design, and part of what remains is exactly this: small rendering failures on the exact controls that convert, invisible to everyone reviewing at desktop width. A 21px email field doesn't throw an error and doesn't fail a functional test. It just quietly costs you the signups of every user who looked at it, shrugged, and left.

Layout is a behavior. Test it like one — across widths, with a pixel baseline on the surfaces that matter, and with production telemetry catching what fires on the devices you can't reach.

Want your signup and checkout flows checked across real mobile viewports, with visual baselines that fail on a collapsed field instead of shrugging at it? Get early access, or read how visual and functional testing divide the work.

Early access

Ready for tests that write themselves?

Get early access Read the docs