Blog

The details nobody notices, and the one minute they do

The best detail work is invisible when it is right and quietly infuriating when it is wrong.

Published

Someone in accounts is filling in a government form. One field wants a supplier's tax identification number. She opens the supplier's website in another tab, drags across the number, copies, comes back, pastes.

Red text. Invalid format.

What she pasted was 0-1055-61086-66-8, hyphens and all. What the form wanted was thirteen unbroken digits. She deletes the hyphens by hand, loses twenty seconds, and is annoyed at a level not quite worth complaining about to anyone.

Those twenty seconds are the subject of this piece.

Format with CSS, keep the value in the text

On this site the company registration number displays as 0-1055-61086-66-8, because reading thirteen unbroken digits off a screen to check them against a certificate is something human eyes are genuinely bad at. Grouped, you can verify it a chunk at a time.

But those hyphens are not characters. They are generated content, produced by CSS ::before and marked user-select: none. The digits live in real text nodes; the separators live in the presentation. Select the number, copy it, and what lands on the clipboard is 0105561086668 — nothing else.

The reason is not tidiness. It is an acknowledgement of who is copying it. Essentially everybody who selects that number is about to paste it into a government or accounting form, and those forms reject punctuation.

The general rule: format for the eye with CSS, keep the usable value in the text. It applies to phone numbers, tax IDs, bank account numbers, order references — anything a person will carry somewhere else.

And if the value coming in is not thirteen digits, it is rendered exactly as it arrived, ungrouped. A mistyped value should look wrong rather than be quietly dressed up until nobody catches it.

Context that survives the click

Someone reads a case study to the end and clicks through to talk to us. If the form they land on is an empty box, they have to begin by re-explaining which page they just came from — something the system already knows.

So a link from a work or service page into the contact form carries a reference with it. The form uses it twice: to pre-fill an opening line so nobody starts at a blank field, and to record the reference on the submission so whoever picks it up knows what the conversation is about.

The care is needed because that value arrives in a URL.

Anything that comes in through a query string and is then rendered back onto the page is a classic injection surface. Whoever forwards the link can put whatever they like in it. So the value is not trusted: it is tested against a strict pattern first, then looked up in our own content. The label shown on screen comes from our database, never from the link.

If the lookup finds nothing — a stale link to a post that has been unpublished, or somebody probing with a made-up path — nothing happens beyond the plain form appearing. No error, and nothing from the URL echoed back onto the page.

Announcing things once

The logo exists in two colourways, one for light backgrounds and one for dark. The most direct approach is to render both and let CSS show the right one. Visually this is correct in every respect.

To a screen reader, though, hidden by CSS does not mean absent. Left alone, a blind visitor hears the company name announced twice in a row on every page load. Not a serious failure — just a small irritation that accumulates all day.

So the hidden copy carries aria-hidden and an empty alt. It disappears from the accessibility tree entirely, and the name is announced once.

Duplicating markup for theming is a common and perfectly reasonable technique. The failure is forgetting there is an audience that is not looking at the page at all.

Content that cannot break the layout

Some of this site's content comes out of a CMS, which means the people writing it are not thinking about the grid or the column width. They are thinking about what they need to say, and one day they will paste in a table with seven columns.

A table wider than its column, left to itself, widens the page. The whole document gets a horizontal scrollbar, every heading drifts sideways with it, and on a phone the result is unreadable.

So every table coming out of the CMS is wrapped in a box that scrolls on its own. The table can be as wide as it likes; it scrolls inside its frame instead of dragging the page along with it.

The principle is that the system absorbs unpredictable content, rather than asking authors to be careful on its behalf. Agreements of that second kind are always forgotten within three months.

The same family of problem, everywhere

Once the pattern is familiar, it turns up constantly.

The card number field that rejects a paste because it contains spaces every four digits — spaces the user did not type, which came from wherever the number was displayed nicely. Stripping them is one line of code. Requiring the user to do it is pushing work onto the person about to hand you money.

The copy button that copies a formatted string. People press it precisely because they trust it to hand back something usable. A button that returns a value needing further cleanup is worse than no button, because it invites the trust before failing it.

The form that discards everything typed when validation fails. Twelve fields filled, one wrong, submit, and back comes an empty page with a message about invalid input. That is where people close the tab, and no metric will ever explain why.

The through-line

None of this appears in a design review. None of it is visible in a screenshot. None of it is what a client praises on first seeing the work.

It appears in the one minute somebody is trying to get something done — the accountant closing a month, the reader who clicked through after finishing an article, the screen reader user opening their twentieth page of the day.

In that minute, the work done well is not noticed at all. That is what success looks like here.

If you would like to talk about your own work, get in touch.

About the author

Portrait of Film

Film — Wisit. A businessman who still does his own BA work more often than he probably should, and writes a fair bit of code, front and back. Runs two or three small businesses. Follows technology and business obsessively, in Thailand and everywhere else. Off the clock: physics, astronomy, DIY, and anything to do with networks. Music always on, though he cannot sing. Plays instruments anyway, badly. Plays a lot of sport, racket sports above all. One flaw: he barely touches video games.

Written with Claude Opus 5