Absolute units go quietly wrong when the reference moves — write reference-dependent values as ratios of that reference

Say your service has an alert rule: "page me if errors exceed 50 per minute." When traffic grows tenfold, it fires on perfectly healthy days; when traffic drops, it stays silent on a day when half the requests fail. 3D pages hit the same trap: the outline from a three.js edge detection pass looks thicker or thinner depending on window resolution, and adaptive quality logic cuts image quality on a 30 Hz monitor that was running fine. None of these produce an error message. The reference the value was leaning on simply moved.

How should you write a value that depends on something else?

If a value was chosen with another value in mind (screen height, refresh rate, traffic, a base distance), write it as a ratio of that reference, not in absolute units. A value written in pixels, milliseconds, counts or fixed distances is only correct in the environment where you picked it; the moment the reference changes, its meaning changes without any error.

Absolute units are dangerous precisely because they start out correct. When you first pick the number there is only one reference, so pixels and ratios render the same picture. The difference only shows up when someone resizes the window, swaps the monitor, or moves one base value — and by then nobody remembers the constant.

Which values are tied to a reference?

If you answer "yes" to these, the value is tied to a reference:

• Did you pick this number by looking at another number? (line thickness by looking at the screen size, an alert threshold by looking at normal traffic)
• Can that other number change across users, devices, or during operation?
• If it changes, does this value have to change too in order to keep meaning the same thing?

Common examples:

• Monitoring alerts: "50 errors/min" → "2% error rate" (a ratio of requests)
• On-screen elements: "2 px outline" → "a fraction of the screen height" (so large and small windows draw the same picture)
• Performance checks: "slow if a frame takes over 20 ms" → "slow if a frame takes over 1.2× the display's frame interval"
• Animation constants: "braking zone of 30" → "0.4× the base distance" (so it follows when the base distance moves)
• Time limits: "batch job times out at 60 s" → "0.5 s per item × item count"

How do you convert an absolute value into a ratio?

1. Name the reference. For rendering, a REF_HEIGHT (reference height); for performance, the measured refresh rate; for operations, the request count. A reference that is melted into a bare number cannot be found when it needs to change.
2. Derive the value from it. Keep it as a formula such as width = 1.1 * (screenHeight / REF_HEIGHT), not as the resulting number in a constants table.
3. Group every value tied to the same reference. If part of the group is a ratio and part is absolute, moving the reference leaves the absolute part behind.
4. Add a test that changes the reference. Window height 1444 px vs 510 px, 60 Hz vs 30 Hz, base distance 32 vs 70 — compare numerically that both cases mean the same thing.
5. Decide how the reference is measured. A reference measured at runtime, such as refresh rate, is pulled around by the first few frames, so measure it after a warm-up.

If an agent does this work for you, put this in its instructions:

When you add or change a constant, first write down whether it was chosen by looking at another value (screen size, refresh rate, traffic, a base distance).
If so, do not write it in absolute units (px, ms, counts). Derive it from that reference with a formula.
Keep constants tied to the same reference in one place, and add a test that checks the result still means the same thing when the reference changes.

Is there anything ratios get wrong?

Yes. Limits set by human eyes and fingers, independent of any reference, belong in absolute units: minimum touch target size, minimum legible font size. So write the ratio and add an absolute floor or ceiling separately. But don't add floors without a reason — a "can't go below 1 px" clamp on a shader kernel is usually unnecessary, because bilinear sampling works fine below one pixel.

A browser's frame rhythm differs between devices. MDN notes that requestAnimationFrame callbacks usually match the display refresh rate, so "milliseconds per frame" is a device-dependent value. The same goes for screen height and pixel density (devicePixelRatio).

What happened to us

In all three cases nothing threw an error; only the picture or the verdict was wrong.

• Line thickness (three.js post-processing outline): the edge detection kernel width was written in pixels, and at buffer heights of 1444 px and 510 px the line weight relative to the scene differed by 2.8× (same scene rendered at two window sizes and compared). We moved the kernel, bleed and hand-jitter to ratios of a reference height, and learned that the real lever for thinner lines was the edge threshold, not the kernel width.
• Adaptive quality: quality dropped based on absolute frame time, so a 30 Hz display that was running fine got its quality cut. The check became "how far behind this display's own refresh interval", with the refresh rate measured after a warm-up.
• A group of animation constants: moving the camera's base distance from 32 to 70 left the braking zone, written as an absolute number, behind — its share shrank to a third, the camera braked abruptly just before landing, and shallower fog erased the distant scenery. We rewrote the whole group to derive from the base distance.

Checklist

• Was this constant chosen by looking at another value? What is that value called?
• Can that reference change across devices, users or during operation?
• Is the value derived from the reference by a formula, or is only the resulting number written down?
• Are all constants tied to the same reference kept in one place?
• Is there a test that swaps the reference for two different values?
• If there is an absolute floor or ceiling, is it based on a real human or device limit?