Closed
Description
Describe the issue
In the current component setup of Gooey Nav, there is a UX inconsistency involving <li>
elements that have onClick
handlers applied, particularly when combined with styling and nested <a>
tags.
⚠️ Problem Summary
- When
onClick
is placed on the<li>
, clicking anywhere within the styled<li>
triggers the animation/effect, but navigation does not occur. - When
onClick
is moved inside the<a>
tag:- Both the animation and navigation work, but The click target is limited — users must click exactly on the anchor text, not the surrounding area (like padding or borders).
- This was mentioned in this Issue [BUG]: components/gooey-nav #256 but the implementation is false.
- I’ve recorded a screen capture of the issue. Video Link
🖱️ Pointer Device Confusion
- On devices with a pointer (mouse, touchpad, stylus, etc.), the cursor changes to a pointer (hand) over the entire
<li>
, giving the impression that the whole area is clickable. - However, clicking on there (outside the actual
<a>
but inside<li>
) does nothing — no animation, no navigation. - This results in poor UX and can be confusing to users, especially when the
<li>
is styled with borders, padding, or background effects.
💥 Expected Behavior
- The entire visible
<li>
area (including padding and borders) should:- Trigger the animation/effect and
- Navigate to the linked page or section when clicked — not just the anchor text itself.
I just wanted to say — I was working on this (related to Issue #256), and I realize I missed the chance to inform @DavidHDev when I should have. I assumed the original PR would be updated and resubmitted, so I held off, but that was my mistake. Apologies for not speaking up earlier.
Reproduction Link
No response
Steps to reproduce
Try Clicking on the edge of nav button using mouse (when the cursor changes from default/arrow to pointer/hand) the animation and navigation won't trigger.
Validations
- I have checked other issues to see if my issue was already reported or addressed