The child combinator (>) is preferred when you want to target only the direct children of a parent element. This provides more precise control and avoids unintentionally styling nested or deeper descendant elements.

Key Scenarios

1
When styling should only apply to immediate children and not grandchildren or deeper descendants.
2
When aiming for better performance by reducing the number of elements the browser must evaluate.
3
When creating maintainable CSS where specificity and hierarchy need to be explicit.
4
When avoiding unexpected styles on nested elements within a complex DOM structure.

Example: Using Child Combinator

Difficulty: 3/10

Topics: child vs descendant combinator, CSS specificity, component isolation

Scenario Questions

0-2 years experience

1
You're styling a navigation menu where each link is a direct child of the <ul>, but you notice some nested dropdown items are getting the same styles—how would you fix that using the child combinator?
2
If you write .card > .title, but later someone adds a span inside .title, will that span get styled? Why or why not?
3
You're told to style only the first-level list items in a sidebar, but not any nested ones. What CSS selector would you use and why?

2-5 years experience

1
A teammate says the buttons in our modal are inheriting padding from a global rule, but they shouldn’t—how would you track down whether the issue is caused by using a descendant vs. child combinator?
2
We have a reusable card component that’s breaking when nested inside another card because styles are leaking. How would you refactor the CSS to prevent this using combinator selection?
3
Our design system uses .list > .item for spacing, but now we need to support nested lists. What’s the risk of keeping the child combinator, and what alternatives would you consider?

5-8 years experience

1
You’re designing a scalable component library where components can be nested arbitrarily. How do you decide between child and descendant combinators to balance specificity, maintainability, and developer ergonomics?
2
A legacy UI has hundreds of components using descendant selectors, causing unintended style collisions. How would you approach migrating to child combinators without breaking existing layouts?
3
In a large CSS-in-JS codebase, you notice performance degradation during re-renders. Could overuse of descendant combinators contribute to this? How would you validate and optimize?

8+ years experience

1
We’re migrating from a monolithic CSS architecture to a micro-frontend setup with independent styling scopes. How do you architect CSS selectors—child vs. descendant—to ensure true encapsulation across teams without relying on CSS-in-JS?
2
A company-wide design system uses descendant selectors for flexibility, but now we’re seeing inconsistent behavior across products due to unpredictable DOM nesting. How would you propose a long-term strategy to enforce component boundaries at the CSS level?
3
You’re advising a startup that plans to scale to 50+ frontend engineers. What CSS architecture principles would you advocate for regarding combinator usage to prevent style leakage and enable independent component ownership?

Follow-up Questions

❓What happens if you accidentally use the descendant combinator in a reusable card component?
❓How would you debug a style that's applying to elements you didn't expect?
❓Can you think of a case where using > would break if the HTML structure changes?