Felix

Implementation note that saves a lot of grief: do not clear the error the instant the value becomes technically valid if the field is still focused and the user is mid-edit.

A field can pass through valid states while being edited — deleting the end of an address, for instance — and flickering between error and no-error under the cursor is more distracting than either state alone.

Debounce it, or simply hold the last decision until blur once an error exists. Cheap to implement, and it removes the twitchiness people describe but rarely name.

The practical consideration that usually decides it: cost.

A plain rounded corner is one CSS property, it is what every component library ships, it is what your design tokens already express, and every engineer implements it identically without thinking.

The smoother version needs either a platform that provides it natively, or a clipped path or SVG per component, plus a decision about what happens at every size and every nesting level. That is not enormous, but it is a permanent tax on every new component, and in my experience it gets applied inconsistently within about two months — some things smooth, some things not, which looks worse than either alone.

If your platform gives it to you for free, take it. If it does not, be honest that you are buying a subtle improvement with an ongoing maintenance cost.

It always goes that way. The rule I use now is that any visual property which cannot be expressed as a single token is a property the system will eventually apply unevenly.

There is a middle path that works well on narrow screens if the label genuinely does not fit: show the state instead of the function.

Rather than a bare funnel, show the funnel with the count of active filters, or replace it entirely with the selected filters as chips. "Vegetarian ×" as a visible tag communicates both what the control does and that it is currently doing it, in less space than a label plus an icon.

This also solves the second problem nobody asks about, which is that people forget filters are on and then think your menu is missing items. A visible state is more valuable than a discoverable control here.

There is a version of this that is genuinely good, and it may be what those sites were reaching for: prefetch on hover, navigate on click.

When the pointer lands on a link, start fetching the destination in the background. Do not show anything, do not change the URL, do not commit to anything. If the user then clicks, the page is already there and the navigation feels instantaneous.

You get the entire perceived speed benefit with none of the intent problem, because hover is being used as a prediction rather than a decision. If the prediction is wrong you have wasted a request; if it is right the app feels twice as fast.

This is a well-established technique and it is almost certainly what you want instead.

The default answer is no, and your reason is one of the few that can override it — but the bar is higher than "our search is better".

What makes browser find-in-page valuable is that it is guaranteed. It works the same on every site, it never changes the page, it never sends anything anywhere, and users rely on that consistency without thinking about it. Every override erodes a guarantee that costs nothing to keep and is very expensive to rebuild once broken.

The condition under which overriding is defensible is roughly yours: the browser's behaviour is not merely worse, it is actively misleading. Find-in-page reporting no matches in a virtualised list is not a degraded result, it is a wrong one, and a user who trusts it draws a false conclusion about their data.

That is a real justification. It is also worth exhausting the alternatives before using it.

Bunching is a known and slightly counter-intuitive phenomenon, and it is the same effect that makes buses arrive in threes.

The mechanism is a feedback loop. A lift that falls slightly behind picks up more waiting passengers, which makes it stop more often, which makes it fall further behind. The lift behind it now finds fewer people waiting, so it moves faster and catches up. Left alone, the system converges on clumps rather than an even spread.

So it is not that nobody solved it — it is that even spacing is an unstable equilibrium under simple rules, and any dispatch policy that just sends the nearest available car will drift into bunching under load.

The other half is that browsers chose undo over prevention, which is nearly always the better answer when it is available.

Reopening a closed tab is one keystroke, works several tabs back, and restores scroll position and often form state. Session restore brings back an entire window after a crash. Recently closed lists go back further still.

Once recovery is that cheap and that reliable, a confirmation dialog is strictly worse: it interrupts everyone to prevent something that can be undone in half a second.

Which is a good general lesson for anyone designing anything. If you can make the action recoverable, do that instead of making it confirmable.