DEV Community: Danny Holloran

CSS User Preference Media Queries: Build Accessible Experiences Without JavaScript

Danny Holloran — Sun, 14 Jun 2026 15:03:20 +0000

Your users have already told your browser what they need. They've toggled "Reduce Motion" in System Settings, switched their OS to dark mode, or cranked up contrast because their display washes out in sunlight. The question is whether your CSS is listening.

User preference media queries let you respond to those signals directly in CSS — no window.matchMedia, no state management, no JavaScript overhead. They've been creeping into browser support for years, but as of 2026 all four major ones are universally supported and underused. Here's how to put them to work.

`prefers-reduced-motion`: Stop Animating People Into Headaches

Motion on the web can be genuinely harmful. For people with vestibular disorders, autoplay animations and parallax effects can trigger vertigo, nausea, or migraines. The prefers-reduced-motion media query maps directly to the "Reduce Motion" accessibility preference in macOS, Windows, iOS, and Android.

The pattern is to write your animated default, then strip it back for users who opt out:

.hero-banner {
  animation: slide-in 0.6s ease-out both;
}

@media (prefers-reduced-motion: reduce) {
  .hero-banner {
    animation: none;
  }
}

A cleaner pattern inverts this — start from no animation and only add it when motion is okay:

@media (prefers-reduced-motion: no-preference) {
  .hero-banner {
    animation: slide-in 0.6s ease-out both;
  }
}

This approach means users who haven't touched the setting still get animations (no-preference is the default), but you're making motion opt-in at the code level rather than opt-out. It also makes it easier to audit during a review — every animated element lives inside a no-preference block.

Don't nuke everything with a blanket * { animation: none } rule. Focus indicators and loading spinners may rely on animation to communicate state. Audit each one and decide whether to remove, slow down, or replace with a static alternative.

`prefers-color-scheme`: Native Dark Mode Without the Toggle

If your app ships its own dark mode toggle, prefers-color-scheme lets you default to whatever the user's OS is already set to — and it updates instantly when they switch, no page reload required.

The typical setup pairs it with CSS custom properties:

:root {
  --bg: #ffffff;
  --text: #111111;
  --surface: #f4f4f4;
  --border: #d1d1d1;
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #0f0f0f;
    --text: #e8e8e8;
    --surface: #1c1c1c;
    --border: #2e2e2e;
  }
}

body {
  background: var(--bg);
  color: var(--text);
}

Everything else in your stylesheet uses the custom properties, so theme switching happens in exactly one place. If you want to layer a user-controlled toggle on top, store the override in a data-theme attribute on <html> and let CSS check that first:

[data-theme="light"] {
  --bg: #ffffff;
  --text: #111111;
}
[data-theme="dark"] {
  --bg: #0f0f0f;
  --text: #e8e8e8;
}

@media (prefers-color-scheme: dark) {
  :root:not([data-theme]) {
    --bg: #0f0f0f;
    --text: #e8e8e8;
  }
}

No attribute = fall back to the OS setting. User hits the toggle = set the attribute. Clean layering, no JavaScript required for the default path.

`prefers-contrast`: Don't Assume Your Palette Is Readable

prefers-contrast responds to Windows' "High Contrast" mode and macOS's "Increase Contrast" accessibility setting. The two useful values are more (user wants higher contrast) and less (some users with light sensitivity prefer reduced contrast).

.card {
  border: 1px solid var(--border);
  background: var(--surface);
}

@media (prefers-contrast: more) {
  .card {
    border: 2px solid currentColor;
    outline: 2px solid currentColor;
  }
}

This is most valuable for subtle UI elements — muted borders, low-contrast placeholder text, ghost buttons. Those choices look polished on a calibrated display but disappear for users with low vision or in bright environments. A prefers-contrast: more block can harden those edges without touching the default design at all.

`forced-colors`: Respect Windows High Contrast Mode

forced-colors: active fires when Windows High Contrast Mode (or the broader Forced Colors spec) is enabled. The OS overrides most of your colors with a restricted system palette — which is intentional. The problem is it can erase things you're using color to communicate: custom focus rings, SVG icon fills, disabled state styling.

The answer isn't to fight the OS. Let the forced palette do its job, but use the CSS system color keywords to opt specific elements into the forced palette explicitly:

@media (forced-colors: active) {
  .icon {
    fill: ButtonText;
  }

  .badge {
    border: 1px solid ButtonText;
  }
}

This doesn't restore your brand colors — it hands off to the OS palette, which is exactly what forced-colors users expect. Background images and decorative SVGs will still disappear, and that's fine; they're decorative. What matters is that your UI's meaning survives.

Putting It Together

None of these require a framework, a library, or a line of JavaScript. They're hooks into decisions users have already made about how they need to experience the web. Start with prefers-reduced-motion if your site has any animation. Layer in prefers-color-scheme if you're not responding to OS theme. Add prefers-contrast and forced-colors blocks where your UI relies on subtle visual cues.

Users who need these settings have already done their part. Meeting them there is the smallest lift with the biggest payoff — and it's pure CSS.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Vue 3.6 Vapor Mode: Opt Out of the Virtual DOM

Danny Holloran — Thu, 11 Jun 2026 21:10:23 +0000

The virtual DOM has been Vue's engine room since day one. It's the layer that diffs what changed in your component tree and figures out the minimal DOM updates needed. For most apps, it's fast enough that you never think about it. But "fast enough" has always meant there was overhead you were silently paying — and now Vue is letting you opt out.

Vue 3.6 ships Vapor Mode as a stable, opt-in compilation strategy. Components that use it skip the virtual DOM entirely. Instead of generating VNodes that get diffed at runtime, the compiler generates direct DOM operations — the same approach that makes SolidJS and Svelte 5 so fast. The benchmarks are striking: up to 97% faster renders in component-heavy scenarios, with bundle sizes 20–50% smaller for Vapor-only components. Vue can now mount 100,000 components in roughly 100ms, which puts it squarely in the same performance tier as SolidJS.

How Opting In Works

The upgrade path is intentionally low-friction. You don't switch your whole app at once. Vapor is a per-component choice, and it coexists freely with your existing virtual DOM components in the same tree.

The simplest way to opt in is a single attribute on your <script setup> tag:

<script setup vapor>
import { ref } from "vue";

const count = ref(0);
</script>

<template>
  <button @click="count++">Clicked {{ count }} times</button>
</template>

That's it. The same ref, the same template syntax, the same Composition API you already know — just with the vapor attribute telling the compiler to generate direct DOM instructions instead of a VNode tree. Alternatively, you can name the file MyComponent.vapor.vue to opt in without touching the script block, which is handy when you want to experiment without modifying source files.

The compiler transform is where the magic happens. A Vapor component's <template> compiles to something that creates DOM nodes once and then surgically updates them when reactive state changes — no diffing, no intermediate object allocations. The reactivity system (still Proxy-based under the hood, now enhanced with the new Alien Signals model) drives granular updates directly against the real DOM.

What You Give Up

Vapor Mode isn't a drop-in replacement for every component. The key constraint is that it only supports Composition API and <script setup>. Options API components, <script> without setup, and class-based components can't use Vapor — they stay on the virtual DOM path.

There's also one notable async exception: <Suspense>. Component trees that rely on Suspense for async data orchestration need to remain on the VDOM path for now, as Suspense is not yet supported in Vapor. That means if a Vapor component is a direct child of a <Suspense> boundary, you'll want to hold off.

For libraries and design system components — things that render a lot and get used everywhere — Vapor is a natural fit. A heavily-used <DataTable>, <VirtualList>, or <Chart> component that renders thousands of rows is exactly where eliminating VNode overhead pays off most.

A Practical Adoption Strategy

The most sensible approach is to start at the leaves. Identify the components in your app that render most frequently or at the highest volume — usually leaf components like list items, table rows, or icon buttons — and add vapor to those first. Mixed trees work: a virtual DOM parent component can render Vapor children without any special configuration or wrappers.

<!-- ParentComponent.vue — standard VDOM component -->
<template>
  <ul>
    <ListItem v-for="item in items" :key="item.id" :item="item" />
  </ul>
</template>

<!-- ListItem.vapor.vue — Vapor component, opted in by filename -->
<script setup>
defineProps(["item"]);
</script>

<template>
  <li>{{ item.name }}</li>
</template>

Vue handles the boundary between the two rendering modes automatically. From a developer experience standpoint, both components look and feel identical — you just notice the performance difference in profiling.

The Bigger Picture

Vapor Mode is the culmination of a direction Evan You signaled years ago: a Vue that can meet the performance bar of compile-time-first frameworks without asking you to abandon the progressive, component-centric model that made Vue popular. You don't have to learn new primitives, switch to JSX, or reason about fine-grained subscriptions manually. The compiler does the work.

For apps that are hitting real rendering bottlenecks — dashboards with dense real-time data, large lists, or component trees that re-render heavily under user interaction — Vapor Mode is worth evaluating today. Start with one hot component, measure, and expand from there. The opt-in model means there's no risk to the rest of your app.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

CSS if(): Inline Conditionals for Smarter Styling

Danny Holloran — Mon, 08 Jun 2026 21:24:25 +0000

There's a moment every CSS developer knows: you want to tweak a single property based on some condition — a viewport width, a user preference, a custom property — and instead of a clean one-liner you end up with a whole new @media block, duplicated selectors, and maybe a dash of JavaScript to handle the edge cases. It works, but it never feels right.

The CSS if() function changes that. Shipping in Chrome 137, it brings inline conditional logic directly into your property declarations, letting you express branching style logic without leaving the property itself.

How if() Works

The syntax is a sequence of condition-value pairs, evaluated top to bottom until one matches:

property: if(condition: value; else: fallback);

The function supports three types of conditions:

style() — queries computed CSS custom property values
media() — runs an inline media query
supports() — feature-detects a CSS property or syntax

You can chain them with else:

button {
  padding: if(media(width >= 1024px): 0.5rem 1.5rem; else: 0.75rem 1.25rem);
}

That's a responsive padding rule with zero extra @media blocks.

Three Practical Uses

1. Touch-Friendly Targets with media()

The pointer media feature lets you distinguish mouse users from touchscreen users. The accessible minimum tap target is 44px; mouse users can get away with smaller:

.icon-button {
  width: if(media(any-pointer: fine): 32px; else: 44px);
  height: if(media(any-pointer: fine): 32px; else: 44px);
}

Previously this needed a full @media (any-pointer: coarse) block. Now it reads like what it is — a single property with two states.

2. Theme Switching with style()

Custom properties are often used to carry design tokens — theme flags, component variants, status values. The style() query lets you branch on them inline:

.status-badge {
  --status: pending;

  background: if(
    style(--status: complete): #22c55e; style(--status: error): #ef4444;
      else: #f59e0b
  );
  color: if(style(--status: complete): #fff; else: #111);
}

Set --status anywhere up the cascade (a data attribute, a parent class, JavaScript) and the badge adapts without touching the rule itself.

3. Progressive Enhancement with supports()

Feature detection used to require @supports wrapper blocks that mirror your regular rules. Inline, it's much less verbose:

.hero {
  background-color: if(
    supports(color: oklch(0.7 0.2 180)): oklch(0.7 0.2 180) ;
      else: hsl(180deg 40% 55%)
  );
}

Modern browsers get the perceptually uniform oklch color; older ones get a safe hsl fallback — all in one declaration.

Browser Support and Progressive Enhancement

As of mid-2026, if() is supported in Chrome 137+, Edge, and Opera — Chromium browsers only. Firefox support is in progress, and Safari has it on the roadmap for 2026–2027. That means you shouldn't lean on if() for anything structural yet.

The recommended approach is to write your safe default first, then layer if() on top behind a @supports guard:

/* Safe default for all browsers */
.card {
  padding: 1rem;
}

/* Enhanced padding for browsers that support if() */
@supports (padding: if(media(width >= 768px): 1.5rem; else: 1rem)) {
  .card {
    padding: if(media(width >= 768px): 1.5rem; else: 1rem);
  }
}

It's a bit redundant today, but the @supports block drops away cleanly once the feature reaches baseline. This is the same progressive enhancement pattern CSS scroll-driven animations and anchor positioning used while support was building.

Worth Watching Now

if() won't replace @media blocks wholesale — complex breakpoint logic with many properties still reads better in a dedicated rule. Where it genuinely shines is in the small conditional cases you'd otherwise scatter across your stylesheet: a size tweak for touch targets, a color swap for a status flag, a palette upgrade when a modern color space is available.

The feature is experimental enough that you should keep an eye on the MDN reference and the CSS-Tricks coverage as browser support widens. But if you're already running Chrome 137+ in development, it's a great time to start reaching for it in low-risk, progressively enhanced places and see where it clicks.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

SvelteKit Remote Functions: Goodbye, API Boilerplate

Danny Holloran — Thu, 04 Jun 2026 16:41:55 +0000

If you've built anything non-trivial in SvelteKit, you know the dance: create a +server.ts endpoint, write a fetch call on the client, hand-roll the types on both sides, and hope they never drift apart. It works, but it's ceremony — and every new piece of data means doing the dance again.

SvelteKit's remote functions (available since 2.27, still behind an experimental flag) collapse all of that into a single import. You write a function once, it always runs on the server, but you can call it from anywhere — including right inside your component markup.

Queries: server data, right in your template

Remote functions live in .remote.js or .remote.ts files and come in four flavors: query, form, command, and prerender. The simplest is query, for reading dynamic data:

// src/routes/blog/data.remote.ts
import { query } from "$app/server";
import * as v from "valibot";
import * as db from "$lib/server/database";

export const getPost = query(v.string(), async (slug) => {
  const [post] = await db.sql`
    SELECT * FROM post WHERE slug = ${slug}
  `;
  return post;
});

Because the exported function is transformed into a fetch wrapper on the client, the argument crosses an HTTP boundary — so SvelteKit asks you to validate it with any Standard Schema library (Zod, Valibot, etc.). In return you get full end-to-end type safety with zero manually written types.

Combined with Svelte's experimental await support, consuming it is almost suspiciously clean:

<script>
  import { getPost } from '../data.remote';
  let { params } = $props();
</script>

{#await getPost(params.slug) then post}
  <h1>{post.title}</h1>
{/await}

You can also await getPost(...) directly in markup and let the nearest <svelte:boundary> handle loading and error states. Identical calls are deduplicated automatically — multiple components awaiting getPost('intro') share one request — and any query can be re-fetched with getPosts().refresh(). There's even query.batch to solve the classic n+1 problem, and the new query.live, which takes an async generator and streams real-time values to the client over a shared connection.

Forms and commands: writes without the wiring

Mutations get the same treatment. The form function returns an object you spread onto a <form> element. It works without JavaScript (plain submit and reload) and progressively enhances when JS is available:

export const createPost = form(
  v.object({
    title: "v.pipe(v.string(), v.nonEmpty()),"
    content: v.pipe(v.string(), v.nonEmpty()),
  }),
  async ({ title, content }) => {
    await db.sql`INSERT INTO post (title, content)
                 VALUES (${title}, ${content})`;
    redirect(303, "/blog");
  },
);

<form {...createPost}>
  <input {...createPost.fields.title.as('text')} />
  <textarea {...createPost.fields.content.as('text')}></textarea>
  <button>Publish</button>
</form>

The fields API generates name, value, and aria-invalid attributes for you, repopulates inputs after a failed submission, and surfaces validation issues per field via issues(). For mutations that aren't tied to a form — a like button, drag-and-drop reordering — command does the same job and can be called from any event handler.

The clever bit is single-flight mutations: inside a form or command handler you can call getPosts().refresh() on the server, and the refreshed query data rides back to the client in the same response. No second round-trip, no stale UI, no invalidate-everything sledgehammer.

Should you turn it on?

Remote functions are still experimental — you opt in via kit.experimental.remoteFunctions and compilerOptions.experimental.async in svelte.config.js, and the API may shift before it stabilizes. That said, it's been maturing steadily since SvelteKit 2.27, and recent releases keep adding polish like query.live for real-time data.

For a side project or an internal tool, it's absolutely worth enabling today — the reduction in boilerplate is dramatic, and the progressive-enhancement story for forms is better than what most of us write by hand. For production apps, keep an eye on the remote functions docs and the ongoing discussion in the SvelteKit repo. Either way, this is clearly the direction data fetching in SvelteKit is headed, and it's worth learning now.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

JavaScript's using Keyword: Automatic Resource Cleanup in ES2026

Danny Holloran — Wed, 03 Jun 2026 23:57:22 +0000

If you've ever opened a database connection, grabbed a file handle, or spun up a worker — and then watched your try...finally block balloon into something that felt more like scaffolding than real code — you know the problem. JavaScript has never had a clean built-in way to say "when this block is done, clean that up." Until now.

ES2026 finalizes Explicit Resource Management, a new language feature that adds using and await using declarations. They let you bind a resource's lifecycle to a block scope, so cleanup happens automatically no matter how the block exits — whether through normal return, an exception, or an early break.

The Problem with try...finally

Consider reading from a file in Node.js:

import { open } from "node:fs/promises";

async function readConfig(path) {
  const file = await open(path, "r");
  try {
    const content = await file.readFile({ encoding: "utf8" });
    return JSON.parse(content);
  } finally {
    await file.close(); // easy to forget, ugly to maintain
  }
}

This works, but the try...finally pattern is noise — especially when you're managing multiple resources at once. Stack them, and you end up with nested blocks or a tangle of cleanup logic that has nothing to do with your actual business logic.

Introducing using and await using

Any object that implements [Symbol.dispose]() (sync) or [Symbol.asyncDispose]() (async) can be used with the new declarations. When the surrounding block exits, JavaScript automatically calls the dispose method — no finally required.

Here's the file example rewritten:

import { open } from "node:fs/promises";

function makeDisposableFile(file) {
  return {
    file,
    [Symbol.asyncDispose]() {
      return file.close();
    },
  };
}

async function readConfig(path) {
  await using handle = makeDisposableFile(await open(path, "r"));
  const content = await handle.file.readFile({ encoding: "utf8" });
  return JSON.parse(content); // file.close() runs automatically here
}

The await in await using doesn't pause at declaration time — it tells JavaScript to await the async disposal when the block exits. If an exception is thrown before the block ends, disposal still runs.

For synchronous resources, drop the await:

function getDbConnection() {
  const conn = openDbSync();
  return {
    conn,
    [Symbol.dispose]() {
      conn.close();
    },
  };
}

function getUserCount() {
  using db = getDbConnection();
  return db.conn.query("SELECT COUNT(*) FROM users")[0];
  // conn.close() runs here, even if query throws
}

Managing Multiple Resources with DisposableStack

When you need to acquire several resources in sequence, DisposableStack (sync) and AsyncDisposableStack (async) give you a container to register them all. They dispose in LIFO order — last acquired, first released — which matches the natural dependency order of most resource chains.

async function processJob(jobId) {
  await using stack = new AsyncDisposableStack();

  const db = stack.use(await openDbConnection());
  const lock = stack.use(await acquireLock(`job:${jobId}`));
  const logger = stack.use(await openLogStream(jobId));

  logger.write(`Starting job ${jobId}`);
  const data = await db.query(`SELECT * FROM jobs WHERE id = ?`, [jobId]);
  await processData(data, logger);

  // On exit: logger closes, then lock releases, then db closes
}

stack.use() registers a disposable and returns it. If acquiring a later resource throws, only the resources already registered get cleaned up — no leaks, no manual rollback logic.

Support and Tooling

TypeScript has supported using and await using since version 5.2 — you can use it today if you're on a recent TS setup. On the runtime side, Node.js 22+ supports it natively, and Chrome 123+ and Firefox 119+ ship it without flags. For older targets, Vite, esbuild, and webpack all transpile it correctly.

The real payoff isn't just fewer lines of code — it's that resource cleanup becomes impossible to accidentally skip. Libraries are already starting to ship [Symbol.dispose]-compatible handles (the Node.js FileHandle from fs/promises being one example), and the pattern will only become more common as the ecosystem catches up.

If you're building anything that touches files, connections, locks, or streams, this is worth adding to your toolkit now. Check out the V8 explainer and the TC39 proposal repo for the full spec details.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

The Speculation Rules API: Instant Page Navigations Without a Framework

Danny Holloran — Thu, 28 May 2026 17:10:09 +0000

Navigation speed is one of the biggest perceived performance wins you can hand users — not the initial page load, but how fast subsequent pages feel. Getting truly instant navigations used to mean reaching for a SPA framework and client-side routing. The Speculation Rules API changes that. It lets you prerender entire pages in the background so transitions feel nearly instantaneous. No framework required.

What the Speculation Rules API Does

The API works through a <script type="speculationrules"> tag containing a JSON structure that describes pages the browser should either prefetch (download the HTML in the background) or prerender (fully load and render the page, including JavaScript execution, in a hidden context). When the user navigates to a prefetched or prerendered URL, the browser activates it instantly.

Two modes, two tradeoffs:

Prefetch — downloads the document and subresources, holding them ready. Cheap and broadly applicable.
Prerender — fully renders the page (runs JS, loads styles, builds the DOM) in a hidden renderer. The navigation feels like it was already loaded. Higher memory cost, so use it selectively.

A basic list-based rule looks like this:

<script type="speculationrules">
  {
    "prerender": [
      {
        "urls": ["/products", "/about", "/pricing"]
      }
    ]
  }
</script>

Drop that in your <head> and Chrome will start prerendering those three URLs in the background as soon as the page loads. When a user clicks one of those links, it activates instantly — the renderer was already running.

Document Rules: Dynamic Prefetching Without Hardcoding URLs

Hardcoding a URL list works for small sites, but most apps need something smarter. Document rules match links already on the page rather than requiring you to enumerate every URL upfront.

<script type="speculationrules">
  {
    "prefetch": [
      {
        "source": "document",
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } }
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

This tells the browser: prefetch any same-origin link on this page, except /logout, and use moderate eagerness. The eagerness setting controls when the speculation fires:

"immediate" — speculate as soon as the rule is parsed
"moderate" — trigger on hover (desktop) or when the link enters the viewport (mobile)
"conservative" — trigger only on pointerdown or touchstart

For prefetch, "moderate" is usually the right default — aggressive enough to feel instant, conservative enough to avoid wasting bandwidth on links that never get clicked.

You can combine both approaches: broad prefetch for general coverage, prerender for your highest-confidence paths:

<script type="speculationrules">
  {
    "prefetch": [
      {
        "source": "document",
        "where": { "href_matches": "/*" },
        "eagerness": "moderate"
      }
    ],
    "prerender": [
      {
        "source": "document",
        "where": { "href_matches": "/products/*" },
        "eagerness": "conservative"
      }
    ]
  }
</script>

Handling Analytics and Side Effects

Prerendering a page means JavaScript runs before the user actually sees it, which is a problem for analytics or anything that records an impression. The document.prerendering property tells you whether the page is in a background prerender state, and the prerenderingchange event fires when the user actually navigates to it.

// Guard analytics so they only fire on real views
function trackPageView() {
  if (document.prerendering) {
    document.addEventListener("prerenderingchange", trackPageView, {
      once: true,
    });
    return;
  }
  // Safe to fire analytics here
  analytics.track("page_view", { path: location.pathname });
}

trackPageView();

Major providers like Google Analytics already handle this automatically. If you're using a custom analytics setup or tag manager, this guard pattern keeps your numbers accurate.

A few more caveats worth knowing:

Browser support: Chromium-based browsers only (Chrome 109+, Edge, Opera). Safari and Firefox ignore the rules entirely with no ill effects — users just get normal navigation.
Memory: Each prerender spins up a real renderer process. Keep your prerender rules to a handful of high-value pages rather than blanketing an entire site.
Don't prerender auth-sensitive pages: Prerendered pages load before the navigation, which can expose logged-in state at unexpected times. Exclude pages like /account, /dashboard, or anything behind a login check from your prerender rules.

Adoption Is Accelerating

The 2025 Web Almanac reported that 35% of mobile websites now use the Speculation Rules API — much of that driven by WordPress 6.8, which baked speculation rules into core in March 2025. If you're running a multi-page app, a content site, or really anything with internal navigation, there's very little reason not to add at least a prefetch rule. The Chrome for Developers prerender guide and the MDN Speculation Rules reference are both excellent starting points for going deeper.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Astro Actions: Type-Safe Server Functions Without the Boilerplate

Danny Holloran — Tue, 26 May 2026 13:37:12 +0000

You've got a contact form in your Astro site. The classic approach: write an API endpoint at src/pages/api/contact.ts, parse formData by hand, validate the fields yourself, and then write a client-side fetch() call that knows nothing about the shape of the data it's sending. You end up touching four files to wire up one form, and TypeScript can't help you across the boundary.

Astro Actions, stable since Astro 5, solve this in a way that actually feels like a step forward rather than a workaround.

What Astro Actions Are

An action is a typed server function you define once and call from anywhere — an HTML form, a client-side script, or a React/Vue/Svelte island. The framework handles the HTTP transport, body parsing, and Zod validation automatically. What you get back on the client is fully typed, which means you catch mistakes at compile time instead of at runtime.

All actions live in src/actions/index.ts inside an exported server object:

// src/actions/index.ts
import { defineAction } from "astro:actions";
import { z } from "astro:schema";

export const server = {
  contact: defineAction({
    accept: "form",
    input: z.object({
      name: z.string().min(1, "Name is required"),
      email: z.string().email("Invalid email address"),
      message: z.string().min(10, "Message too short"),
    }),
    handler: async ({ name, email, message }) => {
      // This runs on the server. Send an email, write to a DB, whatever.
      await sendEmail({ name, email, message });
      return { success: true };
    },
  }),
};

The accept: 'form' tells Astro to parse FormData automatically — no formData.get('email') calls, no casting to string. The Zod schema does the validation, and the handler gets a typed object. If validation fails, Astro returns structured field-level errors before your handler even runs.

Calling Actions From a Form

The simplest integration requires zero JavaScript on the client. Just point the form's action attribute at the action using Astro's helper:

---
// src/pages/contact.astro
import { actions } from 'astro:actions';
---

<form method="POST" action={actions.contact}>
  <input name="name" type="text" placeholder="Your name" />
  <input name="email" type="email" placeholder="Email" />
  <textarea name="message" rows="5"></textarea>
  <button type="submit">Send</button>
</form>

That's the whole progressive-enhancement story: the form submits without JS, the action runs on the server, and you get a redirect back. Add a client-side handler and you get instant feedback without a full page reload — your choice.

For the JS-enhanced version, reading action results and rendering errors stays clean:

// client-side script in the same .astro file
import { actions, isInputError } from "astro:actions";

document.querySelector("form")?.addEventListener("submit", async (e) => {
  e.preventDefault();
  const formData = new FormData(e.currentTarget as HTMLFormElement);
  const { data, error } = await actions.contact.safe(formData);

  if (error && isInputError(error)) {
    // error.fields.name, error.fields.email, etc. — all typed
    console.error(error.fields);
    return;
  }

  if (data?.success) {
    // Show a success message
  }
});

The .safe() variant returns { data, error } instead of throwing, which is usually what you want in UI code. The isInputError() type guard narrows the error to one with a fields object that matches your Zod schema — field names are autocompleted, no guessing.

Calling Actions From Islands

If you're working with a React or Svelte island, actions work just as well. No fetch(), no URL to remember:

// src/components/ContactForm.tsx
import { actions, isInputError } from "astro:actions";
import { useState } from "react";

export function ContactForm() {
  const [status, setStatus] = useState<"idle" | "success" | "error">("idle");
  const [fieldErrors, setFieldErrors] = useState<Record<string, string[]>>({});

  async function handleSubmit(e: React.FormEvent<HTMLFormElement>) {
    e.preventDefault();
    const formData = new FormData(e.currentTarget);
    const { data, error } = await actions.contact.safe(formData);

    if (error && isInputError(error)) {
      setFieldErrors(error.fields as Record<string, string[]>);
      setStatus("error");
    } else if (data?.success) {
      setStatus("success");
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input name="name" type="text" />
      {fieldErrors.name && <p className="error">{fieldErrors.name[0]}</p>}
      <input name="email" type="email" />
      {fieldErrors.email && <p className="error">{fieldErrors.email[0]}</p>}
      <textarea name="message" rows={5} />
      <button type="submit">Send</button>
      {status === "success" && <p>Message sent!</p>}
    </form>
  );
}

Actions also accept JSON payloads — drop accept: 'form' (JSON is the default) and call the action directly with an object:

const { data, error } = await actions.newsletter.safe({
  email: "dan@example.com",
});

That's useful for actions triggered by button clicks or other non-form interactions.

When to Reach For Actions

Actions are a great fit for forms, mutations, and any server-side logic you'd otherwise expose as a one-off API endpoint. They're not a replacement for proper REST or GraphQL APIs when you need something external clients can consume — but for internal Astro-to-server communication, they cut the boilerplate dramatically.

The type safety across the network boundary is the real win. Once you've defined your Zod schema, your IDE knows the shape of the response and the structure of any validation errors. You stop writing as string and start trusting the compiler.

The official Astro Actions docs are thorough and worth reading once you've got the basics down — there's more to explore around middleware-level action handling and using actions with useActionState in React 19.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Svelte 5 Runes: Reactive State That Actually Makes Sense

Danny Holloran — Mon, 25 May 2026 23:32:18 +0000

If you've ever wrestled with Svelte 4's reactive declarations — that vaguely magical $: syntax that sometimes works exactly as you expect and sometimes very much doesn't — you'll appreciate what Svelte 5 brings to the table. Runes are a new set of explicit reactive primitives that replace the old implicit system, and they're a genuine improvement: clearer, more predictable, and no longer confined to .svelte files.

What Are Runes?

Runes are compiler-recognized functions prefixed with $. Think of them as signals — they tell Svelte's compiler (and now its runtime) where reactivity lives and how it flows. Svelte 5 ships four core runes: $state, $derived, $effect, and $props. Each one is a focused primitive with clear semantics.

In Svelte 4, you'd write something like this to declare reactive state:

<script>
  let count = 0;
  $: doubled = count * 2;
</script>

That $: label is a reactive declaration — Svelte's compiler turns it into something reactive under the hood. It works, but it's implicit. The reactivity is tied to the compiler, which means it only works inside .svelte files, and its behavior in complex expressions can catch you off guard.

In Svelte 5, the same thing looks like this:

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

Explicit, readable, and — crucially — portable.

$state, $derived, and $effect in Practice

$state replaces bare let declarations for reactive variables. It signals to Svelte that this value should be tracked. When it changes, anything that depends on it updates.

$derived replaces $: someValue = .... It computes a value from reactive dependencies and is memoized — it only recalculates when its inputs change.

$effect replaces $: { ... } blocks that had side effects. It runs after the DOM has updated, and it re-runs whenever its reactive dependencies change. It also accepts a return value for cleanup — no more worrying about stale subscriptions:

<script>
  let query = $state('');
  let results = $state([]);

  $effect(() => {
    if (!query) {
      results = [];
      return;
    }

    const controller = new AbortController();
    fetch(`/api/search?q=${query}`, { signal: controller.signal })
      .then(r => r.json())
      .then(data => { results = data; });

    // cleanup runs before the next effect
    return () => controller.abort();
  });
</script>

For derived values that need more than a single expression, $derived.by accepts a function:

<script>
  let items = $state([1, 2, 3, 4, 5]);
  let stats = $derived.by(() => {
    const sum = items.reduce((a, b) => a + b, 0);
    return { sum, avg: sum / items.length };
  });
</script>

<p>Average: {stats.avg}</p>

Sharing State Across Components

This is where things get genuinely exciting. In Svelte 4, sharing reactive state meant reaching for Svelte stores — writable, readable, derived — and using the $ shorthand to auto-subscribe. Stores still work in Svelte 5, but runes give you a simpler option: reactive state in .svelte.ts files.

Any file ending in .svelte.ts (or .svelte.js) gets the runes compiler. That means $state and $derived work outside of components:

// cart.svelte.ts
function createCart() {
  let items = $state<{ name: string; price: number }[]>([]);

  let total = $derived(items.reduce((sum, item) => sum + item.price, 0));

  function add(item: { name: string; price: number }) {
    items = [...items, item];
  }

  function remove(index: number) {
    items = items.filter((_, i) => i !== index);
  }

  return {
    get items() {
      return items;
    },
    get total() {
      return total;
    },
    add,
    remove,
  };
}

export const cart = createCart();

Then in any component:

<script>
  import { cart } from '$lib/cart.svelte.ts';
</script>

<p>Total: ${cart.total.toFixed(2)}</p>
<button onclick={() => cart.add({ name: 'Widget', price: 9.99 })}>
  Add to cart
</button>

One key thing to note: export an object or function — not a raw $state variable directly. Exporting a primitive breaks the reactivity because the value gets "frozen" at import time. The getter pattern above (get items()) keeps the reference live.

Also worth knowing: if you're using SSR, shared module-level $state is shared across all server requests. Scope it inside a function (like the factory pattern above) or use getContext for per-request isolation.

Worth Trying

Svelte 5's runes aren't just a syntax facelift — they're a more honest model of how reactivity works. The old magic is replaced with explicit primitives that behave consistently whether you're in a component or a shared module. If you're starting a new Svelte project, go runes-first. If you're on an existing codebase, the migration is gradual — Svelte 5 runs Svelte 4 components without changes.

The official migration guide is thorough and a solid starting point. The LogRocket deep dive is also worth bookmarking for when you hit an edge case.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

React Compiler v1.0: Automatic Memoization Without the Headache

Danny Holloran — Mon, 25 May 2026 23:32:14 +0000

If you've spent any time tuning a React app for performance, you know the ritual: wrap callbacks in useCallback, memoize expensive calculations with useMemo, slap React.memo on child components that keep re-rendering for no good reason. It works — but it's also brittle, easy to get wrong, and clutters your components with optimization noise that has nothing to do with what the component is actually supposed to do.

React Compiler v1.0 shipped in October 2025, and it tackles this problem at the build step. Instead of you manually annotating what needs to be memoized, the compiler analyzes your component code, figures it out, and handles it automatically. Meta has been running it in production for a while now and reported a 20–30% reduction in render time across their apps. It's time to take it seriously.

What the Compiler Actually Does

React Compiler is a Babel (or SWC) plugin that runs at build time and transforms your component code. It classifies every expression in a component as either static — values that never change between renders — or dynamic — values that may change. From there it automatically injects the memoization equivalents of useMemo, useCallback, and React.memo exactly where they're needed, including in places where you can't manually memoize, like conditionally computed values.

The result is that components you write as plain, idiomatic React get compiled into components that behave as if a very careful engineer went through and added memoization in all the right places.

Here's a before/after to make it concrete. Before the compiler, you might write something like this to avoid unnecessary re-renders:

import { useCallback, useMemo, memo } from "react";

const ProductCard = memo(({ product, onAddToCart }) => {
  const formattedPrice = useMemo(
    () =>
      new Intl.NumberFormat("en-US", {
        style: "currency",
        currency: "USD",
      }).format(product.price),
    [product.price],
  );

  const handleClick = useCallback(() => {
    onAddToCart(product.id);
  }, [onAddToCart, product.id]);

  return (
    <div className="card">
      <h2>{product.name}</h2>
      <p>{formattedPrice}</p>
      <button onClick={handleClick}>Add to Cart</button>
    </div>
  );
});

With React Compiler, you write the plain version and the compiler handles the memoization for you:

// No memo(), no useMemo, no useCallback — the compiler adds the equivalent automatically
const ProductCard = ({ product, onAddToCart }) => {
  const formattedPrice = new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD",
  }).format(product.price);

  const handleClick = () => {
    onAddToCart(product.id);
  };

  return (
    <div className="card">
      <h2>{product.name}</h2>
      <p>{formattedPrice}</p>
      <button onClick={handleClick}>Add to Cart</button>
    </div>
  );
};

Same runtime behavior, significantly less ceremony.

Setting It Up

Getting the compiler running is straightforward for most setups. If you're on Next.js 15+, it's a single config flag:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  reactCompiler: true,
};

export default nextConfig;

For Vite projects, install the Babel plugin and add it to your Vite config:

npm install --save-dev babel-plugin-react-compiler

// vite.config.js
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: ["babel-plugin-react-compiler"],
      },
    }),
  ],
});

One thing to know: the compiler requires your code to follow the Rules of React — things like not mutating state directly and keeping components pure. If a component violates these rules, the compiler skips it rather than producing broken output. You can also explicitly opt a component out with a "use no memo" directive at the top of the function body when you need manual control.

Caveats and What to Watch For

The compiler is stable and production-ready, but it's not a complete free pass on performance thinking. A few things worth keeping in mind:

It requires valid React code. The compiler performs static analysis, so components that mutate props, rely on side effects in render, or break referential equality in surprising ways won't always compile cleanly. Running eslint-plugin-react-compiler alongside the build plugin will flag these before they become silent issues.

useMemo and useCallback still have a role as escape hatches. When a memoized value is used as a useEffect dependency and you need precise control over when the effect fires, manually specifying that dependency is still valid and the compiler won't fight you on it.

Check your bundle output once. Tools like React DevTools show you whether a component has been compiled (it'll show "Memo ✓" in the component tree). A quick audit after enabling the compiler confirms it's actually optimizing the components you expect.

React Compiler doesn't change how you think about component design — it just removes the tax of manually annotating your performance constraints. For most React codebases, enabling it today is a straightforward win.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

TypeScript 7.0: The Go Compiler That Makes TS 10x Faster

Danny Holloran — Mon, 25 May 2026 23:23:07 +0000

If you've worked on a large TypeScript codebase, you know the pain. You hit save, you wait. The type-checker grinds through hundreds of files, your IDE lag spikes, and CI takes minutes just to get through tsc --noEmit. It's not TypeScript's fault — the language has always made a reasonable trade-off between expressiveness and performance. But that trade-off is about to get renegotiated.

TypeScript 7.0 is currently in beta, and the headlining change is a complete rewrite of the compiler — from TypeScript itself to Go. The result is build times that are roughly 10x faster. Not 10% faster. Ten times.

Why Go, and Why Now

The TypeScript team's choice of Go wasn't about hype — it was about constraints. The existing compiler is JavaScript running on Node.js, which means it inherits V8's garbage collector and single-threaded execution model. That's fine for small projects, but as codebases scale to hundreds of thousands of lines, GC pauses and sequential file processing become the bottleneck.

Go hits a practical sweet spot: it compiles to native binaries (eliminating Node.js startup overhead), its goroutines make parallelizing across files straightforward, and its memory model is substantially more predictable than V8's heap. In benchmarks using the VS Code codebase — 1.5 million lines of TypeScript — the difference is stark:

tsc (current):    ~78 seconds
tsgo (TS 7 beta):  ~7.5 seconds

Memory consumption also drops by around 57%. If you run type-checking in CI on every PR, that's real money and real developer-hours back on the table.

Trying It Today

TypeScript 7.0 is still in beta, but it's stable enough for experimentation and, for many projects, everyday use. The beta ships under the @typescript/native-preview package:

# Local dev dependency
npm install -D @typescript/native-preview

# Or globally
npm install -g @typescript/native-preview

Once installed, you get a tsgo executable that works as a drop-in for tsc:

# Type-check your project
tsgo --noEmit

# Watch mode
tsgo --watch

# Check the version
tsgo --version
# Version 7.0.0-beta

VS Code users can also install the TypeScript Native Preview extension to get the faster language server in the editor. The experience is noticeably snappier even on mid-sized codebases — hover types and go-to-definition feel instant compared to the current server.

What's Different (and What Might Break)

For the vast majority of projects, tsgo is a transparent swap for tsc. As of the beta, the Go compiler passes over 95% of the TypeScript test suite. The remaining gaps are mostly around legacy emit modes and decorator metadata, which modern projects typically don't rely on.

There are two notable changes to be aware of:

Strict mode is now the default. TypeScript 7 enables strict: true out of the box, which bundles strictNullChecks, noImplicitAny, and friends. If your tsconfig.json currently omits strict settings, you may see new errors in the beta. The fix is explicit:

{
  "compilerOptions": {
    "strict": false
  }
}

That said, if you've been meaning to tighten up your config, this is a good forcing function.

Some tooling APIs aren't compatible yet. The compiler exposes a different internal API surface (codenamed Strada). Third-party tools that reach into TypeScript's compiler internals — some linters, formatters, or custom language service plugins — may not work with tsgo until they're updated. Check your dependencies before switching production CI over. For most teams using tsc directly or through tools like ts-jest and tsx, the transition should be smooth.

What This Means Going Forward

TypeScript 7 isn't adding a sweeping new type system feature — it's investing in the foundation. Faster type-checking compounds in every direction: tighter feedback loops in the editor, faster CI pipelines, and more room for the language to add richer checks without hitting practical performance walls.

The stable release is expected by late June or early July 2026. Until then, the beta is worth running on a branch or a greenfield project to get a feel for the speedups. You can follow along at the TypeScript blog and file issues on the typescript-go GitHub repo.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

Connecting Wallets the Right Way: wagmi v2 and EIP-6963

Danny Holloran — Mon, 25 May 2026 23:23:03 +0000

If you've ever built a dApp and had a user complain that "your site only shows MetaMask even though I have Coinbase Wallet installed," you've run headfirst into the window.ethereum problem. For years, every wallet browser extension raced to claim the same global, and whichever one loaded last won. The result was a constant arms race between wallet vendors and a genuinely terrible user experience.

EIP-6963 fixed that — and wagmi v2 makes the fix trivially easy to adopt. If you're still rolling your own wallet detection or using a library that hasn't caught up yet, this post is for you.

The window.ethereum Problem and How EIP-6963 Solves It

The original EIP-1193 standard gave wallets a single attachment point: window.ethereum. One slot, many wallets, inevitable collisions. MetaMask and Coinbase Wallet both inject themselves there; whoever ran last overwrites the other.

EIP-6963 introduces an event-based discovery protocol instead. On page load, your dApp fires a eip6963:requestProvider event. Each installed wallet extension that supports the spec responds by emitting an eip6963:announceProvider event carrying its own provider object and metadata (icon, name, RDNS identifier). Your app collects the responses and builds a list — every wallet, no conflicts.

You can implement this yourself, but the raw event wiring is boilerplate you don't need to own:

// Low-level EIP-6963 — illustrative only, use wagmi instead
const providers: EIP6963ProviderDetail[] = [];

window.addEventListener("eip6963:announceProvider", (event: CustomEvent) => {
  providers.push(event.detail);
});

window.dispatchEvent(new Event("eip6963:requestProvider"));

The real-world issue is that you also need to handle providers announced after your request, de-duplicate by RDNS, manage lifecycle — it adds up. wagmi v2 handles all of it.

Setting Up wagmi v2 with Multi-Wallet Support

wagmi v2 replaced its ethers.js dependency with viem — a lightweight, fully typed Ethereum library — and rebuilt its connector system from scratch. EIP-6963 discovery is enabled by default with the injected() connector.

Install the stack:

npm install wagmi viem @tanstack/react-query

Create your config:

// lib/wagmi.ts
import { createConfig, http } from "wagmi";
import { mainnet, sepolia } from "wagmi/chains";
import { injected, walletConnect, coinbaseWallet } from "wagmi/connectors";

export const config = createConfig({
  chains: [mainnet, sepolia],
  connectors: [
    injected(), // discovers ALL EIP-6963 wallets automatically
    walletConnect({ projectId: import.meta.env.VITE_WC_PROJECT_ID }),
    coinbaseWallet({ appName: "My dApp" }),
  ],
  transports: {
    [mainnet.id]: http(),
    [sepolia.id]: http(),
  },
});

Wrap your app with the providers:

// main.tsx
import { WagmiProvider } from "wagmi";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { config } from "./lib/wagmi";

const queryClient = new QueryClient();

export function App() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <YourApp />
      </QueryClientProvider>
    </WagmiProvider>
  );
}

That injected() connector does the EIP-6963 legwork automatically. When a user has three wallets installed, your connection UI will show all three.

Building a Wallet Connection Component

With the config in place, wagmi's hooks give you everything you need. Here's a minimal but fully functional wallet picker:

// components/WalletConnect.tsx
import { useConnect, useAccount, useDisconnect, useBalance } from "wagmi";
import { formatEther } from "viem";

export function WalletConnect() {
  const { connectors, connect, isPending } = useConnect();
  const { address, isConnected, chain } = useAccount();
  const { disconnect } = useDisconnect();
  const { data: balance } = useBalance({ address });

  if (isConnected && address) {
    return (
      <div>
        <p>
          {address.slice(0, 6)}…{address.slice(-4)} on {chain?.name}
        </p>
        {balance && (
          <p>{parseFloat(formatEther(balance.value)).toFixed(4)} ETH</p>
        )}
        <button onClick={() => disconnect()}>Disconnect</button>
      </div>
    );
  }

  return (
    <div>
      {connectors.map((connector) => (
        <button
          key={connector.uid}
          onClick={() => connect({ connector })}
          disabled={isPending}
        >
          {connector.name}
        </button>
      ))}
    </div>
  );
}

A few things worth noting here. connectors is populated at runtime based on what's actually available in the browser — if the user has MetaMask and Phantom installed, both show up. The connector.uid is stable across renders so it's safe as a React key. And useBalance returns a bigint value, which is where viem's formatEther utility comes in — it handles the wei-to-ether conversion without floating-point surprises.

For sending transactions, viem's type-safe primitives plug directly into wagmi's useSendTransaction hook:

import { useSendTransaction } from "wagmi";
import { parseEther } from "viem";

const { sendTransaction } = useSendTransaction();

sendTransaction({
  to: "0xRecipientAddress",
  value: parseEther("0.01"),
});

Where This Lands in Practice

EIP-6963 browser support is now effectively universal among modern wallet extensions — MetaMask, Coinbase Wallet, Phantom, Rabby, and most others have shipped it. Users with multiple wallets get a proper choice UI instead of a silent clobber. wagmi v2's default injected() connector handles the discovery without any extra configuration on your end.

If you're maintaining an older dApp that still reaches for window.ethereum directly, migrating to wagmi v2 is the cleanest upgrade path. The wagmi docs are thorough, and the TypeScript types throughout viem make the contract interactions significantly less error-prone than working with ethers.js or raw JSON-RPC calls.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

CSS Scroll-Driven Animations: No JavaScript Required

Danny Holloran — Mon, 25 May 2026 23:14:19 +0000

If you've ever added a scroll progress bar to a page or built a "reveal on scroll" effect, you've probably reached for Intersection Observer, a scroll event listener, or a library like GSAP. They work fine, but they run on the main thread, add weight to your bundle, and often require careful cleanup. The browser has a better idea.

CSS scroll-driven animations are now stable across Chrome, Edge, and Safari 18, with Firefox catching up fast. They let you tie CSS animations directly to scroll position — no JavaScript involved. The result is compositor-thread animations that stay buttery-smooth even when your main thread is busy.

The Two Timeline Types

The core of the API is the animation-timeline property, which replaces the default time-based animation timeline with a scroll-based one. There are two flavors: scroll() and view().

scroll() tracks how far a scroll container has been scrolled from top (0%) to bottom (100%). It's the right tool for things that should reflect the document's overall scroll progress — like a reading progress bar.

@keyframes grow-bar {
  from {
    transform: scaleX(0);
  }
  to {
    transform: scaleX(1);
  }
}

.progress-bar {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 4px;
  background: oklch(60% 0.2 250);
  transform-origin: left;

  animation: grow-bar linear;
  animation-timeline: scroll(root block);
  animation-fill-mode: both;
}

That's it. scroll(root block) tells the browser to use the root scrolling container's block (vertical) axis as the timeline. No scroll listeners. No requestAnimationFrame. The browser handles it entirely at the compositor level.

view() tracks an element's visibility within its scroll container as it enters and exits the viewport. It's purpose-built for reveal animations — animating each card or section as it scrolls into view.

@keyframes fade-up {
  from {
    opacity: 0;
    translate: 0 40px;
  }
  to {
    opacity: 1;
    translate: 0 0;
  }
}

.card {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 40%;
}

The animation-range property is the secret weapon here. It lets you specify which phase of the element's journey through the viewport should drive the animation. entry 0% entry 40% means "animate during the first 40% of the element's entrance into the viewport" — a crisp reveal that finishes before the element is fully on screen.

Scroll-Triggered Animations (Chrome 145+)

There's a newer addition worth knowing about: scroll-triggered animations. Unlike scroll-driven animations (which continuously update based on position), scroll-triggered animations fire once when a scroll threshold is crossed — similar to IntersectionObserver, but declarative in CSS.

@keyframes highlight-nav {
  to {
    background: oklch(25% 0 0);
    box-shadow: 0 2px 12px oklch(0% 0 0 / 30%);
  }
}

header {
  animation: highlight-nav linear forwards;
  animation-timeline: scroll(root);
  animation-range: 80px 81px;
}

This changes the header background once the user has scrolled past 80px and holds that state. It's a one-liner replacement for the classic sticky-nav-scroll-listener pattern.

Progressive Enhancement

Browser support is solid but not universal — Firefox still has partial support behind a flag. Always wrap scroll-driven animations in a @supports check so the experience degrades gracefully:

@supports (animation-timeline: scroll()) {
  .progress-bar {
    animation: grow-bar linear;
    animation-timeline: scroll(root block);
    animation-fill-mode: both;
  }
}

Without the @supports guard, browsers that don't understand animation-timeline will simply ignore those declarations. For the progress bar case that's fine — no bar is better than a broken one. For critical reveal animations, ensure elements are visible by default and only animate them when the feature is supported.

When to Reach for This

Scroll-driven animations shine when the effect is purely visual and directly tied to scroll position: reading indicators, sticky header transitions, parallax backgrounds, element reveals, and image carousels. For anything that needs to trigger side effects — updating state, fetching data, analytics events — you still want Intersection Observer or a scroll event. CSS animations can't call your JavaScript.

MDN's scroll-driven animations guide is the most complete reference, and scroll-driven-animations.style has a fantastic playground of real-world examples to steal from. Give it a scroll.

This post was originally published on danholloran.me. Follow along there for more frontend and dev content.

DEV Community: Danny Holloran

CSS User Preference Media Queries: Build Accessible Experiences Without JavaScript

prefers-reduced-motion: Stop Animating People Into Headaches

prefers-color-scheme: Native Dark Mode Without the Toggle

prefers-contrast: Don't Assume Your Palette Is Readable

forced-colors: Respect Windows High Contrast Mode

Putting It Together

Vue 3.6 Vapor Mode: Opt Out of the Virtual DOM

How Opting In Works

What You Give Up

A Practical Adoption Strategy

The Bigger Picture

CSS if(): Inline Conditionals for Smarter Styling

How if() Works

Three Practical Uses

1. Touch-Friendly Targets with media()

2. Theme Switching with style()

3. Progressive Enhancement with supports()

Browser Support and Progressive Enhancement

Worth Watching Now

SvelteKit Remote Functions: Goodbye, API Boilerplate

Queries: server data, right in your template

Forms and commands: writes without the wiring

Should you turn it on?

JavaScript's using Keyword: Automatic Resource Cleanup in ES2026

The Problem with try...finally

Introducing using and await using

Managing Multiple Resources with DisposableStack

Support and Tooling

The Speculation Rules API: Instant Page Navigations Without a Framework

What the Speculation Rules API Does

Document Rules: Dynamic Prefetching Without Hardcoding URLs

Handling Analytics and Side Effects

Adoption Is Accelerating

Astro Actions: Type-Safe Server Functions Without the Boilerplate

What Astro Actions Are

Calling Actions From a Form

Calling Actions From Islands

When to Reach For Actions

Svelte 5 Runes: Reactive State That Actually Makes Sense

What Are Runes?

$state, $derived, and $effect in Practice

Sharing State Across Components

Worth Trying

React Compiler v1.0: Automatic Memoization Without the Headache

What the Compiler Actually Does

Setting It Up

Caveats and What to Watch For

TypeScript 7.0: The Go Compiler That Makes TS 10x Faster

Why Go, and Why Now

Trying It Today

What's Different (and What Might Break)

What This Means Going Forward

Connecting Wallets the Right Way: wagmi v2 and EIP-6963

The window.ethereum Problem and How EIP-6963 Solves It

Setting Up wagmi v2 with Multi-Wallet Support

Building a Wallet Connection Component

Where This Lands in Practice

CSS Scroll-Driven Animations: No JavaScript Required

The Two Timeline Types

Scroll-Triggered Animations (Chrome 145+)

Progressive Enhancement

When to Reach for This

`prefers-reduced-motion`: Stop Animating People Into Headaches

`prefers-color-scheme`: Native Dark Mode Without the Toggle

`prefers-contrast`: Don't Assume Your Palette Is Readable

`forced-colors`: Respect Windows High Contrast Mode