CSS Only Dropdown Navbar — Hover & Focus-Within, No JavaScript

Dropdown navbars are usually built with a JavaScript click/hover handler that toggles a class, but the two pseudo-classes :hover and :focus-within are enough to build the entire interaction natively, including the keyboard-accessible case that naive CSS-only attempts usually get wrong.

The core mechanism: :hover on the parent, styling a descendant

Each dropdown-capable item is an <li class="menu-item has-dropdown"> containing both the trigger link and a nested <ul class="dropdown">. The rule .has-dropdown:hover > .dropdown says: when the mouse is over this specific <li> (not just the link inside it), reveal its direct-child dropdown. Because :hover matches for as long as the cursor is anywhere inside the element's box — including the dropdown panel itself once it appears below the trigger — moving the mouse down into the open dropdown keeps it open rather than closing it the instant the cursor leaves the link. This is the detail that trips up most hand-rolled attempts: hovering the *link* alone, rather than the containing *li*, causes the dropdown to disappear the moment the cursor moves toward it.

Why :focus-within, not just :focus

:focus only matches an element that is itself the focus target. :focus-within matches an element if *it or any of its descendants* currently has focus. Tabbing to the "Products" link doesn't put focus on the <li> — it puts focus on the <a> inside it — so .has-dropdown:focus would never match. .has-dropdown:focus-within does match, because the focused <a> is a descendant of the <li>. Critically, this also means that after the dropdown opens and a user presses Tab again to move focus into one of the .dropdown-link items, the <li> *still* matches :focus-within, because focus is still somewhere inside it — so the panel stays open while a keyboard user tabs through its contents, and only closes once focus moves to a sibling top-level item or leaves the navbar entirely.

Opacity + visibility, not display

The dropdown transitions with opacity, transform: translateY, and visibility together, rather than toggling display: none/block. display cannot be animated or transitioned by CSS at all — it's an all-or-nothing property, so a fade/slide reveal is impossible with it. visibility, on the other hand, *can* be included in a transition list; while it can't be smoothly interpolated either, listing it in the transition still lets the browser defer applying visibility: hidden until the opacity transition finishes, and the combination is what removes the dropdown from hit-testing (and screen-reader/tab focus reachability, when paired with sensible markup) once it's fully faded out, unlike opacity: 0 alone which would leave an invisible-but-still-clickable panel floating over the page.

The chevron rotation

The small triangle after each dropdown trigger is drawn with a single ::after pseudo-element: two borders (border-right and border-bottom) on an otherwise empty 6×6px box, rotated 45 degrees to form a downward-pointing chevron using transform: rotate(45deg). On hover/focus-within it rotates to -135deg, flipping it to point upward — a single transform transition handles the animation, with no separate "up" and "down" icon assets needed.

Where this matters beyond convenience

Anywhere JavaScript cannot run — sanitized CMS content blocks, HTML email templates, AMP pages, markdown-rendered documentation sites that strip embedded scripts — a JS-driven dropdown navbar simply won't open. Because this version's entire interaction model lives in :hover and :focus-within, both of which are core CSS pseudo-classes the browser evaluates natively, it renders and functions identically in those environments with zero script dependency.

Touch device caveat, addressed honestly

Touch screens have no true hover state — most mobile browsers simulate a "hover" on first tap and then follow through as a click, which can make dropdown-only-on-hover navbars awkward on touch. This pattern is best suited to desktop/pointer navigation; for a fully touch-friendly version you'd pair it with a small media query that swaps to the checkbox-hack pattern (see the companion hamburger-menu snippet) below a touch-relevant breakpoint.