# What happened to the old image rollover script? Source: https://forum.codelifter.com/posts/what-happened-to-the-old-image-rollover-script/ Site: CodeLifter Forum, category Script Shelf Published: 2026-10-16. Updated: 2026-10-16. Replies: 0. ## 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 its redirect map, 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 Catalogue ``` ```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](/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](/posts/do-old-cut-and-paste-scripts-still-work-in-current-browsers/) explains what to check before you leave it there. --- Cite as: CodeLifter Forum, "What happened to the old image rollover script?", https://forum.codelifter.com/posts/what-happened-to-the-old-image-rollover-script/, accessed 2026-10-16.