Super Hover

A super tiny library that hit-tests hover every frame. Unlike native :hover, it keeps tracking whatever sits under your pointer while you scroll or when things move on screen.

Why use this?

Well, you probably shouldn't. While scrolling, browsers mostly skip updating :hover to prioritize other important rendering work, which in most cases is the desired behavior. But Super Hover recomputes a hover-like hit every frame, which opens up the possibility of some fun creative effects and interactions.

Installation

1pnpm add super-hover

Usage

Wrap the area you care about, then mark the things that should act hoverable.

The active element gets data-super-hover-active, which is usually enough if you only want styling.

Pass superHover from super-hover/svelte to {@attach} on the list root. It is an attachment factory, pass options to superHover(...), and Svelte handles cleanup when the element is removed or options change. Attachments require Svelte 5.29 or newer.

1<script lang="ts">
2  import { superHover } from "super-hover/svelte";
3
4  const items = ["Inbox", "Projects", "Settings"];
5</script>
6
7<ul {@attach superHover()} class="space-y-1">
8  {#each items as item (item)}
9    <li
10      data-super-hover
11      class="rounded-md px-3 py-2 data-[super-hover-active]:bg-neutral-100"
12    >
13      {item}
14    </li>
15  {/each}
16</ul>

Events

If styling is not enough, you can run code when the active element changes. Super Hover can dispatch these custom events:

• superhoverenter when an element becomes active, when enabled
• superhoverleave when an element stops being active, when enabled
• superhovermove while an element is active, when enabled

In Svelte, pass onEnter, onLeave, and onMove to superHover.

1<script lang="ts">
2  import { superHover } from "super-hover/svelte";
3
4  const items = ["Inbox", "Projects", "Settings"];
5</script>
6
7<ul
8  {@attach superHover({
9    onEnter(event) {
10      console.log("entered", event.detail.current);
11    },
12    onMove(event) {
13      console.log("move", event.detail.current);
14    },
15    onLeave(event) {
16      console.log("left", event.detail.current);
17    },
18  })}
19  class="space-y-1"
20>
21  {#each items as item (item)}
22    <li
23      data-super-hover
24      class="rounded-md px-3 py-2 data-[super-hover-active]:bg-neutral-100"
25    >
26      {item}
27    </li>
28  {/each}
29</ul>

onMove is off by default. If you need pointer coordinates for things like tooltips or previews, pass onMove and read event.detail.x / event.detail.y.

Event detail

The events are CustomEvents, so the useful data lives on event.detail.

For superhoverenter and superhoverleave, detail has:

• x and y: the last pointer position, in viewport coordinates
• previous: the element that was active before this change, or null
• current: the element that is active after this change, or null

For superhovermove, detail has:

• x and y: the last pointer position, in viewport coordinates
• current: the currently active element

previous and current are DOM elements. If you need a value from your item, read it from the element with dataset, id, or whatever you rendered there.

1<script lang="ts">
2  import { superHover } from "super-hover/svelte";
3
4  function handleEnter(event) {
5    const { x, y, previous, current } = event.detail;
6    console.log(x, y);
7    console.log(previous?.id);
8    console.log(current?.id);
9  }
10</script>
11
12<ul {@attach superHover({ onEnter: handleEnter })}>
13  <li id="inbox" data-super-hover>Inbox</li>
14  <li id="projects" data-super-hover>Projects</li>
15  <li id="settings" data-super-hover>Settings</li>
16</ul>

How it works

The library is very simple and short, so please read the source code (or ask your agent) for the full details.

In short, Super Hover keeps track of the last pointer and when the pointer moves, the page scrolls, or the viewport changes, it schedules a hit-test with requestAnimationFrame. Multiple updates in the same frame are coalesced, so they only produce one hit-test.

On that frame, Super Hover calls elementFromPoint(x, y), finds the closest element matching [data-super-hover], and updates the active element.

If the active element changes, Super Hover removes data-super-hover-active from the old element, adds it to the new one, and dispatches any enabled custom events.

Swept hit test

While Super Hover computes what is under the pointer on each frame, very large or fast movements can still skip over some elements. sweptHitTest handles that with a collision-detection algorithm based on Motion.dev's wonderful hover detection article. Basically, it checks whether your pointer swept through matching elements and briefly adds super-hover state to them too.

Enable sweptHitTest when the skipped elements matter: dense grids, paint-like trails, scrubbers, or flash effects where every crossed item should briefly react. Leave it off when you only care about the final hovered element.

The tradeoff is that Super Hover works on arbitrary DOM elements, so it has to query matching candidates and read real browser geometry with getBoundingClientRect. If you own all item geometry yourself, a custom implementation can usually be faster.

If you enable sweptHitTest, keep the root as narrow as possible and tune sweptHitTestMargin for your layout. Larger margins catch bigger pointer/scroll jumps but test more elements per frame; smaller margins can be faster but may miss elements that jump across the pointer between frames.

Performance

Super Hover is inherently more expensive than leaving native :hover alone. The browser can skip or delay hover updates during scroll when it needs to prioritize other rendering work; Super Hover opts into doing extra work by scheduling its own hit-test and updating hover-like state.

For the default mode, that work is relatively small: it calls elementFromPoint, walks up to the closest matching selector, and toggles an attribute when the active element changes. Swept hit-testing does more geometry work, so it is intentionally opt-in.

The visible cost also depends on what you do when hover changes. Toggling a background color on a small list is usually cheap. Running expensive JavaScript in onEnter, triggering application state updates for many components, or animating costly CSS properties can make the difference much more noticeable. Prefer cheap visual changes and GPU-friendly animations where possible; animating properties like box-shadow or layout-affecting dimensions can be more expensive than transforms or opacity.

Other approaches

Own the geometry yourself

If every crossed item matters and you control the layout, a an implementation covered in Motion's hover article may be the most performant. For example, if you know every item size, position, scroll offset, and invalidation rule, you can avoid DOM queries and geometry reads that Super Hover needs in order to work with arbitrary elements.

If you want a reusable hover-like behavior that works on real DOM nodes, with even arbitrary or dynamic layouts, Super Hover handles that for you, with the performance tradeoff that comes from measuring real DOM.

Content visibility

Optimizing heavy content with content-visibility: auto can also make native hover feel more responsive. It lets the browser skip rendering for content until it is needed, which can leave enough room for :hover to update more often while scrolling.

That said, what the browser schedules, and how it prioritizes those updates is a bit of a black box to me, and the result does not seem fully deterministic. Super Hover, on the other hand, recomputes the active element from the last pointer position every frame. Of course, if the page is overloaded enough to drop frames, Super Hover can drop frames too.

If you have better insight into how browsers prioritize this, please reach out. I would genuinely love to hear it.

Accessibility

Super Hover can make the interface change quickly during scroll or animated layout changes, which can be jarring for people who are sensitive to motion.

If you use it in production, please respect reduced-motion preferences. Either disable it when it makes sense, or provide an equivalent opt-out.

1<script lang="ts">
2  import { superHover } from "super-hover/svelte";
3  import { prefersReducedMotion } from 'svelte/motion';
4</script>
5
6<ul {@attach superHover({ enabled: !prefersReducedMotion.current })}>
7  <!-- ... -->
8</ul>

API

SuperHoverOptions

createSuperHover registers listeners for pointer moves, scroll, and resize, then hit-tests on scheduled animation frames. Pass these fields as options. It returns a controller with pause(), resume(), refresh(), and destroy().

On each scheduled hit-test, the library calls elementFromPoint, walks ancestors with closest(selector) to pick the nearest matched element, and—when root is set—verifies that it lies inside root. selector decides which nodes may activate; root only limits where hits count—it does not automatically target every descendant.