What happened to the old image rollover script?

What the records show

The Script Shelf 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:

<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>

.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 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 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 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 explains why naming the failure modes works better than naming the effect. The keyboard prompting thread 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 explains what to check before you leave it there.