The :focus-within pseudo-class in CSS applies to an element when it or any of its descendants has focus. It is useful for styling a container when an input or interactive element inside it is focused.

Key Points

1
:focus-within applies to the parent element, not just the focused child.
2
It helps highlight groups of elements (like form sections) when one of their inputs is active.
3
It works with all focusable elements, including <input>, <textarea>, <select>, <button>, and elements with tabindex.

Example: Using :focus-within

In this example, when the user focuses on either the 'First Name' or 'Last Name' input, the entire .form-section container gets a highlighted background and border, providing visual context to the focused group.

Best Practices

1
Use :focus-within to improve form usability and highlight related fields.
2
Combine with transitions for smooth visual feedback.
3
Avoid over-styling; subtle highlighting is often sufficient.
4
Test accessibility and keyboard navigation to ensure focus indicators remain clear.

Difficulty: 6/10

Topics: focus-within pseudo-class, form accessibility, CSS state management

Scenario Questions

0-2 years experience

1
You're building a login form and want the entire form box to get a border glow when the user tabs into any input. How would you use :focus-within to do that without JavaScript?
2
If you apply :focus-within to a div containing a button and an input, and the button gets focus, will the div still style? Why or why not?

2-5 years experience

1
A teammate says the search bar’s container isn’t highlighting on focus anymore, even though the input is focusable. What are three things you’d check in the CSS and HTML structure?
2
We’re using :focus-within to show a dropdown menu on focus, but it breaks on mobile Safari. What’s likely causing this, and how would you debug it without changing the markup?
3
Our form validation messages are inside the container with :focus-within, but they’re getting the same highlight as the inputs. How would you fix that without adding extra classes?

5-8 years experience

1
We’re designing a reusable form component library and want :focus-within to be the default focus indicator for accessibility. What edge cases or browser inconsistencies should you account for, and how would you structure the CSS to avoid style leakage?
2
A senior engineer argues that :focus-within is too unpredictable for complex nested forms. How would you defend its use in a scalable UI system, and what performance or maintenance tradeoffs would you highlight?
3
You’re migrating a legacy form system that uses JS to manage focus states. How would you approach replacing those with :focus-within while ensuring backward compatibility and accessibility compliance?

8+ years experience

1
We’re standardizing accessibility patterns across 20+ product teams. Should :focus-within be mandated as the primary focus indicator for form containers? What cross-team adoption risks, legacy browser constraints, or testing infrastructure gaps would you surface?
2
A major redesign is replacing all JS-based focus managers with CSS-only solutions using :focus-within. How would you architect the rollout plan, measure success, and handle regressions in enterprise systems with complex shadow DOMs and third-party widgets?
3
Your team is building a design system for a global financial platform. How would you balance the elegance of :focus-within against the need for consistent, testable, and WCAG-compliant focus states across 50+ form variants and 12 supported languages?

Follow-up Questions

❓How would you test this in a real browser with only a keyboard?
❓What happens if you nest multiple focus-within containers?
❓Could this interfere with a custom focus indicator system?