A stylesheet handles reduced motion with a universal rule that sets animation-duration and transition-duration to 0.01ms !important instead of using animation: none. Why the near-zero duration rather than none, and what does that blanket reset still get wrong?

## The rule being discussed A version of this block appears in most modern resets: ```css @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } ``` Every line is doing a specific job, and the interesting one is the choice of `0.01ms` over `none`. ## Why a near-zero duration and not none CSS animations and transitions dispatch events when they finish: `transitionend`, `animationend`, and for repeated animations `animationiteration`. Interfaces lean on these more than people realise. A dialog removes itself from the DOM on `transitionend` after fading out; a toast releases its slot when the exit animation ends; a wizard advances after a slide completes. If you kill the motion with `animation: none` or `transition: none`, the animation or transition never runs, so the terminating event never fires, and that listener waits forever. The visible bug is not "no animation" — it is a dialog that never unmounts or a control that stays disabled. A duration of `0.01ms` sidesteps this. The animation genuinely runs; it just finishes within the same frame, so the user perceives an instant state change while the event still dispatches on schedule. It is a pragmatic hack around a coupling between visual styling and application control flow, and being able to explain that coupling is the point of the question. `animation-iteration-count: 1` is there for the same family of reasons: an `infinite` animation never ends, so shortening its duration alone would leave it flickering forever at high frequency rather than settling. Capping the count makes it terminate. `scroll-behavior: auto` is a separate concern that happens to live in the same block — it undoes `scroll-behavior: smooth`, whose animated scrolling is exactly the kind of large-area motion the preference is about. ## What the reset still gets wrong **It flattens rather than substitutes.** The preference asks for less motion, not for a page where nothing ever changes gracefully. Collapsing every duration to zero throws away the affordance the animation carried — the sense of where a panel came from, which element the new content replaced. A better per-component answer is often to keep a short opacity crossfade and drop only the movement. **It requires `!important` on a universal selector.** That is a large cascade hammer. Once it is in place, a component that legitimately wants a gentle 150ms fade under reduced motion cannot have one without escalating to `!important` itself. Teams that later adopt a token-based approach usually have to unwind this rule first. **It only knows about two properties.** Motion produced any other way is untouched: animation driven from script, an autoplaying `<video>` background, an animated GIF or APNG, a canvas loop, a carousel that advances on a timer, smooth scrolling implemented in code rather than through `scroll-behavior`. The universal selector gives an illusion of totality that does not survive contact with a real page. **It cannot see third-party or shadow content.** Styles inside a shadow root are not reached by a document-level universal selector unless the component opts in, and an inline `style` attribute written by a widget outperforms author rules unless the reset's `!important` happens to apply to that property. **It has no concept of essential motion.** Some motion is the content or the only feedback available: a loading indicator, a progress bar, a video the user pressed play on. Zeroing it can leave the interface silent about work in progress. Small, localised, non-translating indicators are generally acceptable under reduced motion, and a blanket rule cannot make that distinction. ## How to use it well Keep the reset, but treat it as a floor. It guarantees that anything nobody thought about is at least not sliding across the screen, and it covers stylesheets you do not control. Above that floor, handle motion per component: decide for each animation whether reduced motion means removing it, substituting a crossfade, or leaving it alone because it is essential. Where you have a design system, express duration as a custom property gated once in `:root` so components read a token instead of being overridden by a universal `!important` rule — that keeps a single control point without the cascade collateral damage. Finally, verify it. Turn the OS setting on and walk the flows that depend on end events; that is where a `none`-based reset fails loudly and where the 0.01ms version quietly keeps working.