DevelopmentPractical guide
What is Bootstrap? A practical frontend framework guide
Understand Bootstrap’s responsive grid, CSS utilities and JavaScript components, what they provide and what remains your responsibility.
DevelopmentPractical guide
Bootstrap dropdown on hover: keep click, keyboard and touch working
Add optional hover behaviour to a Bootstrap menu without losing click, keyboard access or touch support. Includes a practical test matrix.
THE USEFUL ANSWER
Bootstrap dropdowns intentionally open on click. Hover can complement that behaviour for a mouse; it should not become the only way to open a menu. Keep the button, keyboard interactions and touch behaviour, and coordinate state through the component API.
- Showing a menu with CSS does not synchronise its JavaScript state.
- Keyboard and touch users must not depend on hover.
- A navigation dropdown is not automatically an ARIA menu widget.
Why click should remain the foundation
Bootstrap 5.3 dropdowns open through a click-based component. Its JavaScript handles opening, closing and standard keyboard interactions. Adding display:block on hover does not necessarily update those behaviours or the expanded state announced by assistive technology.
The actual requirement is usually faster navigation with a mouse. It does not require removing click. A laptop can also have a touchscreen, and a reader may alternate between keyboard and pointer in the same session.
Enhance one working menu instead of creating two
First make the default dropdown work without custom hover code: an identifiable button, real links, one Bootstrap bundle and reliable closing. Then enable the enhancement only for a device capable of precise hover. The hover and pointer media queries describe that capability more usefully than screen width alone.
On pointer entry, use the Dropdown instance’s show method. On exit, allow a cancellable closing delay. Do not call hide while keyboard focus remains inside the group. Preserve the normal button behaviour and the Escape key. These are implementation requirements to validate in your own navigation, not a guarantee delivered by a short CSS snippet.
Test the transitions, not just the open state
Closing at the wrong time is often the real problem. A menu that disappears while someone moves towards a link is frustrating even when the open-state screenshot looks correct.
| Interaction | Expected result | Failure to check |
|---|---|---|
| Mouse moves into submenu | Links remain reachable | Closing across a gap |
| Tab then Enter or Space | Button opens the menu | Hover-only activation |
| Escape | Component closes consistently | Visual state differs from aria-expanded |
| Touchscreen tap | Options are reachable | Parent navigation runs too early |
| Viewport resize | Links stay visible and reachable | Desktop-only positioning remains |
One more question?
Is a :hover-only solution enough?
It may expose the menu visually, but it does not establish correct state, keyboard interaction or touch support. Test the entire interaction.
Does the Bootstrap bundle contain Popper?
The JavaScript bundle includes Popper. Non-bundled setups may need the dependency supplied separately for the components that use it.
Should hover replace clicking?
No. Treat hover as an optional shortcut while keeping an operable button for click and keyboard interaction.