The child combinator (>) cannot select a grandchild element because it only targets elements that are direct children of the specified parent. Elements nested deeper than the first level are not matched.

Key Points

1
Syntax: A > B – selects only immediate children B of parent A.
2
Grandchildren or deeper descendants require the descendant combinator (space) or additional selectors.
3
Using the child combinator ensures precise styling for direct children without affecting nested elements.

Example: Child vs Grandchild

Difficulty: 3/10

Topics: child combinator, CSS selectors, DOM hierarchy

Scenario Questions

0-2 years experience

1
You’re trying to style only the direct children of a nav menu, but your styles are also hitting the links inside dropdowns. What’s the issue, and how do you fix it using the child combinator?
2
If you write .card > p, but the paragraph is inside a div inside the card, will it be styled? Why or why not?

2-5 years experience

1
A teammate says their CSS rule .list > li { color: blue; } isn’t working, but the HTML looks right. What are three possible reasons you’d check, and how would you isolate the issue?
2
We’re building a reusable card component where only top-level buttons should have padding, but nested buttons (like in a footer) shouldn’t. How would you use the child combinator to enforce this, and what edge cases might break it?

5-8 years experience

1
In a dynamic CMS-driven UI, content authors can nest components arbitrarily. How would you design a CSS architecture using the child combinator to ensure styling predictability without over-constraining flexibility?
2
You’re optimizing a legacy UI with 500+ CSS rules. You notice many descendant selectors (space) are causing unintended style leaks. How would you audit and refactor them using child combinators, and what risks would you mitigate?

8+ years experience

1
We’re migrating from a legacy CSS framework that relies heavily on deep descendant selectors to a modern component-based system. How would you design a strategy to replace those with child combinators without breaking existing layouts across 20+ products?
2
When designing a design system for a global company, how do you balance the precision of child combinators against the need for composability in nested third-party widgets? What tradeoffs do you document for engineers?

Follow-up Questions

❓What if you wanted to style all nested list items, not just direct ones?
❓How would you debug if a rule using > wasn’t applying as expected?
❓Can you think of a scenario where using > instead of a descendant selector improves performance?