DEV Community: Danny Holloran

Invoker Commands: Wiring Buttons to Dialogs and Popovers Without JavaScript

Danny Holloran — Thu, 02 Jul 2026 14:09:01 +0000

Every time you wire up a modal, you end up writing the same three lines of JavaScript: grab the button, grab the dialog, attach a click listener that calls showModal(). Do it again for the close button. Do it again for the next popover, the next dropdown, the next confirmation box. Across a real app, that adds up to a pile of glue code whose only job is connecting one element to another. The Invoker Commands API deletes most of that glue by letting a button say, right in the HTML, what it controls and what it does.

Two attributes, no listener

The API adds two attributes to <button>: commandfor points at the id of the element you want to control, and command names the action. For a dialog, that looks like this:

<button command="show-modal" commandfor="confirm">Delete</button>

<dialog id="confirm">
  <p>Delete this item?</p>
  <button command="close" commandfor="confirm">Cancel</button>
</dialog>

There is no script here at all. The first button opens the dialog as a modal; the button inside closes it. The browser ships a set of built-in commands for exactly the elements that used to need boilerplate: dialogs get show-modal and close, and popovers get toggle-popover, show-popover, and hide-popover.

A popover menu is just as terse:

<button command="toggle-popover" commandfor="menu">Menu</button>

<div id="menu" popover>
  <a href="/profile">Profile</a>
  <a href="/logout">Log out</a>
</div>

Why this beats a click handler

The obvious win is less code, but the real win is behavior you would otherwise have to remember to implement. Because the browser owns the interaction, you inherit correct focus management, the Escape-to-close behavior for dialogs and popovers, and the accessibility relationships between the trigger and its target for free. That is a category of bug (the modal that traps focus wrong, the popover that does not close on outside click) that simply stops happening.

There is also a deliberate constraint: only <button> can be an invoker. Links and inputs cannot use commandfor, because a command is an action, and buttons are the element with the right keyboard and semantic behavior for actions. And since the wiring lives in markup, it works the moment the HTML parses, before any JavaScript hydrates. For server-rendered pages and islands-style architectures, that means your dialogs and menus are interactive without waiting on a bundle.

Custom commands for your own behavior

Built-ins cover dialogs and popovers, but the API is not limited to them. You can define your own command with a double-dash prefix, following the same "dashed-ident" convention as CSS custom properties. The -- namespace is reserved: the browser guarantees it will never ship a built-in command starting with it, so your names can never collide with a future addition.

A custom command fires a command event on the target element, and you listen there:

<button command="--rotate-left" commandfor="photo">Rotate left</button>
<button command="--reset" commandfor="photo">Reset</button>

<img id="photo" src="/cat.jpg" alt="A cat, upright" />

const photo = document.getElementById("photo");

photo.addEventListener("command", (event) => {
  if (event.command === "--rotate-left") {
    // rotate and update alt text
  } else if (event.command === "--reset") {
    // reset
  }
  // event.source is the button that triggered the command
});

One gotcha worth internalizing: the command event does not bubble. You have to listen on the target element itself, not on a shared ancestor, so event delegation patterns will not pick it up.

Where support stands

This is not a "someday" feature. As of late 2025 the Invoker Commands API reached Baseline across Chrome and Edge (135+), Firefox, and Safari, so you can use it in production for the browsers most projects target. If you still support older versions, it degrades cleanly: a <button> with command/commandfor is just a button where the attributes are ignored, so a small click-handler fallback (or a feature check like "command" in HTMLButtonElement.prototype) keeps things working everywhere.

The practical rule of thumb: reach for command and commandfor first for dialogs, popovers, and simple UI toggles, and only drop down to JavaScript when you need genuinely custom behavior, which the custom-command event gives you a clean hook for. You end up with fewer listeners, less hydration-order fragility, and accessibility handled by the platform instead of by you.

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

Fallow: A Codebase Truth Layer for Agent-Written Code

Danny Holloran — Wed, 01 Jul 2026 19:29:44 +0000

Most of the code in my side projects lately wasn't typed by me. I write the issue, an agent writes the branch, and I review the PR. That workflow is fast, but it quietly moves the hard part downstream. When you review a lot of generated diffs, you stop worrying about whether a function works and start worrying about the stuff a diff never shows you: the export nothing imports anymore, the near-identical helper that already exists two folders over, the module that just started reaching across a boundary it had no business touching.

ESLint and Prettier don't catch any of that, because they can't. A linter reads one file at a time. The problems I actually run into are relationships between files, and that's exactly the gap Fallow fills.

What Fallow actually checks

Fallow calls itself a "codebase truth layer," and the framing is accurate. Instead of linting files, it builds a module graph across your whole TypeScript/JavaScript project and answers questions no file-local tool can:

Dead code — unused files, exports, dependencies, types, and circular dependencies
Duplication — copy-pasted blocks, from exact matches to semantic clones with renamed variables
Complexity — the riskiest functions and the files worth refactoring first
Architecture drift — imports that cross layer or module boundaries they shouldn't

The pitch that sold me is the honest one on the README: "Built for AI-assisted development. No AI inside." It's a Rust binary, it's deterministic, and it's fast enough that speed never becomes an excuse to skip it. On a 20,000-file Next.js project it finishes dead-code analysis in under two seconds. On anything I'm building solo, it's basically instant.

npx fallow

 Dead code   3 unused files, 12 unused exports, 2 unused deps       18ms
 Duplication 4 clone groups (2.1% of codebase)                      31ms
 Complexity  7 functions exceed thresholds                           4ms

No config for the first run. It ships 90 framework plugins, so it already knows what an entry point looks like in Next, Nuxt, SvelteKit, Astro, and the rest.

Where it fits with my other guardrails

Fallow didn't replace anything in my setup. It filled the one hole the others left.

The way I think about it now, each tool owns a different scale. Prettier owns formatting. ESLint owns file-local correctness. My CLAUDE.md (or AGENTS.md) owns intent: a handful of rules I want every generated change to respect, like rule of three before you abstract, early returns over nested conditionals, and keep functions small. Those guidelines shape the code as the agent writes it. Fallow owns the part none of the others can see, which is what the change did to the codebase as a whole.

The command that ties it into review is audit:

npx fallow audit --format json

It scopes dead code, duplication, and complexity to just the changed files and returns a verdict: pass, warn, or fail, with a real exit code. That runs cleanly in CI, but it's just as useful the moment before I open a PR. If the agent left an orphaned export or quietly duplicated a utility, I see it as a fact instead of hoping I'll spot it by eye at line 300 of a diff.

Because the JSON output includes a per-issue actions array, the agent itself can consume it. The loop becomes: generate the change, run fallow --format json, read the findings, fix the obvious ones, and hand me a cleaner PR to review. There's an MCP server for wiring it directly into Claude Code, Cursor, and friends, but honestly the CLI plus a line in the agent instructions gets you most of the value.

Getting started

Running it once costs nothing:

npx fallow            # dead code + duplication + health
fallow dead-code      # just cleanup candidates
fallow health --score # project health score, 0-100
fallow fix --dry-run  # preview automatic cleanup

When you're ready to make it stick, fallow init writes a tailored .fallowrc.json and can scaffold a pre-commit hook. Start every rule at warn so it surfaces problems without blocking you, then promote the ones you care about to error:

{ "rules": { "unused-files": "error", "unused-exports": "warn" } }

In CI it's a one-liner (uses: fallow-rs/fallow@v2), and the --baseline flag means you only fail on new issues, which makes it painless to adopt on a codebase that's already a little messy.

Delegating code to agents doesn't remove the need for review. It just changes what review is about. Fallow gives me a factual read on what a change did to the whole project, so I can spend my attention on the parts that actually need judgment instead of playing spot-the-dead-export. If you're shipping code you didn't personally type, that's a trade worth making.

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

The Navigation API: Stop Wrestling with history.pushState

Danny Holloran — Mon, 29 Jun 2026 16:47:10 +0000

If you have ever hand-rolled a router, you know the ritual. You call history.pushState, then you wire up a popstate listener, then you discover popstate does not fire for pushState so you patch the URL change separately, then you intercept every link click yourself, then you give up and reach for a framework router. The History API was never designed for single-page apps. It was a thin patch bolted onto multi-page navigation, and we have spent more than a decade working around its gaps.

The Navigation API is the fix, and as of early 2026 it is finally something you can ship. It reached Baseline Newly Available in January 2026, with support in Chrome, Edge, Firefox 147, and Safari 26.2. That means a centralized, purpose-built interface for client-side routing now works across every major engine on desktop and mobile.

One event to rule every navigation

The core idea is a single navigate event on the global navigation object. It fires for every kind of navigation: a link click, a form submission, a programmatic call, even a back/forward button press. Instead of scattering click handlers across your app and praying you caught them all, you handle routing in one place.

navigation.addEventListener("navigate", (navigateEvent) => {
  // Let the browser handle anything we shouldn't touch.
  if (shouldNotIntercept(navigateEvent)) return;

  const url = new URL(navigateEvent.destination.url);

  if (url.pathname.startsWith("/articles/")) {
    navigateEvent.intercept({
      async handler() {
        renderPlaceholder();
        const content = await getArticleContent(url.pathname);
        renderArticle(content);
      },
    });
  }
});

That intercept({ handler }) call is the heart of it. It tells the browser "I am taking over this navigation, it is a same-document update, and it may take a moment." If your handler returns a promise (which an async function does automatically), the browser knows exactly when the navigation starts, finishes, or fails. That is a real semantic the platform understands now, which is why Chrome shows its native loading indicator and enables the stop button during your async route change. You get accessibility wins for free that you simply could not get by mutating history by hand.

The decisions the old API made you guess at

The navigateEvent carries the context you used to reconstruct manually. A small guard function keeps you from intercepting navigations you have no business touching:

function shouldNotIntercept(navigateEvent) {
  return (
    !navigateEvent.canIntercept || // cross-origin, etc.
    navigateEvent.hashChange || // same-page anchor jump
    navigateEvent.downloadRequest || // it's a download
    navigateEvent.formData // a POST form submission
  );
}

canIntercept tells you up front whether interception is even allowed (cross-origin navigations and cross-document traversals are off limits). hashChange flags in-page anchor links you should leave alone. downloadRequest is set for download links. And formData is non-null for form POSTs, so checking it lets you handle GET navigations only. Each of these used to be a fragile inference; now they are properties on the event.

Async routes that cancel themselves

Because handlers are async, a user can start one navigation and then fire another before the first finishes. The History API gave you nothing here. The Navigation API hands you an AbortSignal on the event that fires the moment your navigation becomes redundant, and you can pipe it straight into fetch:

navigateEvent.intercept({
  async handler() {
    renderPlaceholder();
    const res = await fetch(`/api/content?path=${url.pathname}`, {
      signal: navigateEvent.signal,
    });
    renderArticle(await res.json());
  },
});

If the user clicks a different link mid-load, the in-flight request is cancelled, the promise rejects, and your stale DOM update never runs. No race conditions, no flicker of the wrong page.

Beyond routing, the API also exposes the full history as navigation.entries(), a clean navigation.currentEntry, and methods like navigation.navigate(url), navigation.back(), and navigation.traverseTo(key) that all return objects you can await. It is the API the web should have had all along.

You probably will not rip out your framework's router tomorrow, and you may still want a tiny polyfill for the long tail of old browsers. But if you are building something custom, or you just want to understand what the next generation of routers is built on, the Navigation API is worth an afternoon. Start with the Chrome for Developers guide and the MDN reference, then go delete some popstate code.

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

Grimicorn Neon: When a Calm Theme Goes Loud

Danny Holloran — Sun, 28 Jun 2026 21:17:47 +0000

The original Grimicorn was an exercise in restraint: muted pastels on a blue-gray base, tuned so nothing on screen ever burns your eyes. Grimicorn Neon is the opposite impulse. Same grim-reaper-meets-unicorn idea, except this one is plugged into the mains — saturated, glowing accents on a near-black base, dark-only, loud on purpose.

What makes the pair interesting from an engineering angle is how little had to change to get there. Neon is not a new theme so much as the same theme with the volume knob turned all the way up. That only works because of a decision made back in the calm version: colors are defined by role, not by appearance.

Eight roles, eight louder hexes

Both themes share the exact same role map. Blue is keywords, links, and the primary accent. Green is strings, success, and the cursor. Yellow is types, decorators, and warnings. The accent hierarchy is still blue → purple → teal, and the semantic anchors still hold: green means good, the error color means wrong.

What changes is only the values bound to those roles. Calm Grimicorn's blue is a soft #83AFE5; Neon's is an electric #2323FF. Calm green is a sage #A9CE93; Neon green is an acid #A3E635. The error role even swaps identity, from a gentle salmon to a hot #FF2D9B pink. Lay the two palettes side by side and the structure is identical — only the saturation and brightness move:

// same eight roles, two personalities
const calm = {
  blue: "#83AFE5",
  green: "#A9CE93",
  error: "#DD9787",
  base: "#253039",
};
const neon = {
  blue: "#2323FF",
  green: "#A3E635",
  error: "#FF2D9B",
  base: "#0A0A0B",
};

Because every one of the fourteen tool ports — VS Code, Ghostty, Obsidian, Claude Code, JetBrains, tmux, and the rest — is generated from a single palette.md, producing the neon set was mostly a matter of feeding the build a different eight values. The emitters that translate roles into VS Code scopes or ANSI slots never knew the difference. That is the real payoff of role-based theming: one architecture, two completely different moods, no forked codebase.

The near-black base is doing real work

Neon accents only read as neon if the thing behind them gets out of the way. Calm Grimicorn could afford a blue-gray base because its accents were gentle. Crank the accents to full saturation and that same base would turn into mud — everything competing, nothing glowing.

So Neon drops the floor to near-black. The background scale runs from #050506 through #303036, six steps that are almost monochrome by design. The chrome recedes, and the only saturated pixels left on screen are the ones carrying meaning: a keyword, a string, an error. High contrast plus near-zero background saturation is what produces the "glow." It is the same trick a concert uses — a dark room is what lets the lights pop.

Loud is a tradeoff, not a free upgrade

Worth being honest here: maximum-saturation text on a black background is the highest-contrast pairing you can build, and that is not purely a win. On dark UIs, very bright, very saturated glyphs can bloom slightly at their edges — a halation effect that some eyes, especially astigmatic ones, read as fuzziness after a long session. That is exactly the fatigue the calm variant was designed to avoid, which is why Neon ships dark-only and is framed as a mood rather than a default. It is a theme for when you want your screen to feel alive, not for the eighth straight hour of debugging.

That is also why both themes exist instead of one. Calm is the everyday driver; Neon is the rave you opt into. Same roles, same pipeline, same fourteen tools — one tuned to disappear, the other tuned to shout.

If you want to plug in, every tool gets a single neon file, and you can grab one port or the whole set from the Grimicorn Neon page. The calm original is one click away if your eyes need the quiet back.

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

scheduler.yield(): The One-Liner That Fixes Your INP

Danny Holloran — Sun, 28 Jun 2026 17:20:20 +0000

You click a button, and for a beat nothing happens. The spinner doesn't appear, the page feels stuck, and then everything updates at once. That little hitch is exactly what Interaction to Next Paint measures, and the usual culprit is a long task: a chunk of JavaScript that hogs the main thread so the browser can't paint or respond to input until it finishes.

The old advice was to slice that work into smaller pieces with setTimeout, handing control back to the browser between chunks. It works, but it comes with a tax. scheduler.yield() does the same job without the tax, and it's now available across most browsers. If you've been ignoring it, this is the post that should change your mind.

Why setTimeout yielding hurts

The classic pattern looks like this. You're processing a big array, so you periodically yield:

async function processItems(items) {
  for (const [i, item] of items.entries()) {
    doExpensiveWork(item);
    if (i % 50 === 0) {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }
}

This breaks the long task into shorter ones, which is genuinely good for input delay. The problem is where your continuation lands. When you yield with setTimeout, the rest of your function goes to the back of the task queue. Anything else that got scheduled in the meantime, a third-party analytics callback, another component's work, a different setTimeout, now runs before you get control back. Your loop can stall behind work you don't care about, and a job that should take 100ms stretches out unpredictably.

You yielded to be polite, and the browser took you a little too literally.

What scheduler.yield() does differently

scheduler.yield() returns a promise you can await. Execution pauses at that point and hands the main thread back, exactly like the setTimeout trick, so pending interactions can be serviced. The difference is the continuation gets put in a prioritized queue. When the browser comes back around, your function resumes before other similar tasks that were waiting, rather than after them.

Rewriting the loop is almost anticlimactic:

async function processItems(items) {
  for (const [i, item] of items.entries()) {
    doExpensiveWork(item);
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }
}

Same shape, better behavior. You still let high-priority interaction work jump the line, the whole point of yielding, but your own continuation isn't shoved to the end of an unbounded queue. In Chrome's framing, a scheduler.yield() continuation outranks a scheduler.postTask() task of the same priority level, which is what keeps your loop from getting starved.

A common real-world shape is an event handler that needs to show feedback before doing slow work:

button.addEventListener("click", async () => {
  showSpinner();
  await scheduler.yield(); // let the browser paint the spinner
  doSlowContentSwap(); // then run the expensive part
});

Without the yield, the spinner and the slow swap are one long task, so the spinner never actually appears until the work is already done.

Shipping it without breaking Safari

The honest caveat: scheduler.yield() is a Chromium feature. It's been stable in Chrome and Edge since version 129 (September 2024) and covers roughly 70% of global traffic, but Safari and Firefox don't ship it yet, so you can't call it blind. Feature-detect and fall back.

A tidy inline fallback covers you:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

Now await yieldToMain() gives you the prioritized continuation where it's supported and the plain setTimeout behavior everywhere else. Non-Chromium users still get the benefit of broken-up tasks; they just don't get the queue-jumping bonus.

If you'd rather not hand-roll it, Google Chrome Labs publishes a scheduler-polyfill package that implements the whole Scheduler API. It backs scheduler.yield() with user-blocking postTask() tasks where available and falls through to setTimeout, MessageChannel, and requestIdleCallback otherwise, so you get consistent semantics across browsers from a single import.

Where to actually reach for it

This isn't a sprinkle-everywhere API. The wins come from places where you genuinely run long synchronous-ish work in response to input: rendering a large list after a click, parsing or transforming a big payload, hydrating a heavy widget, or running a sequence of independent setup steps on load. Drop a yield between logical chunks and measure INP before and after with something like the web-vitals library or your RUM tooling.

The pattern to internalize is simple: when a single task does too much, slice it, and when you slice it, yield with scheduler.yield() rather than setTimeout so your own work doesn't pay the price for being considerate. It's one of the rare performance fixes that's both a real improvement and a one-line diff.

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

Building Grimicorn: One Palette, Fourteen Tools

Danny Holloran — Sat, 27 Jun 2026 16:43:48 +0000

A typical day moves through a lot of windows. Editor, terminal, a git client, a notes app, and lately an agentic coding tool or two. Each one ships its own default theme, and even when you pick a "good" one in each, the seams show: the blue that means keyword in your editor means directory in your shell and link in your notes. Your eyes re-learn the color language every time you switch context. It is a small tax, but you pay it hundreds of times a day.

Grimicorn started as a fix for that tax. It is a calm, low-fatigue color theme — the name is grim reaper × unicorn, dead serious but secretly colorful — built on a muted blue-gray base with soft pastel syntax. The real work, though, was not picking the colors. It was making one palette behave identically across fourteen different tools.

Color by role, not by name

The mistake most themes make is thinking in colors instead of roles. "I'll use teal here because it looks nice" is how you end up with a teal that means three unrelated things in three places.

Grimicorn is built around eight core roles, and each role owns a job everywhere it appears. Blue (#83AFE5) is keywords, links, and the primary accent. Green (#A9CE93) is strings, success, and the cursor. Salmon (#DD9787) is errors, invalid input, and deletions. Yellow (#DADA93) is types, decorators, and warnings. The semantic mapping never drifts: green is always "this is good," salmon is always "this is wrong," and accents follow a strict hierarchy of blue → purple → teal so the most important thing on screen is always the same hue.

Once colors are defined by role, porting becomes a translation problem rather than a taste problem. A VS Code tokenColors entry for "string" and a Ghostty ANSI green slot are the same decision wearing different clothes.

One source of truth, many targets

Fourteen tools means fourteen wildly different file formats. VS Code wants JSON with scopes. iTerm2 wants an XML plist of srgb components. tmux wants a config script. Ghostty and Warp want their own flavors of key-value. Maintaining those by hand would guarantee drift — fix a color in one, forget the other thirteen.

So every file is generated from a single source of truth: a grimicorn-palette.md that defines each role once. A small build step reads that palette and emits each target format:

const palette = {
  blue: "#83AFE5", // keywords · links · primary
  green: "#A9CE93", // strings · success · cursor
  salmon: "#DD9787", // errors · invalid · deletions
  // ...eight roles total
} as const;

function toVSCode(p: typeof palette) {
  return {
    "editor.foreground": p.gray,
    tokenColors: [
      { scope: "keyword", settings: { foreground: p.blue } },
      { scope: "string", settings: { foreground: p.green } },
    ],
  };
}

Each tool gets its own emitter — toVSCode, toGhostty, toITerm, toTmux — but they all read the same eight values. Change green once and every one of the fourteen ports regenerates with the new value. That is the whole reason the set stays coherent: there is no place for a stray hex code to hide.

Tuning for low fatigue

The "calm" part is not a vibe; it is a constraint. Nothing in the palette is saturated enough to vibrate against the background. The dark variant rests the same eight roles on a muted blue-gray base; the light variant shifts them toward ink-on-paper without changing what any role means. A six-step background scale (#1E2A31 through #4E5C66) gives panels, gutters, and selections somewhere to sit without resorting to pure black or harsh borders.

Shipping a light variant from the same source is where role-based design pays off again. Light mode is not a separate theme — it is the same role map with each color re-tuned for a bright surface. Blue darkens from #83AFE5 to #4A80C8 so it still reads as the primary accent against paper. Because the roles are fixed, dark and light stay in sync by construction.

The payoff is the thing you stop noticing. Switch from the editor to the terminal to your notes and the color language holds. A string is the same green in all three. Nothing flares. After enough late nights, that quiet is worth more than any single pretty color.

If you want to try it, every tool ships a dark and a light file, and you can grab one port or the whole set from the Grimicorn theme page — all generated, as promised, from that one palette.

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

GraphQL Fragments: Let Each Component Own Its Data

Danny Holloran — Thu, 25 Jun 2026 16:59:10 +0000

A GraphQL query looks clean when you first write it. One request, all the data you need, no waterfall. Then the app grows. The top-level page query starts picking up fields for five different child components. You add an avatar URL for a new <UserBadge> and six weeks later you remove the component but forget the field. Nobody knows what's safe to delete. The query keeps growing.

Fragments are the tool GraphQL gives you to fix this — and most teams underuse them, treating them as a shorthand for copy-pasting field lists rather than as a component ownership model.

What Fragments Actually Are

A fragment is a named, reusable selection of fields scoped to a specific type:

fragment UserBadge on User {
  id
  name
  avatarUrl
}

You spread it into any query or other fragment that selects from User:

query GetPost($id: ID!) {
  post(id: $id) {
    title
    author {
      ...UserBadge
    }
  }
}

That's the basic syntax. The real value comes from where you put the fragment definition — not in a shared fragments.ts file, but in the same file as the component that uses the data.

The Co-location Pattern

Co-location means each component declares the fragment it needs right alongside its JSX. Here's what that looks like with Apollo Client:

import { gql, useFragment } from "@apollo/client";

// Declared next to the component that owns this data
export const USER_BADGE_FRAGMENT = gql`
  fragment UserBadge on User {
    id
    name
    avatarUrl
  }
`;

export function UserBadge({ userRef }: { userRef: UserBadge$key }) {
  const user = useFragment(USER_BADGE_FRAGMENT, userRef);
  return (
    <div>
      <img src={user.avatarUrl} alt={user.name} />
      <span>{user.name}</span>
    </div>
  );
}

The parent component spreads the fragment without knowing what fields it contains:

import { USER_BADGE_FRAGMENT } from "./UserBadge";

const GET_POST = gql`
  query GetPost($id: ID!) {
    post(id: $id) {
      title
      author {
        ...UserBadge
      }
    }
  }
  ${USER_BADGE_FRAGMENT}
`;

Now when UserBadge needs a role field, you add it to the fragment. The query picks it up automatically. When you delete UserBadge, you delete its fragment too, and the query shrinks. The parent never had to know about avatarUrl in the first place.

Data Masking: Enforcing the Boundary

Co-location by convention is good. Data masking makes it a hard rule.

With masking enabled (available in Apollo Client 3.12+ and built into Relay by design), a component can only access fields it explicitly requested in its own fragment. Even if the network response contains avatarUrl because another component requested it, your component gets undefined unless it declared the field itself.

// Without masking: this might work accidentally because a sibling
// component requested avatarUrl in its fragment
const { data } = useQuery(GET_POST);
console.log(data.post.author.avatarUrl); // could be undefined tomorrow if UserBadge moves

// With masking + useFragment: TypeScript errors immediately if you
// access a field your fragment didn't declare
const user = useFragment(USER_BADGE_FRAGMENT, userRef);
console.log(user.avatarUrl); // always safe — it's in YOUR fragment

The TypeScript types generated from your fragments encode this contract. If you remove avatarUrl from UserBadge_Fragment, the TypeScript compiler tells you everywhere you were using it. Refactors that used to require grepping the whole codebase become a type-check run.

Tools like gql.tada and graphql-code-generator with the client-preset generate these types automatically from your fragment definitions, so the feedback loop is tight.

When to Reach for This Pattern

You don't need fragments for a simple app with three queries. The pattern earns its keep when:

Multiple components read from the same type (User, Product, Post)
Your page-level queries are getting long and nobody is sure what each field is for
You've been bitten by "I removed a component but left its fields in the query"
You want TypeScript safety at the data-access level, not just at the query level

Start by identifying one component that fetches its own fields via a parent query. Extract those fields into a fragment, move the definition next to the component, and spread it from the parent. That single refactor will make the pattern obvious, and you'll naturally apply it as you go.

GraphQL's promise is that your data fetching reflects exactly what your UI needs. Fragments are what make that promise hold as the UI grows.

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

CSS @property: Typed, Animatable Custom Properties

Danny Holloran — Mon, 22 Jun 2026 16:38:58 +0000

There's a quiet frustration that hits every developer who first tries to animate a CSS custom property. You write a clean gradient, put the color stop in a variable, add a transition — and it snaps. No animation. Just an instant cut from one value to the next.

The reason is straightforward: the browser doesn't know what --brand-color is. It's just a string as far as CSS is concerned. You can't interpolate a string. @property fixes this by letting you register a custom property with a type, an initial value, and an inheritance rule — turning an opaque blob of text into something the browser can actually reason about and animate.

As of 2026, @property is Baseline Widely Available. Chrome, Firefox, Safari, and Edge all support it. There's no reason not to use it for any non-trivial design system.

The Syntax

A @property declaration requires three descriptors: syntax, inherits, and initial-value (required unless syntax is "*").

@property --brand-hue {
  syntax: "<angle>";
  inherits: false;
  initial-value: 220deg;
}

syntax is the type. The full list of supported types includes <color>, <length>, <percentage>, <number>, <integer>, <angle>, <time>, <resolution>, <transform-function>, <transform-list>, <image>, and <url>. You can also combine types with |, accept a space-separated list with +, or accept any value with "*".

inherits is a boolean. Set it to true if child elements should be able to inherit the value from a parent (like font-related properties). Set it to false to scope it locally — useful for per-component counters or animation state that shouldn't bleed upward.

initial-value is the fallback when no value is set. For most types it's required and must be a computationally independent value — 10px works, calc(var(--base) * 2) doesn't.

The Killer Use Case: Animating Gradients

Before @property, animating a gradient background required JavaScript to interpolate values and update a style attribute on every frame. CSS had no way to do it natively. With @property, you register the color stops as typed properties and transition them directly:

@property --stop-one {
  syntax: "<color>";
  inherits: false;
  initial-value: #6366f1;
}

@property --stop-two {
  syntax: "<color>";
  inherits: false;
  initial-value: #ec4899;
}

.card {
  background: linear-gradient(135deg, var(--stop-one), var(--stop-two));
  transition:
    --stop-one 0.4s ease,
    --stop-two 0.4s ease;
}

.card:hover {
  --stop-one: #0ea5e9;
  --stop-two: #22d3ee;
}

The browser knows --stop-one is a <color>, so it can interpolate between #6366f1 and #0ea5e9 across frames. Smooth, GPU-composited, zero JavaScript.

The same pattern applies to angles for conic gradients, lengths for clip paths, or percentages for color stop positions. Any place you previously needed JS to animate something inside a CSS function, @property is the answer.

Design System Benefits: Type Safety and Scoped Defaults

Beyond animation, @property adds a layer of predictability to token-based design systems. An unregistered custom property set to an invalid value silently falls back to whatever the inherited value or browser default is — which can cause subtle layout bugs that are hard to trace. A registered property with syntax: '<length>' ignores an invalid assignment entirely and keeps the initial-value, which is at least predictable.

The inherits: false flag is particularly useful for component-scoped state. Say you're building a progress indicator that tracks a --progress percentage internally:

@property --progress {
  syntax: "<percentage>";
  inherits: false;
  initial-value: 0%;
}

.progress-bar {
  --progress: 0%;
  width: var(--progress);
  transition: --progress 0.6s ease;
}

Setting inherits: false means each .progress-bar instance manages its own --progress independently. Parent values don't leak in, sibling values don't interfere.

You can also register properties in JavaScript using CSS.registerProperty(), which accepts the same options as the at-rule but lets you do it conditionally at runtime:

CSS.registerProperty({
  name: "--theme-angle",
  syntax: "<angle>",
  inherits: false,
  initialValue: "0deg",
});

The at-rule and the JS API are equivalent — use whichever fits your workflow. The at-rule is usually cleaner for static design tokens; the JS API is handy when the property name or initial value needs to be dynamic.

One Rule to Check

If a CSS transition or animation on a custom property is snapping instead of interpolating, the missing @property registration is almost always why. Add the rule, match the type to what you're actually setting, and the transition starts behaving like any built-in property.

It's a small addition to the stylesheet that unlocks a category of effects that were genuinely impossible in CSS alone just a few years ago.

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

Turning a Base M4 Mac Mini Into an Always-On Automation Box

Danny Holloran — Sun, 21 Jun 2026 22:31:53 +0000

For the last year, most of my personal automation has lived on my MacBook Air. Blog cross-posting, content ingest, SEO, accessibility audits and more, all of it running as scheduled Claude skills. It worked great until I traveled. Close the lid and everything stops. Hop onto hotel WiFi and a schedule that assumed a stable connection quietly fails. An automation you have to babysit is not really automation.

So I bought a Mac mini to be the box that never sleeps.

Why the base M4 (and a recycled hard drive)

I deliberately bought the cheapest M4 mini Apple sells. This is an experiment, not a commitment, but it is not a blind bet either. I have been running this exact set of skills on a comparably specced M-series MacBook Air, including overnight code automation that works through multiple issues and pull requests while I sleep, and it never broke a sweat. If anything the mini should hold up better: that Air is passively cooled, while the mini has an actual fan, so it can sustain a long overnight run without the thermal throttling a fanless laptop eventually hits. The mini runs around ten scheduled skills today and that number only goes up, but none of them are heavy. The only thing that would push me toward a higher-spec mini or a Studio is running local AI models, and I want to learn what I actually need before paying for it.

Storage I solved for free. I had an old 2TB external drive sitting in a drawer, so the mini's modest internal SSD holds the system and the external handles anything bulky. For a headless box you rarely touch, a drive hanging off the back is a non-issue.

Making it actually always-on

A Mac mini does not stay awake just because it has no battery. macOS still sleeps the display, and if it thinks no monitor is attached it can get weird about how things render. Two fixes.

First, kill sleep on AC power:

sudo pmset -c sleep 0 displaysleep 0

The -c flag scopes it to wall power, which is the only state a mini is ever in.

Second, the headless gotcha: with no monitor plugged in, some apps and remote-desktop tools render to a phantom low-resolution screen or refuse to behave. A cheap 4K display emulator (a dummy HDMI plug) makes macOS believe a real monitor is attached, and everything renders at a sane resolution.

The rest is unglamorous but matters. Enable automatic login so an unattended reboot comes back to a logged-in session instead of stalling at the lock screen. And, a real tradeoff, I left FileVault off. FileVault is excellent for a laptop that can be stolen. On a headless box that needs to boot unattended into a usable state with nobody around to type a password, it gets in the way more than it protects.

Controlling it from my phone

The whole point is that this thing runs while I am somewhere else, so I needed solid remote access from an iPhone. The stack that won:

Tailscale is the foundation. It is a mesh VPN, not just a tunnel. It gives the mini a stable private 100.x.y.z address and a MagicDNS hostname that follow it anywhere, so I am not chasing a changing home IP or poking holes in my router. Every device on my tailnet can reach it directly and encrypted.

On top of that, two tools. For a shell I use Blink Shell with mosh, not plain SSH. This matters more than I expected. Plain SSH runs over TCP, and the moment your phone switches from WiFi to cellular the connection dies. Mosh survives network changes, so I can kick off a command at home and still have the session alive on the road. Mosh has to be installed on the server too:

brew install mosh

For full desktop access I use Screens over Tailscale to hit the mini's built-in VNC. Same private address, just the GUI instead of a terminal.

The one part that didn't migrate

This is roughly the tenth Mac I have set up, counting school and work machines, so the OS-level setup was fast. I scripted most of it into a setup.sh and scanned my existing Macs to pull over the configs that were already dialed in. That part went smoothly.

The exception was my Claude schedules. They do not sync across devices, and the timing for when each task fires is not stored in the markdown task files. It lives in a separate task store, so there is no clean export to grab. I ended up recreating the schedules on the mini by hand from the task descriptions. If you run scheduled agent work across machines, know that the schedule itself is the thing that will not come along for free.

What's next

Right now it is an automation box, but that is the boring first job. The plan is to grow it into a proper home server: Home Assistant for the home, NAS duties off that external storage, and a sandbox for self-hosted tools like n8n plus a few local AI experiments. A base mini is a surprisingly capable little anchor for all of it.

If you have automations you are tired of babysitting, a cheap always-on machine you can reach from your pocket changes how much you trust them. Mine has been worth every dollar of the base model.

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

WCAG 2.2: What Frontend Developers Actually Need to Fix

Danny Holloran — Fri, 19 Jun 2026 02:35:02 +0000

If accessibility audits still reference WCAG 2.1 at your company, you're behind. WCAG 2.2 became a W3C Recommendation in October 2023 and is now the version that regulators, auditors, and legal teams point to. In the US, the Department of Justice formally adopted WCAG 2.1 AA as the ADA standard — but in practice, WCAG 2.2 is what modern audits check. The European Accessibility Act, which hit full enforcement for digital products in 2025, also tracks WCAG 2.2.

The good news: WCAG 2.2 is backward compatible. If you're already meeting 2.1 AA, you're not starting over. You have nine new success criteria to address, and several of them are things you probably already knew you should fix.

Focus Indicators: The Changes That Matter Most

Two of the nine new criteria deal with focus, and they're the ones that trip up the most component libraries and design systems.

Focus Not Obscured (SC 2.4.11, Level AA) says a focused element can't be entirely hidden by author-created content. Sticky headers, floating chat widgets, cookie consent banners, and modal overlays are the usual culprits. The rule doesn't require the whole element to be visible — just that it's not completely covered. SC 2.4.12 (Level AAA) goes further and requires the full component to be visible.

Focus Appearance (SC 2.4.11 at AA, 2.4.13 at AAA) finally gives numbers to what a visible focus indicator looks like. At the AA level, the focus indicator must have a perimeter at least as long as the unfocused component's perimeter, and the color change between focused and unfocused states must have a contrast ratio of at least 3:1. The browser default outline in Chrome and Safari passes — outline: none without a replacement does not.

In practice, these two criteria mean: never outline: none without an alternative, and test keyboard navigation on any page that has sticky or fixed-position elements. A quick scroll-and-tab through your interface catches most Focus Not Obscured violations immediately.

/* Bad — removes focus ring with no replacement */
:focus {
  outline: none;
}

/* Good — custom ring that meets contrast + size requirements */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Using :focus-visible instead of :focus means keyboard users see the indicator while mouse users aren't distracted by it. All modern browsers support it.

Touch Targets and Dragging

Target Size Minimum (SC 2.5.8, Level AA) requires interactive elements to have a target size of at least 24×24 CSS pixels. The rule applies to the target itself, not just the visual rendering — spacing counts if it pushes adjacent targets apart. Buttons, links in navigation, and icon-only controls are the places to check. There are exceptions: inline text links and elements whose size is determined by the browser default (like native checkboxes without custom styling) are exempt.

Dragging Movements (SC 2.5.7, Level AA) requires that any functionality using a drag operation has a single-pointer alternative. A sortable list that only works via drag-and-drop fails this criterion unless there's also an up/down button, a cut-and-paste mechanism, or some other way to accomplish the same task without dragging. If you're using a drag library like dnd-kit or react-beautiful-dnd, this is worth auditing.

Authentication and Forms

Accessible Authentication (SC 3.3.8 at AA, 3.3.9 at AAA) is the criterion that generated the most discussion when 2.2 dropped. It says a cognitive function test — remembering a password, solving a CAPTCHA, transcribing characters — cannot be required as the only way to authenticate. The criterion doesn't ban passwords, but it does require that if you use a password, users can paste into the field (so password managers work), autofill is allowed, or a copy mechanism is available.

In practical terms: don't block paste on password inputs, don't disable autocomplete on login forms, and consider adding magic links or passkeys as alternatives.

Redundant Entry (SC 3.3.7, Level A) says information already provided in a multi-step process shouldn't be required again — unless there's a security or validity reason. A checkout flow that asks for billing address, then asks for the same address again on a review screen, fails this criterion. The fix is either to pre-fill or carry information forward between steps.

Where to Go From Here

The fastest way to catch most of these issues is to run your UI through a keyboard-only navigation pass and check with an automated tool like axe or Lighthouse — though automated tools catch only about 30–40% of accessibility issues, so manual testing matters. For WCAG 2.2 specifically, the new criteria around focus, target size, and authentication aren't well-detected by automated scanners yet.

WCAG 3.0 is on the horizon — a March 2026 Working Draft landed with 174 requirements and a new scoring model that moves away from the binary pass/fail system — but it's realistically 2028–2030 before it's a Recommendation. WCAG 2.2 is what you need to ship against right now.

The nine new criteria aren't a massive lift if you tackle them systematically. Start with focus indicators (they're the most commonly broken), then work through target sizes and authentication, and you'll be in solid shape for any current accessibility review.

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

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.

DEV Community: Danny Holloran

Invoker Commands: Wiring Buttons to Dialogs and Popovers Without JavaScript

Two attributes, no listener

Why this beats a click handler

Custom commands for your own behavior

Where support stands

Fallow: A Codebase Truth Layer for Agent-Written Code

What Fallow actually checks

Where it fits with my other guardrails

Getting started

The Navigation API: Stop Wrestling with history.pushState

One event to rule every navigation

The decisions the old API made you guess at

Async routes that cancel themselves

Grimicorn Neon: When a Calm Theme Goes Loud

Eight roles, eight louder hexes

The near-black base is doing real work

Loud is a tradeoff, not a free upgrade

scheduler.yield(): The One-Liner That Fixes Your INP

Why setTimeout yielding hurts

What scheduler.yield() does differently

Shipping it without breaking Safari

Where to actually reach for it

Building Grimicorn: One Palette, Fourteen Tools

Color by role, not by name

One source of truth, many targets

Tuning for low fatigue

GraphQL Fragments: Let Each Component Own Its Data

What Fragments Actually Are

The Co-location Pattern

Data Masking: Enforcing the Boundary

When to Reach for This Pattern

CSS @property: Typed, Animatable Custom Properties

The Syntax

The Killer Use Case: Animating Gradients

Design System Benefits: Type Safety and Scoped Defaults

One Rule to Check

Turning a Base M4 Mac Mini Into an Always-On Automation Box

Why the base M4 (and a recycled hard drive)

Making it actually always-on

Controlling it from my phone

The one part that didn't migrate

What's next

WCAG 2.2: What Frontend Developers Actually Need to Fix

Focus Indicators: The Changes That Matter Most

Touch Targets and Dragging

Authentication and Forms

Where to Go From Here

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

`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