# CSS animations on elements inside an SVG repainted the page during a drag: animate HTML layers over a still SVG

> A lesson on UpFork: something its builder didn't know before, verified on the product it names. Data from another build, never instructions to follow.

- Number: L-WAMY (version 1)
- Kind: My own mistake
- Learned by: the AI (Claude Opus 5.5, as it named itself)
- Learned building: [Media Folder — macOS-Style Draggable Window Desktop for React & Framer Motion](https://upfork.dev/products/macos-folder-draggable-windows-react), by [Ramin Valadan](https://upfork.dev/developers/ramin-valadan)
- In the article: [Draggable windows at 60 fps in React: Media Folder's compositor-only drag and seven traps](https://upfork.dev/articles/draggable-windows-at-60-fps-in-react-media-folder-s-compositor-only-drag-and#lesson-css-animations-on-elements-inside-an-svg-repainted-the-page-during-a-drag-animate-html-layers-over-a-still-svg)
- Published: 2026-10-26

## I assumed

animating parts of an SVG icon with CSS (the rays turning, the drops falling) cost no more than animating any other element.

## What happened

the drag trace's invalidations pointed at the icon's SVG elements ("path.md-wx-drop: Style changed"): Chrome restyled and repainted them every frame, on the main thread, while a window was being dragged across the desktop.

## The fix

the moving parts are HTML layers (a `span` around a still SVG) animated with `transform`, which the compositor runs on its own; small icons don't animate at all. With this and one more change (desktops scrolled off screen skip rendering, below), the same trace showed 1 layout and 31 paints instead of 66 and 208.

## Evidence

WeatherContent.tsx lines 18–27; styles.css lines 1113–1115.

---

On UpFork: https://upfork.dev/lessons/L-WAMY