pointer-events

Why Is My Dropdown Closing When I Move the Mouse?

by

Dropdown closes when moving mouse problems usually happen because there is a hover gap between the trigger and the menu, the dropdown is positioned too far away, pointer-events are disabled, or the menu is being covered by another layer.

Dropdown Hover Fix

Why is my dropdown closing when I move the mouse?

A dropdown can open correctly and still close the moment you move your mouse toward it. That usually means the mouse leaves the hover area before it reaches the menu. The most common cause is an invisible gap between the trigger and the dropdown, but z-index, pointer-events, positioning, and mobile hover behavior can create the same frustrating bug.

CSS Fixes Responsive Fixes
  • Hover gap
  • Pointer events
  • z-index
  • Mobile menu

What the bug looks like

The dropdown opens on hover, but disappears before your cursor reaches the menu item you want to click.

Why it happens

The hover state is attached to an area that does not include the full path from trigger to dropdown.

What usually fixes it

Remove the hover gap, add a hover bridge, keep the dropdown inside the hoverable parent, and avoid hover-only menus on mobile.

Error 1

There is a gap between the trigger and the dropdown

The dropdown closes because the mouse leaves the hoverable parent while crossing the empty space between the button and the menu. Visually, the gap may look tiny, but to CSS hover it is a complete state break.

Broken code

Hover dead zone 
.nav-item {
  position: relative;
}

.dropdown {
  position: absolute;
  top: 70px;
  left: 0;
}

.nav-item:hover .dropdown {
  display: block;
}

Broken visual result

Cursor crosses a dead zone
Products gap
Landing pages Components Templates
The menu disappears because the cursor leaves the hoverable parent before reaching the dropdown.

Correct code

Hover bridge 
.nav-item {
  position: relative;
}

.dropdown {
  position: absolute;
  top: 100%;
  left: 0;
  padding-top: 12px;
}

.dropdown::before {
  content: "";
  position: absolute;
  left: 0;
  right: 0;
  top: -12px;
  height: 12px;
}

Fixed visual result

Safe hover path
Products
Landing pages Components Templates
The dropdown includes a safe invisible bridge, so the hover state does not break.
Error 2

The dropdown is shown on the wrong hover target

If the hover is attached only to the button, the dropdown closes as soon as the cursor leaves the button. The hover should usually live on a wrapper that contains both the trigger and the menu.

Broken code

Button-only hover 
.menu-button:hover + .dropdown {
  display: block;
}

.dropdown {
  display: none;
}

Broken visual result

Hover area too small
Services
Design Development Debugging
The menu depends on hovering the button, but the user must leave the button to reach the menu.

Correct code

Wrapper hover 
.nav-item:hover .dropdown,
.nav-item:focus-within .dropdown {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
}

.nav-item {
  position: relative;
}

Fixed visual result

Wrapper owns the interaction
Services
Design Development Debugging
The hoverable wrapper contains both the trigger and the dropdown, so the menu stays open.
Error 3

pointer-events makes the dropdown unusable

Some dropdowns are hidden with opacity and visibility, but developers forget to restore pointer-events when the menu opens. The result feels like the dropdown closes or cannot be reached, even though it is visible.

Broken code

Clicks pass through 
.dropdown {
  opacity: 0;
  pointer-events: none;
}

.nav-item:hover .dropdown {
  opacity: 1;
  /* pointer-events still none */
}

Broken visual result

Visible but not interactive
Account
Profile Settings Logout
Pointer problem The menu can look open but ignore the mouse.
A visible dropdown still needs pointer events enabled when open.

Correct code

Interactive open state 
.dropdown {
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
}

.nav-item:hover .dropdown,
.nav-item:focus-within .dropdown {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
}

Fixed visual result

Visible and clickable
Account
Profile Settings Logout
The open state should restore opacity, visibility, and pointer events together.
Error 4

The dropdown is hover-only on mobile

Touch devices do not behave like desktop hover. A mobile dropdown that depends only on :hover can open inconsistently, close immediately, or trap the user. Mobile menus usually need a click/tap state.

Broken code

Hover-only mobile menu 
.nav-item:hover .dropdown {
  display: block;
}

@media (max-width: 768px) {
  .dropdown {
    position: absolute;
  }
}

Broken visual result

Touch behavior is unstable
Mobile nav

The menu depends on hover, which is not a reliable mobile interaction.

Tap menu
Home Services Contact
Hover-only dropdowns are fragile on touch screens.

Correct code

Click/tap state 
.dropdown {
  display: none;
}

.nav-item.is-open .dropdown {
  display: block;
}

@media (hover: hover) {
  .nav-item:hover .dropdown {
    display: block;
  }
}

Fixed visual result

Mobile has its own state
Mobile nav

The menu can use tap/click state on mobile and hover only where hover exists.

Tap menu
Home Services Contact
Use hover as an enhancement, not the only way to open a mobile dropdown.
Premium pattern

A production-minded dropdown hover pattern

A strong dropdown pattern keeps the trigger and menu inside one parent, removes hover gaps, supports keyboard focus with :focus-within, restores pointer events when open, and treats touch screens differently from hover devices.

Premium code

Safe dropdown system 
.nav-item {
  position: relative;
}

.dropdown {
  position: absolute;
  top: 100%;
  left: 0;
  min-width: 220px;
  padding-top: 12px;
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
  transform: translateY(6px);
  transition: .18s ease;
  z-index: 100;
}

.dropdown::before {
  content: "";
  position: absolute;
  left: 0;
  right: 0;
  top: -12px;
  height: 12px;
}

.nav-item:hover .dropdown,
.nav-item:focus-within .dropdown,
.nav-item.is-open .dropdown {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
  transform: translateY(0);
}

@media (hover: none) {
  .nav-item:hover .dropdown {
    opacity: 0;
    visibility: hidden;
    pointer-events: none;
  }

  .nav-item.is-open .dropdown {
    opacity: 1;
    visibility: visible;
    pointer-events: auto;
  }
}

Premium visual result

No hover gap, no panic close
Resources
Guides Components Debug checklist
Premium dropdowns do not depend on a perfect mouse path. They create a safe interaction area.

Fast practical rule

If a dropdown closes when moving mouse, look for the gap first. Move the dropdown closer to the trigger, keep both inside the same hoverable parent, and add an invisible hover bridge before touching complicated JavaScript.

Debug checklist

  • Move the mouse slowly from the trigger to the dropdown and watch where it closes.
  • Check whether there is a visible or invisible gap between the button and the menu.
  • Attach hover to the wrapper that contains both the trigger and the dropdown.
  • Add :focus-within so keyboard users can keep the dropdown open.
  • Restore pointer-events:auto when the menu is open.
  • Check whether another layer is covering the dropdown with a higher z-index.
  • Avoid hover-only behavior on touch screens.
  • Use click/tap state for mobile menus and hover as a desktop enhancement.
Best first move Temporarily give the dropdown area a background color so you can see the hover path.
Most common cause The dropdown is too far below the trigger, creating a dead zone.
Most sneaky cause The menu is visible, but pointer-events:none is still active.
Better mindset Dropdowns need an interaction area, not just a visual box.

Related fixes that can help

Dropdowns that close too early often connect to hover behavior, click blocking, z-index, mobile menus, and floating UI layers.

Why is my mobile menu not opening? If the dropdown is part of a mobile nav and tap behavior is unreliable. Read this fix
Why is my button not clickable? If the menu opens but menu items or buttons cannot be clicked. Read this fix
Fix z-index not working If the dropdown is open but hidden behind another element. Read this fix
Why is my tooltip hidden behind other elements? If the same floating UI problem happens with tooltips. Read this fix
Why is my modal behind the overlay? If overlays, modals, and dropdowns are fighting in the same layer system. Read this fix
Why is my sticky header not staying on top? If the dropdown lives inside a sticky header and disappears behind content. Read this fix

Final takeaway

A dropdown closes when moving mouse because CSS hover is unforgiving. If the cursor leaves the hoverable area for even a moment, the dropdown closes. Most of the time, the fix is not complicated JavaScript. It is a better hover area.

Keep the trigger and menu inside one wrapper, remove the gap, add a hover bridge, restore pointer events, and use click/tap state for mobile. The dropdown will feel stable because the interaction path is stable.

Want more fixes like this?

Browse more hover, dropdown, menu, and CSS interaction debugging guides in the FrontFixer library.

CSS Fixes All Fixes

Why Is My Modal Behind the Overlay?

by

Modal behind overlay problems usually happen when the overlay has a higher z-index than the modal, the modal is trapped inside a stacking context, or the modal and overlay are placed in the wrong HTML structure.

Modal z-index Fix

Why is my modal behind the overlay?

A modal behind overlay bug is one of the most confusing CSS problems because the modal exists, the overlay exists, and the code looks almost right. But visually, the dark overlay sits above the modal, the popup looks faded, or the modal cannot be clicked. The real issue is usually layer order: z-index, stacking context, position, transform, or where the modal is placed in the HTML.

CSS Fixes All Fixes
  • Modal z-index
  • Overlay layer
  • Stacking context
  • Click blocking

What the bug looks like

The modal appears dim, sits under the dark background, cannot be clicked, or looks like it opens behind the page.

Why it happens

The overlay and modal are not in the right stacking order, or the modal is trapped inside a lower stacking context.

What usually fixes it

Put the overlay and modal in one predictable layer system, then make the modal layer higher than the overlay.

Error 1

The overlay has a higher z-index than the modal

This is the simplest version of the bug. The overlay is placed above the page, but the modal is not placed above the overlay. The result is a popup that looks hidden, darkened, or unclickable.

Broken code

Overlay wins 
.overlay {
  position: fixed;
  inset: 0;
  z-index: 1000;
}

.modal {
  position: fixed;
  z-index: 50;
}

Broken visual result

Modal is under overlay
Page content
behind Modal

The popup is lower than the overlay layer.

The modal exists, but the overlay paints above it and steals the visual focus.

Correct code

Modal wins 
.overlay {
  position: fixed;
  inset: 0;
  z-index: 1000;
}

.modal {
  position: fixed;
  z-index: 1001;
}

Fixed visual result

Modal above overlay
Page content
above Modal

The popup is now above the overlay layer.

The modal layer must be higher than the overlay layer.
Error 2

The modal is trapped inside a stacking context

A modal can have a huge z-index and still lose if it is inside a parent stacking context. A transformed parent, filtered parent, or positioned parent with its own z-index can trap the modal below the page overlay.

Broken code

Trapped modal 
.card {
  transform: translateZ(0);
  z-index: 1;
}

.card .modal {
  position: fixed;
  z-index: 9999;
}

Broken visual result

Huge z-index still loses
Transformed parent
trapped Modal

The modal is inside a lower parent context.

A huge z-index cannot escape a parent stacking context.

Correct code

Page-level modal 
<body>
  <main class="page">...</main>

  <div class="overlay"></div>
  <div class="modal">...</div>
</body>

Fixed visual result

Modal escaped the trap
Page card
page level Modal

The modal is a sibling of the overlay at page level.

Place app-level overlays and modals near the end of the body or in a portal/root layer.
Error 3

The modal has z-index, but no useful positioning

Developers often add z-index to a modal and expect it to jump above everything. But if the element is not positioned or not participating in a stacking order that accepts z-index, the value may not solve the layer problem.

Broken code

z-index without position 
.overlay {
  position: fixed;
  inset: 0;
  z-index: 20;
}

.modal {
  z-index: 100;
}

Broken visual result

Layer rule incomplete
Page content
incomplete Modal

The modal layer is not defined clearly.

z-index alone is not a complete modal positioning system.

Correct code

Positioned modal layer 
.overlay {
  position: fixed;
  inset: 0;
  z-index: 20;
}

.modal {
  position: fixed;
  inset: auto;
  z-index: 30;
}

Fixed visual result

Position and layer agree
Page content
defined Modal

The modal is positioned and layered above the overlay.

For modals, define both placement and layer order explicitly.
Error 4

The HTML order makes the overlay cover the modal

When two positioned elements are in the same stacking level, later elements can paint above earlier elements. If the overlay is inserted after the modal and both use similar z-index values, the overlay may cover the modal.

Broken code

Overlay after modal 
<div class="modal">...</div>
<div class="overlay"></div>

Broken visual result

DOM order fights layer order
Page content
covered Modal

The overlay is inserted after this layer.

When layers are not explicit, DOM order can make the overlay paint above the modal.

Correct code

Explicit layer order 
<div class="overlay"></div>
<div class="modal">...</div>

Fixed visual result

Overlay below modal
Page content
top layer Modal

The modal is inserted and layered above the overlay.

Use clear z-index values and sensible HTML order for overlay systems.
Premium pattern

A production-minded modal layer pattern

A reliable modal system uses named layer values, keeps modal and overlay close together in the DOM, and avoids placing modals inside transformed cards, sliders, headers, or small layout wrappers.

Premium code

Predictable modal stack 
<div class="modal-root">
  <div class="modal-overlay"></div>

  <section class="modal-dialog" role="dialog" aria-modal="true">
    ...
  </section>
</div>
:root {
  --layer-overlay: 1000;
  --layer-modal: 1010;
}

.modal-overlay {
  position: fixed;
  inset: 0;
  z-index: var(--layer-overlay);
  background: rgba(15, 23, 42, .64);
}

.modal-dialog {
  position: fixed;
  left: 50%;
  top: 50%;
  z-index: var(--layer-modal);
  transform: translate(-50%, -50%);
  width: min(100% - 32px, 480px);
}

Premium visual result

Modal system, not z-index guessing
Page content
clean layer Modal dialog

The overlay and dialog have predictable, named layers.

Premium modal CSS avoids random z-index numbers and makes the layer order obvious.

Fast practical rule

If your modal is behind the overlay, compare the overlay layer and the modal layer first. Then inspect the modal’s parents for stacking context traps like transform, opacity, filter, isolation, and positioned wrappers.

Debug checklist

  • Inspect the overlay and modal in DevTools and compare their computed z-index values.
  • Make sure both overlay and modal have a real position, usually position:fixed.
  • Keep the modal z-index higher than the overlay z-index.
  • Check whether the modal is inside a transformed, filtered, or positioned parent.
  • Move app-level modals near the end of the document or into a dedicated modal root.
  • Avoid random values like z-index:999999; use a small layer scale instead.
  • Check whether the overlay is stealing clicks with pointer-events.
  • Verify that the modal is not inside a header, slider, card, or overflow-hidden wrapper.
Best first move Temporarily lower the overlay z-index. If the modal appears, the issue is layer order.
Most common cause The overlay has a higher z-index than the modal.
Most sneaky cause A parent with transform traps the modal inside a lower stacking context.
Better mindset A modal should be a page-level layer, not a child of whatever section opened it.

Related fixes that can help

Modal behind overlay bugs are usually connected to z-index, stacking context, HTML structure, and invisible click-blocking layers.

Fix z-index not working If changing z-index does nothing, the real issue may be stacking context. Read this fix
Why is my button not clickable? If the modal opens but the close button or CTA cannot be clicked. Read this fix
Fix HTML structure problems If the modal is nested inside the wrong container or component. Read this fix
Why is my sticky header not staying on top? If headers, overlays, and modals are competing for the same top layer. Read this fix
Why is my mobile menu not opening? If the same overlay or layer bug is breaking a mobile menu. Read this fix
Why is my page wider than the screen? If the modal or overlay also creates horizontal overflow on mobile. Read this fix

Final takeaway

A modal behind overlay problem is usually not fixed by throwing a bigger z-index at the modal. The real fix is to understand which stacking context the modal belongs to and whether the overlay is above it.

Place the overlay and modal in a predictable page-level layer, give the overlay a lower layer than the modal, and avoid trapping the modal inside transformed or overflow-heavy parents.

Want more fixes like this?

Browse more z-index, overlay, and CSS debugging guides in the FrontFixer library.

CSS Fixes All Fixes

Why Is My Mobile Menu Not Opening?

by

Mobile menu not opening problems usually happen when the button and menu are not connected correctly, the wrong class is being toggled, the menu is still hidden in CSS, or another element is sitting on top of it.

Mobile Navigation Fix

Why is my mobile menu not opening?

A mobile menu can look like it should work but still stay closed when you tap the hamburger button. The cause is usually not random. The button may be toggling the wrong class, the checkbox label may not match the input ID, the menu may still be hidden by a stronger CSS rule, or an overlay may be blocking the menu completely.

HTML Fixes Responsive Fixes
  • Hamburger menu
  • HTML structure
  • CSS classes
  • Mobile navigation

What the bug looks like

You tap the hamburger icon, but the navigation stays closed, appears behind the page, flashes for a second, or opens but cannot be clicked.

Why it happens

The menu’s open state is not connected to the CSS rule that actually reveals the navigation.

What usually fixes it

Make the trigger, menu, open class, selector, z-index, and breakpoint rules all point to the same state.

Error 1

The button toggles one class, but the CSS expects another

This is one of the most common reasons a mobile menu is not opening. The HTML or JavaScript adds one class, but the CSS selector is written for a different class name.

Broken code

Class mismatch 
/* The button adds .active */
.menu-button.active {
  color: orange;
}

/* But the CSS opens only .is-open */
.mobile-menu.is-open {
  display: block;
}

Broken visual result

Button changed, menu closed
menu still closed
Page content

The icon changed state, but the navigation never received the class that reveals it.

The CSS and the menu state are speaking different languages.

Correct code

Same state name 
.mobile-menu {
  display: none;
}

.mobile-menu.is-open {
  display: block;
}

Fixed visual result

Menu state matches CSS
menu open
Page content

The menu opens because the class used by the state matches the class used by the CSS.

Use one clear open state and reuse that exact name everywhere.
Error 2

The checkbox and label are not connected

CSS-only hamburger menus often use a hidden checkbox. If the label’s for value does not match the checkbox id, tapping the hamburger does nothing.

Broken code

Wrong ID 
<input id="mobile-toggle" type="checkbox">
<label for="menu-toggle">Menu</label>

<nav class="mobile-menu">...</nav>

Broken visual result

Tap does not toggle
wrong target
No checkbox state

The hamburger label points to an ID that does not exist, so the menu never receives an open state.

The trigger exists, but it is connected to the wrong element.

Correct code

Matching ID 
<input id="menu-toggle" type="checkbox">
<label for="menu-toggle">Menu</label>

<nav class="mobile-menu">...</nav>

Fixed visual result

Trigger connected
checkbox toggled
Connected menu

The label toggles the right checkbox, and the CSS can reveal the navigation.

For CSS-only menus, the label and checkbox must be wired perfectly.
Error 3

The menu opens behind an overlay or another layer

Sometimes the mobile menu is technically open, but you cannot see or click it because an overlay, header, section, or transformed parent creates a stronger stacking layer above it.

Broken code

Layer problem 
.overlay {
  position: fixed;
  z-index: 1000;
}

.mobile-menu {
  position: absolute;
  z-index: 10;
}

Broken visual result

Menu hidden behind layer
Overlay is above the menu
The menu exists, but another layer wins the stacking order.

Correct code

Menu above overlay 
.site-header {
  position: relative;
  z-index: 1001;
}

.mobile-menu {
  position: absolute;
  z-index: 1002;
}

Fixed visual result

Menu visible and clickable
Overlay behind menu
The header and menu need a deliberate stacking plan.
Error 4

A media query keeps the menu hidden

A mobile menu can fail because the open selector is correct, but a later mobile rule still says display:none. In CSS, the rule that wins is the one with the right specificity and order.

Broken code

Later rule wins 
.mobile-menu.is-open {
  display: block;
}

@media (max-width: 768px) {
  .mobile-menu {
    display: none;
  }
}

Broken visual result

Open rule overridden
hidden by CSS
Rule conflict

The menu has an open class, but the breakpoint still hides it.

The open state loses because a later CSS rule keeps the menu hidden.

Correct code

Open state inside breakpoint 
@media (max-width: 768px) {
  .mobile-menu {
    display: none;
  }

  .mobile-menu.is-open {
    display: block;
  }
}

Fixed visual result

Open rule wins
visible
Rule order fixed

The hidden state and open state live in the same breakpoint, so the open state can win.

Put the mobile open selector where it can actually override the mobile hidden selector.
Premium pattern

A production-minded mobile menu pattern

A stronger mobile menu pattern uses clear HTML, a single open state, an accessible button, and CSS that reveals the navigation only when the parent state says the menu is open.

Premium code

State on the parent 
<header class="site-header" data-menu="closed">
  <a class="logo" href="/">Site</a>

  <button class="menu-button"
    aria-controls="mobile-menu"
    aria-expanded="false">
    Menu
  </button>

  <nav id="mobile-menu" class="mobile-menu">
    <a href="/">Home</a>
    <a href="/services/">Services</a>
    <a href="/contact/">Contact</a>
  </nav>
</header>

.mobile-menu {
  display: none;
}

.site-header[data-menu="open"] .mobile-menu {
  display: grid;
}

.site-header {
  position: relative;
  z-index: 1000;
}

Premium visual result

Clear state, clear menu
Stable navigation

The menu opens from one parent state, sits above content, and stays easy to debug.

Premium mobile menus avoid scattered states. One parent state controls the whole navigation.

Fast practical rule

If your mobile menu is not opening, do not start by changing random z-index values. First check whether the trigger changes the exact state that the CSS uses to reveal the menu. Then check rule order, structure, and layers.

Debug checklist

  • Check whether the hamburger button is actually being clicked or tapped.
  • Confirm the open class name in HTML, CSS, and any menu script is exactly the same.
  • For CSS-only menus, make sure the label for value matches the checkbox id.
  • Inspect the menu in DevTools and see whether it is hidden by display:none, opacity:0, visibility:hidden, or transform.
  • Check whether a media query overrides the open state after it is declared.
  • Check whether an overlay, header, or parent stacking context is covering the menu.
  • Confirm the menu is inside the parent expected by the selector.
  • Use aria-expanded and aria-controls so the menu state is easier to maintain.
Best first move Inspect the menu element and see whether the open class appears after tapping the button.
Most common cause The button toggles one class while the CSS is written for another class.
Most sneaky cause The menu opens, but it is behind an overlay or hidden by a later mobile rule.
Better mindset A mobile menu should have one obvious state that controls visibility, position, and layering.

Related fixes that can help

If your mobile menu is not opening, the surrounding problem may involve HTML structure, blocked clicks, z-index, or responsive CSS.

Why is my button not clickable? If the hamburger icon is visible but taps or clicks do nothing. Read this fix
Fix HTML structure problems If the menu selector depends on a parent-child structure that your HTML does not match. Read this fix
Fix z-index not working If the menu opens behind another layer, overlay, header, or section. Read this fix
Fix responsive design not working If the menu only breaks on mobile or at a specific breakpoint. Read this fix
Why is my page wider than the screen? If the mobile menu opens but creates horizontal scrolling. Read this fix
Horizontal scroll on mobile? If the menu, header, or nav links are pushing the viewport sideways. Read this fix

Final takeaway

A mobile menu not opening is usually a connection problem, not a mystery. The button, menu, class name, selector, breakpoint, and layer order all need to agree on what “open” means.

Start by checking whether the open state appears in DevTools. If it does not, the trigger is not connected correctly. If it does appear but the menu is still hidden, inspect CSS order, display rules, z-index, overlays, and parent structure.

Want more fixes like this?

Browse more HTML, CSS, and responsive debugging guides in the FrontFixer library.

HTML Fixes All Fixes

Why Is My Hover Effect Not Working?

by

A hover effect usually stops working when the selector does not match the element, another layer is blocking the pointer, a stronger CSS rule overrides the hover state, or the device does not actually support hover.

CSS Interaction Fix

Why is my hover effect not working?

A hover effect can fail in several sneaky ways. The button may not change color, the card may not lift, the dropdown may not open, or the effect may work on desktop but feel broken on mobile. The problem is usually not “hover is broken.” The real issue is selector targeting, CSS order, specificity, pointer events, overlays, disabled elements, or touch-screen behavior.

Browse CSS Fixes Browse All Fixes
  • Hover selector bugs
  • Pointer events
  • CSS specificity
  • Touch devices

What the bug looks like

The button does not change color, the card does not lift, the menu does not open, or the hover works only when your mouse is over a tiny part of the element.

Why it happens

The hover rule is either not matching, not winning, not receiving pointer input, or being tested on a device where hover does not behave normally.

What usually fixes it

Confirm the selector, inspect the active rule, remove blocking layers, add transitions to the base state, and design a touch-friendly fallback.

Error 1

The hover selector targets the wrong element

This is the simplest hover bug. The CSS is valid, but the selector does not match the element you are actually hovering. The browser is doing exactly what you asked. It is just not the element you meant.

Broken code

Wrong selector 
<a class="cta-button" href="#">
  Start fixing
</a>

.button:hover {
  background: #ff6a3d;
  color: white;
}

Broken visual result

Hover rule never matches
CTA area The button class is cta-button, but the CSS is targeting .button:hover. Start fixing
The hover effect looks broken because the selector and the HTML class do not match.

Correct code

Matching selector 
<a class="cta-button" href="#">
  Start fixing
</a>

.cta-button:hover {
  background: #ff6a3d;
  color: white;
}

Fixed visual result

Hover rule matches
CTA area The selector now targets the same class that exists in the HTML. Start fixing
The effect appears because the hover rule is attached to the correct element.
Error 2

A later CSS rule overrides the hover effect

Sometimes the hover selector is correct, but it still loses. The hover state may be crossed out in DevTools because a later rule or stronger selector keeps the old color, transform, or opacity.

Broken code

Hover loses cascade 
.card:hover {
  transform: translateY(-4px);
  background: #fff5ef;
}

.featured-card {
  transform: none;
  background: white;
}

Broken visual result

Hover is overridden
.card:hover transform: translateY(-4px) overridden
.featured-card transform: none wins
The hover rule exists, but another rule wins the final computed style.

Correct code

Hover wins intentionally 
.featured-card {
  background: white;
  transition: transform .2s ease, background .2s ease;
}

.featured-card:hover {
  transform: translateY(-4px);
  background: #fff5ef;
}

Fixed visual result

Hover wins
.featured-card base style base
.featured-card:hover transform active
The hover state now targets the same component and appears after the base style.
Error 3

An invisible overlay blocks the hover target

This is a sneaky one. An absolutely positioned layer, pseudo-element, or overlay can sit above the button. Your mouse is technically hovering the overlay, not the button underneath.

Broken code

Overlay steals pointer 
.card::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 2;
}

.card .button {
  position: relative;
  z-index: 1;
}

Broken visual result

Pointer hits overlay
Card content The button looks visible, but another layer is sitting above it. Hover me
Invisible overlay blocks hover
The hover target is visually there, but it is not receiving the pointer.

Correct code

Overlay ignores pointer 
.card::before {
  content: "";
  position: absolute;
  inset: 0;
  pointer-events: none;
}

.card .button {
  position: relative;
  z-index: 2;
}

Fixed visual result

Button receives hover
Card content The decorative layer is still there, but it no longer steals pointer input. Hover me
Overlay no longer blocks
Use pointer-events:none only on decorative layers that should not be interactive.
Error 4

The hover effect is being tested on a touch device

Mobile devices do not have a mouse cursor hovering above the screen. Some browsers simulate hover after a tap, some do not, and some leave hover-like states stuck. A hover-only interaction is not a safe mobile pattern.

Broken code

Hover-only UI 
.menu {
  display: none;
}

.nav:hover .menu {
  display: block;
}

Broken visual result

Touch has no real hover
Mobile menu The menu depends only on hover, so it may not open reliably on phones. Menu
Hover can be a nice desktop enhancement, but it should not be the only way to reveal important content.

Correct code

Hover plus focus 
.menu {
  display: none;
}

.nav:hover .menu,
.nav:focus-within .menu {
  display: block;
}

.nav-toggle {
  cursor: pointer;
}

Fixed visual result

Keyboard and tap friendlier
Mobile menu The interaction now supports hover and focus, making it less fragile. Menu
For serious mobile navigation, JavaScript state is often more reliable than hover-only behavior.
Premium pattern

A production-minded hover pattern

The stronger pattern treats hover as progressive enhancement. The base state works. The focus state works. Touch users are not blocked. Motion is smooth, but not required for the interface to make sense.

Premium code

Hover, focus, motion-safe 
.card {
  position: relative;
  border: 1px solid #e5e7eb;
  border-radius: 24px;
  background: #fff;
  transition:
    transform .2s ease,
    border-color .2s ease,
    box-shadow .2s ease;
}

.card:hover,
.card:focus-within {
  transform: translateY(-3px);
  border-color: #ffd2c2;
  box-shadow: 0 18px 38px rgba(255,106,61,.12);
}

.card::before {
  content: "";
  position: absolute;
  inset: 0;
  pointer-events: none;
}

@media (hover: none) {
  .card:hover {
    transform: none;
  }
}

Premium visual result

Hover is enhancement
Production-ready card

The component has a good base state, a hover state, a focus state, and a safer touch-device fallback.

Open fix
Premium hover is not just pretty. It is predictable, accessible, and less likely to break across devices.

Fast practical rule

If a hover effect is not working, inspect the element and force the :hover state in DevTools. If the rule appears but is crossed out, fix specificity or order. If the rule never appears, fix the selector. If the element never receives hover, check overlays and pointer events.

Debug checklist

  • Confirm the hover selector matches the actual class or element in the HTML.
  • Use DevTools to force :hover and see whether the rule becomes active.
  • Check whether the hover rule is crossed out by a later or stronger selector.
  • Check whether an overlay, pseudo-element, or absolute layer is sitting above the target.
  • Use pointer-events:none only on decorative layers that should not receive input.
  • Make sure transitions are placed on the base element, not only on the hover state.
  • Do not rely on hover-only behavior for important mobile interactions.
  • Add :focus or :focus-within when the element should also work by keyboard or tap.
Best first move Force :hover in DevTools before changing random CSS.
Most common cause The selector does not match the element you are actually hovering.
Most invisible cause An overlay or pseudo-element is sitting above the button and stealing the pointer.
Better mindset Hover should improve the interface, not be the only way the interface works.

Related fixes that can help

If hover is not working, the real cause may be selector targeting, z-index layering, pointer blocking, or a clickable element problem.

Why is my button not clickable? If a button looks visible but cannot be clicked or hovered properly. Read this fix
Why is my z-index not working? If the hover target is hidden behind another layer or trapped in a stacking context. Read this fix
Why is my CSS not updating? If you changed the hover CSS but the page still shows the old behavior. Read this fix

Final takeaway

A hover effect not working usually has a concrete cause: the selector is wrong, the rule is overridden, the element is not receiving pointer input, or the device does not support hover the way a desktop mouse does.

Start by forcing :hover in DevTools. Then check whether the rule matches, whether it wins, and whether another layer is blocking the target. Once those three questions are answered, the fix becomes much easier.

Want more fixes like this?

Browse more CSS interaction and layout debugging guides in the FrontFixer library.

CSS Fixes All Fixes

Why Is My Button Not Clickable?

by

Button not clickable bugs usually happen when the visible button and the real clickable layer are not the same thing. An invisible overlay, disabled state, pointer-events rule, or broken HTML structure can make a button look normal while clicks go nowhere.

Interaction Fix

Why is my button not clickable?

A button can look perfectly fine and still refuse to click. The color is right, the hover state may appear, the spacing looks clean, and the design seems finished. But the browser does not click what your eyes see. It clicks the topmost interactive layer under the pointer. If another element is covering the button, if pointer-events is wrong, if the button is disabled, or if the markup is not truly interactive, the UI can feel dead even though the visual design looks normal.

Browse All Fixes Explore HTML Fixes
  • Invisible overlays
  • Pointer-events bugs
  • Disabled states
  • Broken hit areas

What the bug looks like

The button is visible, styled correctly, and seems ready to work, but clicks do nothing, only part of the button responds, or the button works in one layout but not another.

Why it happens

The browser usually is not ignoring the button. Something in the stacking order, pointer behavior, disabled state, markup, or hit area is blocking the click.

What usually fixes it

Use DevTools to inspect the topmost layer under the cursor, then check pointer-events, disabled, semantic markup, and the real size of the clickable target.

Why a button can look clickable but still be dead

A button bug is often not a button-design bug. It is an interaction-layer bug. The visible button may be behind another layer, inside a disabled form state, covered by a pseudo-element, or visually larger than the actual clickable element.

This is why blindly changing colors, padding, or hover styles rarely fixes the problem. You need to find what element is actually receiving the click. The same idea appears in other FrontFixer layout bugs: with z-index problems, what appears visually on top may not be in the layer system you think; with dropdowns getting cut off, the issue may be a parent wrapper rather than the dropdown itself.

Error 1

An invisible overlay is stealing the click

This is the most common reason a button is not clickable even though it looks normal. A decorative layer, pseudo-element, full-card overlay, modal backdrop, or animation layer is placed above the button. The user thinks they are clicking the button, but the browser is clicking the invisible layer instead.

Broken code

Overlay wins 
.card {
  position: relative;
}

.card::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 5;
}

.card .button {
  position: relative;
  z-index: 1;
}

Broken visual result

Click blocked
Save changes

The button is visible, but an invisible layer is sitting above it and receives the click first.

Correct code

Clicks pass through 
.card::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 1;
  pointer-events: none;
}

.card .button {
  position: relative;
  z-index: 2;
}

Fixed visual result

Click reaches button
Save changes

The decorative layer no longer steals pointer events, and the real button is above it in the stacking order.

Error 2

pointer-events:none is on the wrong element

pointer-events:none can be useful on decorative layers, but it is dangerous on real interactive elements. If the button itself, or a parent wrapper, has pointer events disabled, the UI may render normally while ignoring clicks.

Broken code

Dead interaction 
.button {
  pointer-events: none;
}

Broken visual result

Looks active, ignores click
Checkout button pointer-events: none
Newsletter button parent blocks it
Card CTA no click target

The button can still look styled, but the browser is told not to treat it as a pointer target.

Correct code

Interactive target 
.button {
  pointer-events: auto;
}

.decorative-overlay {
  pointer-events: none;
}

Fixed visual result

Real button receives pointer
Checkout button clickable
Newsletter button clickable
Card CTA clickable

Pointer events should be disabled on decorative layers, not on the button users need to click.

Error 3

The button is disabled but still looks active

A disabled button is supposed to ignore clicks. The bug happens when the visual design does not make that disabled state obvious. Developers then spend time debugging JavaScript or CSS when the markup already says the button cannot be clicked.

Broken expectation

Markup says disabled 
<button class="button" disabled>
  Save changes
</button>

Broken visual result

Disabled state

Account settings

The button may look designed, but the HTML state blocks interaction.

disabled

If the button has disabled, it cannot be clicked until that state is removed.

Correct state

Active button 
<button type="button" class="button">
  Save changes
</button>

Fixed visual result

Enabled state

Account settings

The button is now semantically enabled and can receive clicks.

enabled

Good UI makes disabled and enabled states visually clear, so users and developers do not confuse them.

Error 4

The visual button is larger than the real clickable target

Sometimes the full visual shape looks like a button, but only a small text link inside it is actually clickable. This creates the frustrating “only part of my button works” bug. The visual hit area and the real interactive element must match.

Broken structure

Tiny real target 
<div class="button-look">
  <a href="/checkout">Checkout</a>
</div>

Broken visual result

Only a small area works
Big visual button
Real link
The visual button is large, but the actual clickable anchor is much smaller.

Users click the large visual area, but only the small nested link actually receives navigation.

Correct structure

Full target 
<a class="button" href="/checkout">
  Checkout
</a>

Fixed visual result

The full button is clickable
Full clickable button
The link itself owns the full visual shape, so the hit area matches what users see.

The clickable element should usually be the same element that creates the visual button shape.

Error 5

The HTML structure is invalid or fighting the browser

Button bugs can also come from invalid structure: buttons inside links, links inside buttons, clickable wrappers inside clickable wrappers, or custom components that use a <div> where a real <button> should be used.

Fragile markup

Nested interaction 
<a href="/pricing">
  <button>View pricing</button>
</a>

Why this is risky

Nesting interactive elements makes click behavior harder to predict and can create accessibility problems. The browser, screen readers, and keyboard navigation may not treat the UI the way you expect.

Cleaner markup

One interactive element 
<a class="button" href="/pricing">
  View pricing
</a>

<button type="button" class="button">
  Open modal
</button>

Better rule

Use a link when the action navigates somewhere. Use a button when the action changes something on the current page. Do not nest one interactive element inside another.

Fast practical rule

If your button is not clickable, do not start by rewriting the button style. First use DevTools to inspect what element is actually under the cursor. If the selected element is not the button, you have a layer or hit-area problem. If it is the button, check disabled, pointer-events, event listeners, and semantic markup.

How to debug the click target in DevTools

Open DevTools and use the element picker. Move the cursor over the button and watch which element gets highlighted. If an overlay, pseudo-element, wrapper, or backdrop is selected instead of the button, the browser is telling you exactly why the click does not reach the button.

Then temporarily disable suspicious CSS rules: z-index, position:absolute, inset:0, pointer-events, opacity, and overlay pseudo-elements. The goal is not to guess. The goal is to reveal the real click layer.

Quick temporary debug CSS

Find blockers 
* {
  outline: 1px solid rgba(255, 106, 61, .35);
}

.card::before,
.overlay,
.backdrop {
  outline: 3px solid red;
}

Safe CTA pattern

Navigation button 
<a class="button" href="/fixes/">
  Browse fixes
</a>
.button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 44px;
  padding: 0 18px;
  border-radius: 999px;
  background: #ff6a3d;
  color: #fff;
  position: relative;
  z-index: 2;
}

Why this pattern is safer

The link owns the full button shape. The hit area matches the visual shape. The element is semantically correct for navigation, and the position plus z-index gives it a predictable place if decorative layers exist around it.

For actions that open a modal, submit a form, or change the current interface, use a real <button> instead.

Debug checklist

  • Use DevTools element picker and confirm the button is the element actually under the cursor.
  • Check for overlays, pseudo-elements, full-card links, modal backdrops, sticky bars, or wrappers covering the button.
  • Inspect ::before and ::after on parent containers.
  • Look for pointer-events:none on the button or any ancestor.
  • Check whether the button has the disabled attribute.
  • Confirm the visual hit area and the real clickable element are the same size.
  • Avoid nesting buttons inside links or links inside buttons.
  • Use <a> for navigation and <button> for in-page actions.
  • Test mobile separately, because overlays and menu layers often change across breakpoints.
  • Do not assume the CSS class is broken until you know what layer receives the click.
Best first move Inspect the exact element under the cursor before editing the button styles.
Most common false fix Raising the button z-index without checking whether the overlay should use pointer-events:none.
Most overlooked cause A pseudo-element covers the whole card and silently steals every click.
Better mindset A button not clickable bug is usually about hit testing, not just styling.

Related fixes that can help

If your button problem turns out to be structural, layered, or responsive, these FrontFixer guides are the next places to check.

Fix z-index not working If the button is behind another layer or the wrong element is sitting on top. Read this fix
Fix HTML structure problems If the clickable UI is built from invalid markup or the wrong semantic element. Read this fix
Why is my dropdown getting cut off? If the button belongs to a menu, dropdown, or layered component that is being clipped. Read this fix

Final takeaway

When a button is not clickable, the visible design is not enough evidence. The browser clicks the real topmost interactive layer, not the layer you intended users to click. That means invisible overlays, pseudo-elements, disabled states, pointer-event rules, and invalid markup can all make a normal-looking button feel broken.

Start by identifying the actual click target in DevTools. Then remove blockers, restore pointer events, fix disabled states, and make sure the visual button and the real interactive element are the same thing. Once you debug the interaction layer, button bugs become much easier to fix.

Want more fixes like this?

Explore the full FrontFixer fixes library and keep debugging with practical guides built for real front-end layout and interaction problems.

Browse All Fixes Explore HTML Fixes