---
title: "Why a 320 by 90 Button Needed an Invisible Two Pixel Border"
canonical: https://dxdev.com/everyday-ai/button-that-moved-four-pixels/
datePublished: 2026-04-27
---
The button shifted sideways when it was clicked.

We had already been through a round of fixes on the checkout page. A senior developer had sent back four notes. The little plus and minus controls were not stepping the way they should. The bar pinned to the bottom of the page did not line up with the rest of the page. Some event cards did not take people where the rest of the site taught them to expect. A price button used the wrong font.

None of those problems was dramatic. Nobody had lost money. The checkout did not crash. But a checkout page asks people to trust it at the exact moment they are deciding whether to hand over their card. A crooked frame on a front door does not stop the door from opening, but it does make you wonder what else was put together in a hurry.

We fixed the notes and called the page done.

That was the first thing that went wrong. The page looked fine after the obvious repairs, so we treated it as finished. It cost us another round of review and another person's patience. Someone had to click the button, notice the movement, and say, in effect, "This is still not right."

The movement was four pixels. A pixel is one of the tiny dots that make up what you see on a screen. Four is not many. Yet the [button grew on its right side](/blog/last-2-pixels/) when someone pressed it, and the words inside could wrap differently, which made the button's height jump. It looked like a small shrug.

A still screenshot hides that. The button at rest looked normal. The button after a click looked normal. The trouble lived in the trip between the two.

The cause was a border. The resting button had no border. The clicked button added a border two pixels thick on each side, and the page counted that border as extra room, so the button became four pixels wider. The text also had enough room to change its wrapping, so the button could get taller too.

The fix involved one technical term, `box-sizing`. It is a setting that tells the page whether a border counts inside the size you gave a button or gets added on outside. We set it so the border stayed inside. We also gave the button an invisible two-pixel border in its normal state, so it was already holding the room it would need when clicked. A minimum width of 320 pixels kept the label on one line. The result was a button that stayed exactly 320 by 90, whether it was sitting there or being pressed.

That came to five small lines of styling instructions: the `box-sizing` setting, the invisible two-pixel border reserved in the resting state, and the minimum width so the label could not rewrap. The hard part was not writing them. The hard part was noticing they were needed, and none of them get written by looking at the button. They get written by clicking it in a real browser and watching the half second between the two states.

## What the AI missed

We keep coming back to this because of how we work with AI. The machine got the page most of the way there quickly, and it made something that looked believable at first glance. That is useful, but it means believable cannot be treated as finished.

The AI produced a plausible answer and missed the part that only appeared when a person used the page. A person in a real browser switched the button from one state to the other and saw the change.

The same pattern shows up far from a checkout page. A form can look tidy until someone uses a long last name. A phone menu can look fine until a tired person tries it with one thumb. An automated email can read perfectly until it lands after the event it was supposed to remind someone about.

Before a page that handles payment is called finished, find out who has used it in a real browser and watched what happens between states, not only at rest.