# What happened to the old image rollover script?

Source: https://codelifter.com/forum/posts/what-happened-to-the-old-image-rollover-script/
Site: CodeLifter Forum, category Script Shelf
Published: 2026-10-16. Updated: 2026-11-03. Replies: 2.

## Question by CodeLifter editors (staff), 2026-10-16

It was not restored, because the editors cannot trace a CodeLifter rollover page in the surviving link records, and the effect no longer needs a script. Two images and a CSS `:hover` rule do the swap. Add `:focus-visible` so keyboard users see the same change, and keep anything important out of the hover state.

## What the records show

The [Script Shelf](https://codelifter.com/scripts/) lists every old script the editors can tie to a name and an address: fifteen of them, taken from links to the original site that still exist and from the original site's archived pages, checked on 2026-10-15. An image rollover is not among them. That list is not the full original catalogue, so a rollover page may well have existed. If you have a working link to one on the old site, post it in this thread so the shelf can be checked against it.

What the shelf does show is where the old scripts went. Six became reviewed prompts, five were replaced by something built into the browser, and four were retired. A rollover would fall in the second group.

## What a rollover script did

The common pattern of that era was a pair of images and two event handlers: on `mouseover`, change the `src` of the image to the highlighted version; on `mouseout`, change it back. Scripts usually preloaded the second image so the swap did not flash. It worked with a mouse and nothing else: no keyboard focus, no touch, and nothing for a screen reader beyond the first image's alt text.

## Can you keep an old rollover that still works?

Probably, in the narrow sense: `mouseover` and `mouseout` still fire for a mouse, and swapping an image `src` is ordinary DOM code. The problems are the ones it always had. Keyboard users never see the highlighted state, touch users may get it stuck, and inline `onmouseover="..."` attributes are hard to audit next to the rest of your markup. If the rollover is on a link people need to find, replace it with the CSS version below. If it is pure decoration on a page nobody maintains, it can wait until you next edit the file.

## The CSS version

Put both images inside the link and let CSS decide which one shows:

```html
<a class="swap" href="/catalogue/">
  <img src="catalogue.png" alt="Catalogue" width="200" height="120">
  <img class="swap-on" src="catalogue-on.png" alt="" width="200" height="120">
</a>
```

```css
.swap { position: relative; display: inline-block; }
.swap-on { position: absolute; inset: 0; opacity: 0; }
@media (hover: hover) {
  .swap:hover .swap-on { opacity: 1; }
}
.swap:focus-visible .swap-on { opacity: 1; }
@media (prefers-reduced-motion: no-preference) {
  .swap-on { transition: opacity 150ms; }
}
```

Why each part is there:

1. The second image has `alt=""`. MDN's [img reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img) says an empty alt marks an image as not a key part of the content, so non-visual browsers may skip it. The link's name comes from the first image only.
2. `:hover` sits inside `@media (hover: hover)`. MDN's [:hover page](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:hover) warns that on touchscreens the pseudo-class "might never match, match only for a moment after touching an element, or continue to match" until another element is touched. The [hover media feature](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/hover) tests whether the primary input can hover conveniently, so phones skip the effect instead of getting stuck in it.
3. `:focus-visible` gives the same change when someone tabs to the link. MDN describes it as matching when the element has focus and the browser decides focus should be made evident.
4. The fade runs only when the visitor has not asked the system to reduce motion, using `prefers-reduced-motion`.

Both images download with the page, so there is nothing to preload.

## Old and new side by side

| | Script rollover | CSS rollover |
|---|---|---|
| Trigger | `mouseover` and `mouseout` handlers | `:hover` and `:focus-visible` |
| Keyboard | No change on focus | Same change on focus |
| Touch | Often stuck in one state | Effect skipped where hover is not convenient |
| Works with JavaScript off | No | Yes |
| Code to maintain | Handlers per image, preload list | One rule set for every `.swap` link |

## If you ask an assistant for one

Ask for the behaviour, not "a rollover script", or you may get the 1999 pattern back with `onmouseover` attributes. Lines worth putting in the prompt:

- "Use CSS only: `:hover` inside `@media (hover: hover)`, plus `:focus-visible`. No JavaScript."
- "The second image is decorative: `alt=""`."
- "Do not put any text or link that only appears on hover."
- "Wrap any transition in `prefers-reduced-motion: no-preference`."

[How to write a coding prompt](https://codelifter.com/prompts/how-to-write-a-coding-prompt/) explains why naming the failure modes works better than naming the effect. The [keyboard prompting thread](/forum/posts/how-do-i-prompt-for-javascript-that-works-with-a-keyboard/) covers the same idea for scripts that do need JavaScript, and if you still have an old rollover pasted into a page, [the thread on whether old cut-and-paste scripts still work](/forum/posts/do-old-cut-and-paste-scripts-still-work-in-current-browsers/) explains what to check before you leave it there.

## Reply 1 by CodeLifter editors (staff), 2026-10-30

**Does :focus-visible work in all current browsers?** Yes. MDN's [:focus-visible page](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:focus-visible) marks it Baseline widely available, working across browsers since March 2022. The pseudo-class matches when an element has focus and the browser decides, by its own heuristics, that the focus should be shown. MDN's example: when a button is clicked with a pointing device, focus is generally not shown, but when someone tabs to it, it is. So a keyboard user tabbing to the rollover link gets the highlighted image, while a mouse click usually does not leave it showing. That is why the CSS in the opening post uses `:focus-visible` rather than `:focus`. If you must support a browser older than that, MDN suggests repeating the focus styling under `:focus` inside an `@supports` test, and notes that an old browser with no custom `:focus` rule still shows its native outline, which may be enough. The page also gives a contrast requirement that is easy to miss on an image swap. WCAG 2.1 success criterion 1.4.11, Non-text Contrast, asks for a visible focus indicator of at least 3 to 1. A highlighted image that differs only slightly from the plain one may not meet that, so keep the browser's own outline on the link as well, and do not add `outline: none` to `.swap`.

## Reply 2 by CodeLifter editors (staff), 2026-11-03

**Does a hover effect work on a touchscreen laptop?** It depends on which input the browser treats as primary, and CSS can ask about both. The opening post wraps the rollover in `@media (hover: hover)`, which tests the primary input. MDN's [any-hover page](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/any-hover) describes the companion feature: `any-hover` tests whether any available input mechanism can hover. It takes two values, `hover`, when one or more inputs can hover conveniently, and `none`, when none can or there is no pointing device. It has worked across browsers since December 2018. On a laptop with a touchscreen and a trackpad, `(any-hover: hover)` can match even when the primary input is touch, so a rule written with `any-hover` shows the effect to the trackpad user, while `hover` may hide it from everyone on that device. For a decorative image swap, `hover` is the safer choice: nobody loses anything if the effect is skipped. For a control that only reveals itself on hover, neither query is enough, and the opening post's rule applies: do not put anything people need in the hover state. Pair either query with `:focus-visible` so keyboard users get the same change.

---
Cite as: CodeLifter Forum, "What happened to the old image rollover script?", https://codelifter.com/forum/posts/what-happened-to-the-old-image-rollover-script/, accessed 2026-11-12.