🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.
🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.
REFERENCEcss

css Documentation

LOADING ENGINE...

Child Selectors

AI & DATA SCIENCE // child-selectors

A child selector, written with a greater-than sign like ul > li, targets only the direct children of an element matching the first selector, not deeper-nested descendants.

Syntax

parent > child {
  property: value;
}

Deep Dive Course

ul > li matches only <li> elements that are immediate children of a <ul>, excluding any <li> nested more deeply, say inside a nested <ul> within one of those top-level list items — this is the key distinction from the plain descendant selector, a space, which matches at any nesting depth regardless of how many levels separate the two elements. The child combinator is specifically useful when a descendant selector would be too broad, matching unwanted deeply-nested instances, such as styling only a menu's top-level items while leaving nested submenu items unaffected by that same rule.

1Understanding Child Selectors

ul > li matches only <li> elements that are immediate children of a <ul>, excluding any <li> nested more deeply, say inside a nested <ul> within one of those top-level list items — this is the key distinction from the plain descendant selector, a space, which matches at any nesting depth regardless of how many levels separate the two elements. The child combinator is specifically useful when a descendant selector would be too broad, matching unwanted deeply-nested instances, such as styling only a menu's top-level items while leaving nested submenu items unaffected by that same rule.

💡

Reach for the child combinator (>) instead of the plain descendant selector, a space, specifically when nested, deeper instances of the same element exist and shouldn't be affected by the same rule, like top-level menu items versus items in a nested submenu.

editor.html
.menu > li {
  display: inline-block;
}
localhost:3000

2Practical Example

Here is a real-world application of Child Selectors showing how it is used in production CSS code.

editor.html
<ul class="menu">
  <li>Home</li>
  <li>Products
    <ul>
      <li>Nested item</li>
    </ul>
  </li>
</ul>

.menu > li { font-weight: bold; }
localhost:3000

3Best Practices

Follow these guidelines when working with Child Selectors:

1. Use the child combinator when you specifically need to exclude more deeply-nested instances of the same element that a plain descendant selector would otherwise also match

2. Reach for > when styling a component with intentionally nested, recursive structure, like nested lists or nested menus, where only the top level should receive a specific style

3. Default to the plain descendant selector for the more common case where matching at any depth is actually the intended, correct behavior

⚠️

Tip: Reach for the child combinator (>) instead of the plain descendant selector, a space, specifically when nested, deeper instances of the same element exist and shouldn't be affected by the same rule, like top-level menu items versus items in a nested submenu.

editor.html
.menu > li {
  display: inline-block;
}
localhost:3000

Examples

Example 01Basic Usage
.menu > li {
  display: inline-block;
}
Example 02Advanced Example
<ul class="menu">
  <li>Home</li>
  <li>Products
    <ul>
      <li>Nested item</li>
    </ul>
  </li>
</ul>

.menu > li { font-weight: bold; }

Best Practices

  • Use the child combinator when you specifically need to exclude more deeply-nested instances of the same element that a plain descendant selector would otherwise also match
  • Reach for > when styling a component with intentionally nested, recursive structure, like nested lists or nested menus, where only the top level should receive a specific style
  • Default to the plain descendant selector for the more common case where matching at any depth is actually the intended, correct behavior

Interview Question

Why would .menu li and .menu > li produce different results specifically on a menu structure containing a nested submenu, but identical results on a menu with no nesting at all?

Hint: Think about what each selector actually requires structurally, and whether that requirement is even relevant when no nested elements exist in the markup to begin with.

The plain descendant selector, .menu li, matches any <li> anywhere inside .menu regardless of nesting depth, while the child combinator, .menu > li, matches only <li> elements that are immediate children of .menu specifically, excluding any <li> nested deeper inside a submenu. On a menu structure that actually contains a nested submenu, these two selectors genuinely differ in which elements they match, since the descendant selector would additionally match the deeper, nested submenu items that the child combinator deliberately excludes. On a flat menu structure with no nesting at all, however, every single <li> inside .menu already happens to be a direct child by definition, there simply are no deeper-nested <li> elements for the two selectors' differing behavior to actually apply to, so both selectors end up matching the exact same set of elements and therefore produce identical results, purely because the specific structural difference between them, direct child versus any-depth descendant, never actually comes into play on that particular markup.

Exercises

MediumPractice using Child Selectors in a real scenario.
View Solution
.menu > li {
  display: inline-block;
}

Frequently Asked Questions

Why would .menu li and .menu > li produce different results specifically on a menu structure containing a nested submenu, but identical results on a menu with no nesting at all?

The plain descendant selector, .menu li, matches any

  • anywhere inside .menu regardless of nesting depth, while the child combinator, .menu > li, matches only
  • elements that are immediate children of .menu specifically, excluding any
  • nested deeper inside a submenu. On a menu structure that actually contains a nested submenu, these two selectors genuinely differ in which elements they match, since the descendant selector would additionally match the deeper, nested submenu items that the child combinator deliberately excludes. On a flat menu structure with no nesting at all, however, every single
  • inside .menu already happens to be a direct child by definition, there simply are no deeper-nested
  • elements for the two selectors' differing behavior to actually apply to, so both selectors end up matching the exact same set of elements and therefore produce identical results, purely because the specific structural difference between them, direct child versus any-depth descendant, never actually comes into play on that particular markup.

  • Related Functions

    Descendant-SelectorsSiblings-SelectorsUniversal-Selectors