Back to the CV

Essay

 · 

2025

Why our editor stopped jumping

Every time you typed a long line item, the row grew, the total moved and your cursor went with it. What we measured and the rule that stopped it.

For three years, typing a long line item into a Ledgerline invoice made the page jump. The row grew, the total underneath slid down, and your cursor went with it. Everyone knew. Support had a saved reply. Studios typed their invoices in a notes app and pasted them in, which is a strange thing to ask of people who are trying to get paid.

This is how we found out why it happened, and the rule that stopped it coming back.

It wasn’t one bug

We assumed one culprit and found four. The description field grew a line at a time, pushing everything below it down. The amount reformatted as you typed, so £1,000 came out wider than £999 and the column shifted left. The total recalculated on every keystroke and changed width with it. And on slow connections our web font arrived late and reflowed the whole table, usually just as someone started typing.

Each one was small. Together they made the editor feel like it was flinching.

Measure the thing people feel

Page speed scores didn’t help, because they stop measuring once the page has loaded and our problem started after that. So we measured layout shift while typing: every movement of anything on screen while the cursor was in a field. The worst invoices scored 0.31. We wanted zero, and we put that number on the wall, which in a remote team means a pinned message nobody can unpin.

What fixed it

Numbers got tabular figures, so every digit is the same width and a total can grow without moving. The amount column got a fixed width, sized for the largest invoice anyone had ever sent us plus a bit for optimism. Formatting waits until you leave the field instead of happening under your fingers. Descriptions still grow, but the total now lives in its own row that never reflows, and the font loads with a matched fallback so the swap is invisible.

None of this is clever. The hard part was agreeing that the editor should never move anything you are looking at.

The rule

Nothing above your cursor moves. That is the whole rule. We wrote a test that types a long invoice into the editor and fails the build if anything on screen shifts. It has failed twice since, both times for a good reason, and both times it was right.

The saved reply in support has been archived. I asked if we could frame it.

Create a free website with Framer, the website builder loved by startups, designers and agencies.