corners are relative

A border-radius is just a number. A number can't describe how a corner should feel.

The same 12px looks generous on a small button and almost flat on a wide card. Place a rounded element inside another rounded element, give them the same radius, and the corners still won't line up.

Roundness is relative. Against a small element a radius reads soft, against a large one it nearly disappears, and inside another rounded element it has to bend around the gap. The number never moves. Everything around it does.

Most design systems define radius tokens. Far fewer define the relationships between them.

Size is the part you judge by eye. Nesting is the part you can calculate, and it is where many interfaces break.

Buttons expose this fast, because their height leaves less room for ambiguity. A larger radius is not automatically cleaner. At small sizes, the corner starts to compete with the button shape itself. Push it far enough and the button wants to become a pill.

The trap is the middle. A value near half the height, say 14px on a 40px button, doesn't commit. Too round to read as a precise rounded rectangle, not round enough to read as an intentional pill, so it looks swollen instead of soft. A button reads better when the shape is clear: a controlled rounded rectangle, or a pill.

The common failure is one element rounded inside another: a card at 12px, an image inside it, 8px of padding.

It passes review, then looks wrong on screen. Nested corners need a shared center. The inner corner is not another 12px corner placed inside the card. It is the same corner moved inward by the gap.¹

That is why, for round corners, the inner radius is the outer radius minus the gap. The gap is everything between the two curves: padding, border, and any intentional spacing.

The formula gives you concentric, not finished. At small radii a strictly concentric inner corner can read a little tight, so a pixel or two more often looks better even when the math disagrees. The number gets you to concentric, your eye takes it the rest of the way. In the demo below, the math lands on 4px. To my eye 6px sits better.

If the gap is bigger than the radius, the inner corner is square. Once you see it, you start noticing it everywhere.

A border is not decoration outside the math. It consumes space between the outer and inner curve. Stack a bordered child inside a padded card and the border joins the padding as part of the gap.

Everything between the two curves is the gap, padding and border together. With a 16px outer radius, 8px of padding, and a 1px border, the inner radius is 7px, not 8. Use 8 and you only subtracted the padding. Concentric starts at 7; your eye can take it from there.

A system needs two things: a scale that sets the outer radius, and a rule that derives the inner one. Tokens give you the scale. They do nothing for the rule.

This is the practical rule. The inner radius is the parent's radius minus the full gap, border and padding both.

Write the relationship, not the result. A 12px card with a 1px border and 8px padding lands on 3px today, but you never typed 3. Change the padding and the corner follows on its own. That is the whole point: hold onto the formula, not the number it happens to produce.

The subtraction works because the default corner is a quarter circle. Offset a circle inward and you get a smaller circle. That is a fact about circles, not corners.

Round was the only corner for so long that nobody clocked it as a choice. Current Chromium corner-shape support makes the assumption visible.

The border-radius property still sets how big the corner is. corner-shape sets the curve that fills it.² round is the arc every example above assumes. squircle is a superellipse, a curve that spreads its bend differently than a circle.

A superellipse does not offset to a smaller superellipse the way a circle does. Subtract the gap and the inner corner no longer traces the outer one.

The CSS compiles. The numbers look right. The corners drift. There is an open CSSWG issue about a superellipse value with inner and outer symmetry, because the plain one does not nest cleanly.³

SwiftUI already has ConcentricRectangle for this.⁴ CSS does not. For now the squircle part is a forecast, not a recipe.

The formula was always a floor, not a finish. Squircles take the floor away. This time there is no simple number that lands. You judge it and ship the least-wrong one.

A radius is not a standalone decision. It changes with size, spacing, borders, and the curve itself.

Size the radius to the element. A button, a card, and a panel should not blindly share one token. On small controls, bad radius choices show up faster: too round to feel precise, not round enough to feel intentional.

For nested round corners, derive the inner radius. Outer radius minus the full gap, with the border counted as part of that gap.

Then look. The formula gets you to a clean relationship, not a finished design. Your eye decides the final value, often a pixel or two past the math.

Drop the formula when you change the curve. With corner-shape, subtraction no longer guarantees a clean nest. Judge the result and ship the least-wrong one.

Gate corner-shape behind @supports. Fall back to round corners everywhere else.