A page sets font-family on body, yet the site's buttons and inputs still render in the browser's default font. Why does inheritance not reach them, and what is the standard fix?

## Inheritance only fills a vacuum The order matters: the cascade runs first, considering every declaration that targets this element for this property, from any origin — user-agent, user, or author. Only if that produces nothing does defaulting run, and only then does an inherited property look at its parent. The user-agent stylesheet is a real stylesheet with real declarations. It is the weakest origin, so any author rule beats it — but *only if an author rule exists for that property on that element*. A `body`-level declaration does not target the button. From the button's point of view the only declaration in play is the UA one, so the UA one wins, and inheritance never gets a turn. This is the general shape of nearly every "why did it not inherit" bug: something already declared the property on that element. ## What the browser actually declares UA stylesheets for form controls set the `font` shorthand to a platform-flavoured value. In Chromium the button rule has long resolved to something close to `font: 400 13.333px Arial`; Firefox and Safari use their own values, and modern builds increasingly reference system font keywords. The exact value is not the point and is not worth memorising — what matters is that **a declaration exists**, and that it is a shorthand, so it sets `font-style`, `font-weight`, `font-size`, `line-height` and `font-family` all at once. That is also why the same controls do not pick up your `color`, and why `text-align` inside a `<button>` is centred: those are separate UA declarations doing the same thing. ## The fix, and why the shorthand ```css button, input, select, textarea { font: inherit; } ``` `font: inherit` expands to `inherit` on every font longhand plus `line-height`, so the control adopts the page's whole type treatment. Writing only `font-family: inherit` fixes the typeface but leaves the UA's `font-size` in place, giving you a 13px control on a 16px page — a very common half-fix that looks broken at larger text sizes and hurts readability. Add `color: inherit` when you want the control's text colour to follow the page too, and remember `line-height` comes along with the `font` shorthand, so if you rely on a global unitless `line-height`, controls now share it. ## What this rule does not do `font: inherit` changes typography only. The control keeps its native background, border, padding and focus ring, which is usually what you want — those are what make it recognisable and keyboard-friendly. If you want a fully custom control you style those properties deliberately, rather than wiping everything with `all: unset`, which also removes the focus indication and the pointer cursor and leaves you re-implementing affordances by hand. Also note this is styling only: which element to use for a control, and the semantics it carries, are separate questions from how it inherits type. ## Related surprises with the same cause - A `<textarea>` does not inherit `font-family` for the same reason, and additionally has its own `white-space` behaviour. - `<select>` and its `<option>` children are rendered partly by the platform in some browsers, so even `font: inherit` may not reach every part of the dropdown. - Headings do not inherit `font-size` from `body` — the UA stylesheet declares `h1 { font-size: 2em; }` and friends. Same mechanism, different element. - `<table>` historically did not inherit font in old browsers for the same reason; that particular UA rule is gone in modern engines. ## Diagnosing it in seconds In DevTools, select the control and look at the Computed pane for `font-family`. If the value traces to a `user agent stylesheet` rule rather than showing as inherited from an ancestor, you have your answer immediately — and the same trick identifies any other property that mysteriously refuses to inherit.