DEV Community: Danny Holloran

CSS text-box-trim: The End of Fudging Vertical Padding

Danny Holloran — Fri, 14 Aug 2026 08:05:34 +0000

You give a button padding: 12px and it comes out looking bottom-heavy. So you split it: padding: 10px 12px 14px, squint, nudge the numbers, ship it. Two sprints later design swaps the type family and every one of those hand-tuned values is wrong again, because the new font reserves a different amount of invisible space than the old one did.

That invisible space has a name, and as of this month you can finally cut it off.

Where the extra space comes from

Every font ships with metrics that describe more than the letters you can see. There's room above the capitals for accents and diacritics, and room below the baseline for descenders, and the browser reserves all of it whether or not a single "p" appears in your text. On top of that, line-height adds leading, which the web splits in half and distributes evenly above and below the content area. Matthias Ott's The Thing With Leading In CSS walks through the typesetting history behind that split, but the practical upshot is simple: a text box is always taller than its text, by an amount that changes per font and per line-height.

Symmetric padding on top of an asymmetric box gives you an asymmetric-looking result. That's the whole bug.

The two properties

text-box-trim says which edges to cut. text-box-edge says where to cut to.

h1 {
  text-box-trim: trim-both; /* trim-start | trim-end | trim-both | none */
  text-box-edge: cap alphabetic; /* over-edge, then under-edge */
}

cap trims the over edge down to the top of the capital letters. ex trims to the x-height instead, which is a nicer optical match for some display faces. alphabetic trims the under edge flush with the baseline. There's a text value on both sides if you want the font's own text edges rather than the letterform edges.

In practice you'll write the shorthand and move on:

button {
  text-box: trim-both cap alphabetic;
  padding: 12px;
}

That's the version you want roughly all of the time. Now padding: 12px actually means twelve pixels of visible space on every side, in every font, and swapping the type family doesn't silently re-break your spacing.

Where it actually pays off

Optical centering. Buttons, badges, pill-shaped tags, anything small and intrinsically sized. These are the components where half-leading is proportionally largest and most obvious.

Aligning text next to non-text. Put a 40px avatar beside a heading and the heading's box is taller than its letters, so the two never quite line up. Trim the heading and they do.

Gaps that mean something. In a stacked block of text, gap and margin-block measure box edges, which include the invisible band on both sides. Trim the leading and your rhythm values start describing the space a reader actually perceives, instead of that space minus an unknown font-dependent constant.

One caveat worth being deliberate about: trimming removes visual space, not just visual space you didn't want. If you trim a button and don't add the padding back, you've quietly shrunk the tap target. WCAG 2.2's target size minimum is 24 by 24 CSS pixels, and half-leading was doing invisible work toward that number. Trim, then set the padding you actually meant.

Multi-line text behaves the way you'd hope: the trim applies above the first formatted line and below the last one, never between lines. And because it's defined in terms of over and under rather than top and bottom, it follows writing-mode correctly without any extra work.

Shipping it

Chrome and Edge have had this since 133, Safari since 18.2, and Firefox 154 turns it on by default. That release is dated August 18, 2026, which makes text-box a Baseline newly-available feature about a week from now.

Even before that lands everywhere, the failure mode is the kindest one CSS offers: a browser that doesn't recognize the property ignores the declaration and renders the spacing it always did. Nothing collapses, nothing overlaps, you just don't get the tightening. That makes it safe to add today with no fallback at all.

If the trimmed spacing is load-bearing in a particular component, gate the compensating padding behind a feature query so the two values stay in sync:

.tag {
  padding: 6px 12px;
}

@supports (text-box: trim-both cap alphabetic) {
  .tag {
    text-box: trim-both cap alphabetic;
    padding: 10px 12px;
  }
}

If you've ever used Figma's vertical trim control and wondered why the handoff never matched, this is the missing half. Adam Argyle's Chrome for Developers post has an interactive playground that's worth ten minutes of poking at with your own type stack, and the MDN reference has the full value grammar. Start with your buttons. The difference is small, and you will not be able to unsee it.

Trusted Types Is Baseline: DOM XSS Is Now a Type Error

Danny Holloran — Tue, 11 Aug 2026 08:05:20 +0000

Every codebase has one. Somewhere in a component nobody has opened in eighteen months, there is a line that reads el.innerHTML = someValue, and nobody can tell you with confidence where someValue comes from. Maybe it's a hardcoded template. Maybe it's a server response. Maybe, three refactors ago, it started carrying a slice of location.hash. That uncertainty is the entire DOM XSS problem: the sink is a plain string setter, strings all look alike, and the browser has no way to tell a trusted one from an attacker-controlled one.

Trusted Types fixes that by refusing strings outright. And as of February 2026, when Firefox 148 shipped support, it's Baseline — Chrome and Edge have had it since 83 back in 2020, Safari joined in version 26, and now the whole core browser set is covered. It's no longer a Chrome-only hardening trick you bolt onto an internal admin tool.

Turning a whole class of bug into a runtime error

The API works by locking down the risky sinks: innerHTML, outerHTML, insertAdjacentHTML, document.write, DOMParser.parseFromString, <iframe srcdoc>, script src and text content, and the code-compiling family (eval, new Function(), string-argument setTimeout and setInterval). Once enforcement is on, passing a raw string to any of them throws a TypeError.

You opt in with a CSP header:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types escape-html;

That first directive is the switch. The second is an allowlist of policy names — factories that are the only things permitted to mint a trusted value:

const escapeHTMLPolicy = trustedTypes.createPolicy("escape-html", {
  createHTML: (input) => input.replace(/</g, "&lt;"),
});

const safe = escapeHTMLPolicy.createHTML("<img src=x onerror=alert(1)>");
safe instanceof TrustedHTML; // true
el.innerHTML = safe; // fine

el.innerHTML = userInput; // TypeError

Note what this actually buys you. Trusted Types does not sanitize anything — your createHTML function is still your own code and can still be wrong. What it guarantees is that every path into a dangerous sink now runs through a named policy you declared on purpose. The DOM XSS attack surface of the entire app collapses down to the handful of lines inside your policies. That is a security review you can finish in an afternoon instead of grepping 40,000 lines for innerHTML.

Also worth knowing before you start: Trusted Types only works in secure contexts, so HTTPS or localhost.

Rolling it out without breaking production

Do not flip enforcement on first. Ship the report-only variant, let it run against real traffic, and collect what breaks:

Content-Security-Policy-Report-Only: require-trusted-types-for 'script'; report-uri /csp-reports

Violations arrive with the file, line, column, and a script-sample snippet of the offending value, which is usually enough to find the culprit immediately. If you'd rather not stand up a collector on day one, a ReportingObserver gets you the same data in the console:

new ReportingObserver(
  (reports) => {
    for (const r of reports) {
      if (r.body.effectiveDirective === "require-trusted-types-for") {
        console.warn("Trusted Types violation:", r.body);
      }
    }
  },
  { buffered: true },
).observe();

Then work the list. Most violations have a boring fix — the code didn't need string HTML in the first place:

// before
el.innerHTML = "<img src=xyz.jpg>";

// after
el.replaceChildren(
  Object.assign(document.createElement("img"), { src: "xyz.jpg" }),
);

Where you genuinely need to render untrusted HTML, reach for a sanitizer that already speaks the protocol. DOMPurify will hand back a TrustedHTML instead of a string if you ask:

import DOMPurify from "dompurify";
el.innerHTML = DOMPurify.sanitize(html, { RETURN_TRUSTED_TYPE: true });

The escape hatch is a policy literally named default, which the browser applies to any string that reaches a sink without one. It's the right tool when a third-party script from a CDN is the thing violating and you can't patch it. Use it grudgingly — a default policy re-centralizes all your sanitization decisions in one function that has no idea what context it's being called from, which is most of the way back to where you started.

Where this fits

Trusted Types and the Sanitizer API solve adjacent halves of the same problem and pair well: the Sanitizer decides what HTML is safe, Trusted Types enforces that something made that decision at all. Neither replaces a strict, nonce-based CSP for the server-rendered side of XSS.

If you own an app that handles anything sensitive, the report-only header is close to free — one line of config, zero behavior change, and a list of exactly where your DOM XSS risk lives. Start there, and decide later whether to enforce.

Further reading: MDN's Trusted Types API reference and the web.dev deep dive.

The Long Animation Frames API: Find What Actually Broke Your INP

Danny Holloran — Mon, 10 Aug 2026 08:06:37 +0000

Your real user monitoring dashboard says the 75th percentile INP on your product page is 412ms. You open DevTools, click the same button forty times, and every interaction comes back at 60ms. Nothing reproduces. So you start guessing: maybe it's the analytics tag, maybe it's the third-party chat widget, maybe it's that one useEffect that everybody is afraid to touch.

The Long Tasks API was supposed to help here, and it mostly didn't. It would tell you a task ran for 210ms and attribute it to "self" or an iframe container, which is roughly as actionable as a smoke alarm that only reports "somewhere in the house." The Long Animation Frames API is the replacement, and it does the thing you actually wanted all along: it hands you a script URL, a function name, and a character offset.

A frame is a better unit of measurement than a task

Slow interactions are rarely one fat task. They're usually five medium tasks, a ResizeObserver callback, and a style recalculation, all landing between two paints. Long Tasks only saw the fat ones, and it stopped measuring before rendering even started.

LoAF widens the window. It reports on any animation frame whose total work exceeded 50ms, covering everything from the first task in that frame through style, layout, and paint. Entries arrive with entryType of long-animation-frame:

const observer = new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    console.log({
      duration: frame.duration,
      blockingDuration: frame.blockingDuration,
      scriptTime: frame.renderStart ? frame.renderStart - frame.startTime : 0,
      styleAndLayout: frame.styleAndLayoutStart
        ? frame.paintTime - frame.styleAndLayoutStart
        : 0,
    });
  }
});

observer.observe({ type: "long-animation-frame", buffered: true });

Four timestamps do most of the work. startTime is when the frame began, renderStart is when script handed off to the rendering pipeline, styleAndLayoutStart is where recalc and layout begin, and paintTime is where it ends. Subtracting them tells you whether you have a JavaScript problem or a layout problem, which are fixed in completely different ways.

The one field to alert on is blockingDuration. It sums the over-50ms portion of every long task in the frame plus the rendering time, so it approximates how long the main thread was genuinely unavailable to a user. A 300ms frame with a 20ms blockingDuration is fine. A 120ms frame with a 90ms blockingDuration is not.

Script attribution is the whole point

Every LoAF entry carries a scripts array of PerformanceScriptTiming objects, and this is where the guessing stops:

const worst = frame.scripts.sort((a, b) => b.duration - a.duration)[0];

console.log({
  url: worst.sourceURL, // https://cdn.example.com/widget.js
  fn: worst.sourceFunctionName, // handleScroll
  char: worst.sourceCharPosition, // 18422
  invoker: worst.invoker, // window.onscroll
  invokerType: worst.invokerType, // event-listener
  duration: worst.duration,
  forcedLayout: worst.forcedStyleAndLayoutDuration,
  paused: worst.pauseDuration,
});

invokerType tells you how the script got run: event-listener, user-callback, resolve-promise, module-script, classic-script. That distinction matters, because a slow event-listener is your code to fix and a slow classic-script during load is usually a tag manager you need to defer.

forcedStyleAndLayoutDuration is quietly the best field in the API. If it's a meaningful chunk of duration, you have layout thrashing: something read offsetHeight or getBoundingClientRect() inside a write loop and forced synchronous layout. You now know which function, in which file, at which character.

The caveat worth knowing before you build dashboards on this: attribution only covers same-origin main-thread scripts. Cross-origin iframes, web workers, service workers, and browser extensions can lengthen a frame without ever showing up in scripts. When you see a big duration with a nearly empty scripts array, that absence is itself the signal.

Tie it to the interaction, not just the clock

A stream of slow frames is noise until you connect it to a specific bad interaction. The easiest path is web-vitals with the attribution build, which already correlates LoAF entries with the INP interaction for you:

import { onINP } from "web-vitals/attribution";

onINP(({ value, attribution }) => {
  if (value < 200) return;

  const culprit = attribution.longAnimationFrameEntries
    .flatMap((frame) => frame.scripts)
    .sort((a, b) => b.duration - a.duration)[0];

  beacon("/rum", {
    inp: value,
    target: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processing: attribution.processingDuration,
    presentation: attribution.presentationDelay,
    script: culprit && `${culprit.sourceURL}:${culprit.sourceFunctionName}`,
  });
});

Send the single worst script, not the whole entry. A busy page can produce dozens of LoAFs in a session and serializing all of them will cost you more than the insight is worth.

LoAF shipped in Chrome 123 after an origin trial, and it's still Chromium-only. That sounds limiting until you remember that Chrome is also where your Core Web Vitals field data comes from, so the coverage gap and the metric you're optimizing line up almost exactly. Start by logging blockingDuration and the top script for interactions over 200ms, then read the Chrome documentation and the spec once you know which part of your frame is actually on fire.

Invoker Commands: Wiring Buttons to Dialogs and Popovers Without JavaScript

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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

Originally published on danholloran.me

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.