The classic bug: z-index 999 that loses to 2
The point (60, 70) is where the menu hangs over the banner. While the header has z-index: 1 it is a stacking context and the banner (2) covers it, menu and all. The script sets the header to auto: it stops being a stacking context, and the menu's 999 now competes directly with the banner's 2.
When boxes overlap, the browser paints them in a fixed order; z-index changes that order for positioned boxes, but only among siblings in the same stacking context, which is why a child with z-index: 9999 can still be stuck under another element.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Make a .card whose decorative ::before blob sits behind the card's text but above the page background, using a negative z-index.
Two absolutely positioned boxes .first and .second overlap; .second is later in the HTML. Make .first appear on top without changing the HTML order.
A .site-header with position: sticky should stay above every card on the page, including cards with hover transforms. Write the CSS.
Explain it without notes
What is a stacking context, and how does it limit z-index?
List several CSS properties that create a stacking context.
Describe the default painting order inside one stacking context.
A dropdown has z-index: 9999 but appears under a banner with z-index: 2. How do you debug and fix it?
Preview
Console
Nothing logged yet.Expected console output
header z-index 1 -> banner
header z-index auto -> menu