The visibility trick that makes dropdowns safe
The most common dropdown bug is hiding a menu with opacity: 0 alone. An element at zero opacity still occupies space, still receives clicks, and — critically — is still in the keyboard tab order and still announced by screen readers. A "closed" menu built that way silently traps keyboard users in invisible links.
The fix is to include visibility: hidden in the transition alongside opacity. Because visibility is discrete rather than continuous, it flips at the end of the transition on close and immediately on open — so the menu fades smoothly but genuinely disappears when closed. Every dropdown here uses that pattern.
Making hover menus keyboard-accessible
A dropdown that only opens on :hover is unreachable by keyboard. Adding :focus-within to the same rule fixes it in one line: the menu opens when any descendant receives focus, so tabbing into the trigger reveals it exactly as hovering does.
For production navigation, a click-triggered menu driven by JavaScript is generally better than hover — it works identically on touch, allows explicit Escape-to-close, and lets you manage aria-expanded honestly. Use the hover pattern for simple cases and progressive enhancement.
Transform origin communicates where things come from
The difference between the fade and the grow effect is spatial information. A menu that scales up from transform-origin: top left visibly emerges from its button; a menu that simply fades in appears from nowhere. The former helps users connect the panel with the control that opened it — worth the extra line for menus that open in unexpected places.
Staggering, and knowing when to stop
The staggered effect adds an incremental transition-delay per item, cascading them into view. It looks considered on a menu of three to five items and sluggish beyond that — the last item in a ten-item menu arrives long after the user has started reading. Cap the stagger, and set delays back to zero on close so the menu snaps shut instantly.