In CSS, what does :focus-visible match that :focus does not, and why was it added to the language?

## The problem :focus-visible solves Before it existed there was exactly one focus selector, `:focus`, and it matched every focused element regardless of how focus arrived. That created a genuine conflict. A mouse user clicking a button already knows where they are, so the ring reads as visual noise; a keyboard user has no other cue at all, so the ring is the entire navigation model. Teams resolved the conflict the fast way — `:focus { outline: none }` or `*:focus { outline: 0 }` in a reset — and shipped a site that is unusable without a mouse. `:focus-visible` splits the case. It matches a focused element only when the user agent's heuristic concludes a visible indicator should be drawn. ## What the heuristic actually does The specification deliberately leaves the rule to the user agent, but the behaviour converged in practice: - Focus moved by keyboard — Tab, Shift+Tab, arrow keys inside a composite widget — matches `:focus-visible`. - Elements that accept text input match whenever they are focused, including by mouse. A caret sitting in a field with no ring is confusing, so the heuristic keeps the indicator. - A mouse press on a button or link generally focuses it (`:focus` matches) without `:focus-visible` matching. - Programmatic focus generally inherits the modality of the last interaction: after keyboard use, moving focus in script tends to match `:focus-visible`; after a click, it tends not to. Because it is a heuristic rather than a fixed rule, treat the first two bullets as reliable and the rest as "the browser decides". ## The modern default already uses it Current browsers' user-agent stylesheets draw the default focus ring via `:focus-visible`, not `:focus`. Two consequences follow. First, the old complaint that motivated `outline: none` has largely disappeared on its own — clicking a button in an unstyled page does not leave a ring. Second, `:focus { outline: none }` in your own stylesheet is now actively harmful, because it overrides a UA rule that was already doing the right thing. ```css /* Do not do this — it kills the keyboard indicator too */ button:focus { outline: none; } /* Do this — replace the ring, scoped to the case that needs it */ button:focus-visible { outline: 3px solid #0b5fff; outline-offset: 2px; } ``` `outline` is the right property for the job: it is drawn outside the box without participating in layout, so it never shifts anything, and in current browsers it follows `border-radius`. `outline-offset` pushes it clear of the element's own border. Using `box-shadow` instead works visually but disappears under forced-colors modes, so if you go that route add an `outline` fallback. ## The pattern for suppressing only the mouse ring If you must keep a custom ring but drop it on click, do not write a blanket removal. Scope the removal to the negation: ```css .btn:focus:not(:focus-visible) { outline: none; /* mouse/tap focus only */ } .btn:focus-visible { outline: 3px solid Highlight; outline-offset: 2px; } ``` The first rule is the fallback-safe order: if a browser did not support `:focus-visible`, the `:not()` would fail to parse and the removal would never apply, leaving the ring intact. That fail-safe direction is why this idiom persisted. ## :focus-within, the container case A related pseudo-class, `:focus-within`, matches an element that is focused **or** contains a focused descendant. It is how you highlight a whole form group, card, or combobox wrapper while any control inside it has focus, without script: ```css .field:focus-within { border-color: #0b5fff; } .field:focus-within > label { color: #0b5fff; } ``` Do not confuse the three: `:focus` is "this element has focus", `:focus-within` is "focus is somewhere in here", `:focus-visible` is "this element has focus and should show it". ## Interview-grade judgment The points that separate a strong answer: the indicator must meet a visible contrast bar against both the component and the page behind it; never rely on colour alone if the shape is unchanged; test by tabbing through the page, since a mouse pass will never reveal the bug; and remember that removing focus styles is a WCAG failure, not a taste decision. Browser support has not been a limitation since 2022 — `:focus-visible` shipped in Chrome 86, Firefox 85, and Safari 15.4 — so a codebase still carrying a global `outline: none` reset is carrying a defect, not a compatibility shim.