Using Descendant and Child Combinators in CSS
You can use the descendant combinator (space) to select all <p> elements inside a <div> regardless of nesting depth, and the child combinator (>) to target only direct children, such as <li> elements inside a <ul>.
Descendant combinator (A B) selects all B elements nested anywhere inside A.
Child combinator (A > B) selects only B elements that are direct children of A.
These combinators allow precise targeting of elements based on DOM relationships without adding extra classes or IDs.
Using the correct combinator improves maintainability and performance by avoiding overly broad selectors.
You’re given a page with a div containing multiple paragraphs, some nested inside other elements. How would you write a CSS rule to style only the paragraphs that are inside that div, no matter how deep they are?
You have a <ul> with nested <li> elements, and some of those <li>s contain another <ul>. How would you style only the top-level <li>s directly under the <ul>, and not the ones inside the nested lists?
Your teammate says their CSS isn’t working — they wrote 'div > p' but all paragraphs inside the div are styled. What’s the most likely mistake they made?
Our component library has a reusable card component with a div wrapper and multiple paragraphs. We’re seeing unintended styles leak into nested cards inside the main card. How would you fix this using combinators without adding classes?
A designer wants all list items in a navigation menu to have a bottom border, but not the ones inside dropdown menus. The HTML structure is fixed. How would you target only the top-level list items without modifying the markup?
We’re debugging a styling issue where a <p> inside a <div> isn’t getting the expected margin. The CSS uses 'div p' but the rule is being overridden. What could be causing this, and how would you verify your fix?
We’re migrating a legacy UI to a component-based system. Many styles rely on deep descendant selectors like 'div div p' for scoping. What are the performance and maintainability risks, and how would you refactor them without breaking existing layouts?
In a dynamic CMS, content authors can nest arbitrary HTML inside a container. How would you design a CSS architecture that reliably styles direct children of a container (like list items) while preventing unintended styling of deeply nested elements, without relying on classes?
A performance audit shows our CSS is slow on mobile due to complex descendant selectors. How would you identify and replace inefficient combinators in a large stylesheet without introducing visual regressions?
We’re designing a design system used across 50+ products with varying HTML structures. How would you architect CSS scoping rules using combinators to ensure predictable styling across teams, while minimizing specificity wars and enabling safe third-party integrations?
Our legacy app has hundreds of pages using global descendant selectors for layout scoping. We want to migrate to shadow DOM or CSS modules. What’s your strategy for phasing out these combinators without breaking existing functionality or requiring a full rewrite?
How would you define a CSS architecture standard for a company-wide design system that balances developer convenience, performance, and long-term maintainability when using combinators — especially when teams have different levels of CSS expertise?