Padding belongs to the thing, margin belongs to the relationship

A distinction that decides how reusable your work is

Every element has space inside it and space around it. The distinction sounds like a technical detail in CSS, and it is actually a design decision with consequences that show up months later.

The rule:

Padding is part of the object. It travels with the thing wherever it goes, because it is what makes the thing look like itself.

Margin is part of the relationship. It belongs to the layout, because it describes how this object sits next to that one.

A card has 24px of padding because a card with 4px of padding is not the same card. A card has 32px below it because in this layout it sits above a section heading. Move the card into a sidebar and the padding should follow; the 32px should not.

The component that cannot be reused

Here is the failure. Somebody builds a card and gives it margin-bottom: 32px so that a stack of them looks right. It does look right, in that one layout. Then:

• The card goes into a grid, where the gap is handled by the grid, and every card now has 32px of dead space underneath.
• The last card in a list has a trailing 32px that nothing balances, so somebody adds a rule for :last-child.
• A different page wants 48px, so somebody adds a modifier class.
• Six months later the card has four spacing overrides and nobody can say what its natural spacing is.

Every one of those steps was reasonable. The original decision was the mistake: the card claimed ownership of a relationship it was not part of.

Let the container own the gaps

The modern answer is that a container sets the spacing between its children, and children carry no outer margin at all:

.card { padding: var(--space-4); }       /* the object */
.card-list { display: grid; gap: var(--space-5); }  /* the relationship */

This also sidesteps margin collapsing, which is a genuine source of confusion: adjacent vertical margins in normal document flow merge into the larger of the two rather than adding, and a parent's margin can collapse through to a child. gap does none of that. It puts the stated space between things and nothing else.

The same logic applies away from code. In a design file, a component's spec should state its internal padding. The spacing between instances belongs to the layout that contains them, and a component that ships with an external margin baked in is a component that will be fought with.

Padding is measured to the visible mass

The optical point from earlier returns here. If a button has 12px of padding measured against the line box, the space above the letters looks like about 8px and the space below like about 16px, because the line box reserves descender room the word may not use.

So padding around text is not simply a number. Two working rules:

• Set the line height explicitly on the element you are padding, so you know what you are measuring against.
• Expect to shave 1 to 2 pixels off the bottom padding at body size, more at display sizes.

For icons the opposite problem appears: most icon artwork ships with transparent padding built into the file, so a 24px icon may only be 20px of visible mark. Two icons from different sets in the same 24px box will look like different sizes. Check the artwork, not the box.

The nesting rule

When a padded object sits inside another padded object, the two paddings add up, and the result is usually too much. A section with 32px of padding containing a card with 24px gives 56px between the card's content and the section's edge, which reads as a mistake.

The usual resolution is that one level of nesting owns the padding and the other owns nothing. Pick the level that is visible — if the card has a background, it needs the padding; if the section has the background, the card can be flush.

The related detail from the shape lesson: an inner rounded rectangle nested inside an outer one wants an inner radius equal to the outer radius minus the padding. With 16px of padding inside a 16px radius, the inner element should have square corners.

Why this is a design lesson and not an engineering one

Because the decision is about what a thing is. Deciding that a card owns its padding is deciding that the padding is part of the card's identity, and that its position in a layout is somebody else's business. That is a piece of design thinking, and it is the point where a set of screens starts to become a system.