DEV Community: Dimon

The Inline HTML Almost Nobody Uses

Dimon — Tue, 16 Jun 2026 16:54:33 +0000

Everyone knows <b>, <i>, <a>, and <code>. But HTML has a whole second cast of inline elements that most developers go entire careers without typing once — <ins>, <dfn>, <abbr>, <var>, <q>, <mark>. Not because they're broken or deprecated. They're rare because the use cases are genuinely narrow, and when one does come up, the reflex is to reach for a <span class="something"> instead.

I bumped into this building out a prose/content section for a UI system — once you start styling text properly, you notice how many real semantic elements you'd been ignoring. So here's the whole forgotten cast, in a single sentence that legitimately uses eleven of them:

Here's what that actually is:

<p>
  The experiment revealed <mark>a significant energy spike</mark> in
  the reactor core. Previous readings of
  <del>42.7 terawatts</del> were revised to
  <ins>51.3 terawatts</ins> after recalibration. The formula
  <var>E</var> = <var>mc</var><sup>2</sup> governs the conversion,
  where H<sub>2</sub>O serves as the coolant medium.
  <abbr title="Void Energy Reactor Interface">VERI</abbr> logs
  confirm the anomaly. As Dr. Vasquez noted,
  <q>the readings exceed all theoretical models</q>
  (<cite>Void Research Quarterly</cite>). This phenomenon, known as
  <dfn>energy cascade</dfn>, occurs when containment thresholds are
  breached. The <s>original safety protocols</s> have since been
  replaced.
</p>

The cast, and where you'd actually use each

Edits and corrections. <ins> and <del> are added and removed content — they pair up for change tracking, and both accept datetime and cite attributes so the edit is machine-readable. <s> is the one people conflate with <del>: it marks content that's no longer accurate or relevant (a stale price, an outdated claim), which is a different statement than "this was deleted." Two elements exist precisely because those mean different things.

Notation. <sub> and <sup> are for cases where the position carries meaning — chemical formulas (H₂O), exponents (I²R), ordinals, footnote markers — not for "make it small and raised." <var> is a variable in math or code, which is why P, I, and R above are each wrapped in one.

Reference and meaning. <mark> is a relevance highlight — it's literally what search engines use to highlight your query in the results. <abbr title="…"> gives an abbreviation its expansion, surfaced as a tooltip. <dfn> marks the one spot where a term is defined (its introducing instance, not every later mention). <cite> is the title of a work — a book, paper, album — and notably not a person's name, which is the thing nearly everyone gets wrong. And <q> is an inline quotation where the browser inserts the quotation marks for you: correct for the document's language, and correctly nested if you put a quote inside a quote. You never type a " again.

Why bother

Every one of these throws a bit of meaning into the page that a styled <span> silently discards. Screen readers announce them. <q> localizes its punctuation. <abbr> exposes the long form. <ins>/<del> are a real, parseable changelog. A <span class="highlight"> looks the same and means nothing.

The only honest reason to avoid them is that the browser defaults are inconsistent and, frankly, ugly — <mark> is highlighter-yellow, <q>'s marks are whatever, half of them are unstyled. But that's a few lines of CSS, not a law of physics. Give <mark> a brand-tinted background, <ins> a green underline, <abbr> a dotted one, <q> colored quote marks, <dfn> an italic weight — and suddenly an entire sentence of semantic richness reads as clean, deliberate typography.

Most of these you'll reach for maybe once a year. But once a year correctly — with the meaning intact and the styling handled — beats a <span> that's lying about what it is.

Liquid glass needs a ladder

Dimon — Sun, 14 Jun 2026 13:02:34 +0000

Everyone wants the lens right now — the Apple-style glass where content doesn't just blur behind a surface but visibly bends around its rim. And you can build it on the web today: SVG displacement filters plugged into backdrop-filter produce a genuinely convincing lens.

Here's the problem: backdrop-filter: url(#some-svg-filter) works in exactly one engine family. Safari ignores it. Firefox does something worse — it parses it as valid, then renders nothing, which turns your beautiful glass panel into a fully transparent hole with text floating over whatever's behind it. And even where it works, it costs real GPU time that a phone doesn't want to spend.

So the question isn't "how do I build liquid glass." It's "how do I ship liquid glass to the users who can render it without shipping a broken page to everyone else." The answer that ended up in the design system I've been building is a ladder — four tiers of glass, each falling through to the one below automatically:

Tier	What it is	Gate
2 — geometric lens	per-element displacement map matched to the surface's shape	opted-in signature surfaces only
1 — noise warp	one global SVG turbulence filter — the "liquid" wobble	Chromium, confirmed at runtime
0 — blur + saturate	plain CSS `backdrop-filter: blur() saturate()`	`@supports (backdrop-filter: …)`
— opaque surface	a solid background color	none — this is the floor

A surface that opts into the lens but runs on Firefox falls back to the noise warp's gate, fails that too, and lands on plain blur. A browser with no backdrop-filter at all gets a solid, fully readable panel. Nothing configures this per-surface; the gates compose. You can't regress anything — each tier only ever adds on top of what's already there.

The rest of this post is the four decisions that made the ladder actually work, because the tier table is the easy part.

1. Never trust `url()` in backdrop-filter — gate it twice

The naive version writes the SVG filter reference straight into the stylesheet. Two real failures come out of that:

Firefox accepts the declaration as syntactically valid — so your @supports checks pass — and then renders nothing. The surface becomes transparent. This is the nastiest kind of cross-browser bug: not a missing enhancement, an actively broken page.
Chromium has a race: if the CSS references the filter before the SVG node is hydrated into the DOM, the surface flashes transparent on load.

The fix is to never let CSS reference the filter unconditionally. The stylesheet keys the tier-1 rule on an attribute — html[data-liquid-glass] — and a tiny runtime sets that attribute only after two things are true: the SVG filter is actually in the DOM, and the engine is one that can render it. CSS stays declarative, the gate is one attribute, and a browser that would break simply never matches the selector — leaving tier 0's plain blur standing.

2. Hold the blur constant across every tier

The ladder upgrades a surface after first paint: tier 0 renders immediately, then the runtime confirms the engine and swaps in the higher tier a few hundred milliseconds later. That lag is harmless only as long as the upgrade is invisible.

The first version I built wasn't. I'd tuned each tier's blur on its own, and they didn't match — the base tier ended up noticeably heavier than the lens. So every page load played out the same way: a surface painted with that heavy frost, then visibly thinned out to a much lighter blur the moment the lens kicked in. The material itself appeared to change mid-load. It read as a glitch, because it was one.

The rule that fixed it: all three tiers share the exact same blur radius. Stepping from tier 0 to 1 to 2 only ever swaps the displacement — the wobble, the rim bend — never the frost amount. Upgrades become invisible; the surface just quietly gains refinement. If you build any multi-tier visual effect, find the parameter the eye anchors on (here: blur) and freeze it across tiers. Degrade and upgrade along every other axis.

3. The lens is for small chrome — and that's a feature

The geometric lens displaces a band along the surface's rounded border. On a small element — a pill-shaped nav bar, a floating control, the circles in the video above — that rim refraction is gorgeous. On a large surface it falls apart in a specific way: any high-contrast straight edge in the backdrop kinks where it crosses the lens's corner, and with nothing to frame that bend it reads as a rendering bug, not as glass.

I learned this the expensive way: I put the lens on modals and a command palette, it looked wrong for exactly this reason, and I pulled it back to the noise warp. The scope rule that survived: tier 2 is opt-in, per signature surface, small chrome only. Tier 1 stays the default for every other glass surface. Not every tier of an enhancement ladder should be a global upgrade — sometimes the top tier earns its place precisely by being rare.

4. Engine and feature aren't the only gates

The full gate list for the lens tier ended up being five conditions, and only one of them is the classic @supports:

Feature — backdrop-filter exists at all (tier 0's gate).
Engine — Chromium, because of the Firefox parse-but-don't-render trap above.
Material — the surface is actually glass right now. (My system has multiple visual physics (glass / flat / retro), and the lens applies only under glass; switch themes and it releases itself.)
Pointer — fine pointers only. The lens is a desktop refinement; on touch devices it's GPU cost without payoff, so phones get the noise warp or plain blur.
Motion preference — prefers-reduced-motion disables the displacement and falls back to the static blur chemistry.

"Progressive enhancement" usually gets shortened to a single @supports query. For filter-level effects, it's a matrix — feature, engine, material, input device, accessibility preference — and the clean way to manage that matrix is exactly the ladder: every gate that fails just drops the surface one tier, and every tier below is already correct.

The demo

The video at the top is one page with three circles over the same scrolling backdrop — tier 0, tier 1, tier 2, side by side. Watch the stripes: under plain blur the edges soften but stay straight; under the noise warp they wobble; under the lens they bend around the rim while the center stays calm. Same markup, same blur radius, three different filters — and on a browser that can't render the fancy ones, all three circles would quietly look like the first.

That's the whole idea. Liquid glass isn't one effect; it's a ladder you let each browser climb as far as it can.

The three physics of UI: glass, flat, and retro

Dimon — Fri, 12 Jun 2026 14:26:24 +0000

Every design system I've used has a theme switcher. Dark mode, light mode, maybe an accent color. And after you've swapped every color in the palette, all of your themes still behave like the same material: shadows fall the same way, corners curve the same way, hover states move at the same speed with the same easing. You haven't changed what the UI is made of. You've repainted it.

When I designed theming for the design system I've been building, I ended up splitting it into three independent axes:

Palette — which colors.
Mode — light or dark.
Physics — what material the interface is made of.

This post is about the third axis: what a "physics" actually is, why my system ships exactly three of them, and the one physics × mode combination it refuses to render.

What I mean by "physics"

A material, in UI terms, is a set of rules about light and time. Not a color — a behavior. My system has three:

Glass — the object emits light. Surfaces are translucent with a backdrop blur. Borders are thin. Shadows aren't black — they're derived from the canvas color, so depth reads as atmosphere, not dirt. On hover, elements physically lift a few pixels, and the lifted shadow includes a glow in the accent color, because in this material the surface itself is the light source. Motion is springy: overshooting cubic-beziers, slightly slower durations. Things float.

Flat — external light casts shadows. Surfaces are opaque. Shadows are neutral black at very low opacity — 5 to 10 percent, the way paper shadows under office lighting actually look. Nothing glows, ever. Nothing lifts on hover. Easing curves are quick and polite, with no overshoot. This is the material almost every product you use today is made of.

Retro — there is no light model. No soft shadows at all. The "shadow" under a raised element is drawn, not cast: a hard 3px 3px 0 offset in a solid color, the way a pixel artist would draw it. Border radius is zero everywhere. Borders are thick. And — my favorite detail — every duration token is 0ms, and the easing functions are steps(2) and steps(4). State changes snap. The era this material quotes couldn't animate, so the material doesn't either.

In CSS, the whole mechanism is one data attribute and a set of custom properties:

[data-physics='glass'] {
  --radius: 12px;
  --speed: 300ms;
  --ease: cubic-bezier(0.34, 1.56, 0.64, 1);  /* springy, overshoots */
  --lift: -3px;                               /* hover raises the surface */
  --shadow-lift: 0 8px 28px -4px var(--shadow-tint),
                 0 0 12px var(--glow);        /* ...and it glows */
}

[data-physics='flat'] {
  --radius: 12px;
  --speed: 130ms;
  --ease: cubic-bezier(0.22, 0.61, 0.36, 1);  /* quick, no overshoot */
  --lift: 0px;                                /* nothing floats */
  --shadow-lift: 0 4px 12px rgb(0 0 0 / 0.1); /* neutral, barely there */
}

[data-physics='retro'] {
  --radius: 0;
  --speed: 0ms;                               /* state changes are instant */
  --ease: steps(2);                           /* what little moves, steps */
  --lift: -2px;
  --shadow-lift: 3px 3px 0 var(--accent-dim); /* drawn, not cast */
}

Components only ever consume the variables — var(--speed), var(--ease), var(--shadow-lift) — and never know which material they're rendered in. That's the entire trick. One component tree, three materials, zero per-component branching.

Why these three? Because UI history did it first

I didn't pick three aesthetic moods I happened to like. The three materials fall out of how screen UI actually evolved:

1. The terminal era (retro, dark). Phosphor characters on a black tube. A character grid: hard edges, no curves, no transitions — the screen redraws, it doesn't animate. Green or amber light on darkness.

2. The paper era (retro, light). When bitmapped GUIs arrived — the Xerox Alto, the original Macintosh — they were deliberately black-on-white, because the metaphor was paper. Documents, desktop publishing, WYSIWYG. The geometry stayed hard and the motion stayed instant; only the light flipped. Today's neo-brutalism trend is this era quoted back at us.

3. The flat era (flat, both modes). Metro, then iOS 7, then Material. The industry threw out texture and ornament and settled on the external-light model: opaque surfaces, minimal neutral shadows, restrained motion. This is still the mainstream default — it's what "a normal app" looks like in 2026.

4. The glass era (glass, dark). This one has been trying to happen for twenty years. Aero shipped translucent window chrome in 2007 and the hardware mostly couldn't carry it. iOS 7 smuggled frosted blur into the system even while flattening everything else. Then the glassmorphism trend, and now Apple has pushed translucent, light-emitting material across its entire platform line. The new trend is becoming the new mainstream.

The obvious objection: where's skeuomorphism? Where are the leather calendars and felt game tables of the 2000s? My answer is that skeuomorphism was never a light model — it was the external-light model wearing theatrical decoration. Textures, bevels, stitching: all of it was imagery layered onto the same physics flat design uses. Which is exactly why, when the decoration fell out of fashion in 2013, what remained underneath was flat. Materials survive trend cycles; decoration doesn't. That's the test I use for whether something deserves to be a physics.

So: three light models in roughly fifty years of screens. Everything else that looks like a "different era" is a palette riding on one of these three.

The part I didn't expect: physics owns time

I went into this thinking the physics axis was about shadows and corners. The bigger payoff turned out to be motion.

Most design systems define one global motion scale — duration-fast: 150ms, ease-standard: ... — and every theme inherits it. Which means every theme moves identically, and that's a big part of why ten themes can feel like the same product wearing different shirts.

In my system, duration and easing tokens live inside the physics layer. The consequence: a modal opening under glass enters slowly with a soft overshoot, like something surfacing through liquid. The same modal, same component, same code, under retro appears in two frames via steps(2). Under flat it's quick and businesslike. No component opted into any of this. Moving time into the material was a one-time architectural decision that made every current and future component era-correct for free.

If you take one implementation idea from this post, take that one: a material is a light model plus a time model. If your timing tokens are global, your materials are paint.

The combination I refuse to render

Three physics × two modes = six combinations. My system ships five. Ask for glass in light mode and the runtime silently corrects it to flat.

That sounds like a bug, or at best laziness. And I know the obvious objection: Apple has spent years teaching everyone that glass looks perfect in light mode. So let me be precise about what I'm actually claiming — because it's narrower, and it's defensible.

The claim is not "light glass can't exist." The claim is that this glass — and most glassmorphism you see on the web — is an emissive material, and emission doesn't survive light mode. Dark glass differentiates itself through accent glows, canvas-tinted shadows, specular highlights on translucent surfaces. All of that reads because it's light against darkness. A light surface cannot emit — light-on-light is invisible. That's optics, not taste.

Strip the emission out and what's left is translucency: backdrop-filter: blur(). And blur has a precondition people forget — it needs something behind it. Blur is an averaging filter, and the average of a solid color is the same solid color. You can verify this in ten seconds: open any glassmorphism demo and replace the background photo with plain white. The glass disappears.

Apple never faces this problem, because Apple designed the content to always be there. Their glass is OS chrome — toolbars, docks, tab bars — floating over wallpapers and scrolling feeds. The backdrop is guaranteed. And where blur alone isn't enough, their material leans on refraction: edge lensing, specular highlights, content-aware tinting. Notice that's a different optical mechanism from emission. What Apple ships in light mode isn't dark glass with a light palette — it's another material, engineered for light from the start. Even then, they spent an entire beta cycle publicly seesawing its transparency after legibility complaints, and "Reduce Transparency" exists as an accessibility setting for a reason. Light glass walks a knife edge between invisible and illegible, and that edge is exactly where the world's best-resourced design team keeps adjusting its footing.

Product UI — the kind my system targets — is mostly panels over a solid canvas. No wallpaper, no photo feed passing behind every card. In that context, an emissive glass with the emission turned off renders identically to flat, except you're paying GPU cost for blur the user can't see. And a physics in my system is global: every surface, every component, the whole page. A material that's only visible where imagery happens to pass behind it isn't a material — it's an effect. Rather than ship a combination that quietly renders as flat-but-slower, the runtime corrects it.

So the matrix is deliberately ragged:

	dark	light
glass	✓	→ corrected to flat
flat	✓	✓
retro	✓	✓

I used to feel uneasy about that hole — asymmetric APIs look like design debt. I now think the opposite: mode support is a property of the material. The asymmetric matrix is physical honesty. The dishonest version is the complete matrix where one cell silently renders as a worse version of another cell.

And Apple doesn't contradict this — Apple confirms it. They earned light mode by engineering a refraction-first material from scratch, not by relaxing a dark one. If I ever want light glass, that's the honest path: a fourth physics, built for light, with its own rules. Never a palette swap on this one.

The clamp I got wrong

Here's the part that earns the previous section, because I almost made the same call twice and one of them would have been a mistake.

Originally retro was clamped to dark mode too. CRTs are dark — obviously. But when I actually audited why retro needed darkness, the material decomposed into two layers. There's a phosphor layer — the emissive, glowing-characters-on-black part — which is genuinely dark-only, same argument as glass. And there's a structural layer — zero radius, stepped motion, hard drawn offsets — which doesn't reference light at all.

Put the structural layer on warm paper-colored ink with a typewriter monospace and you don't get "broken retro." You get the paper era from the history section: early Mac, print, neo-brutalism. Historically real, visually coherent, and it cost almost nothing to support because the geometry never cared about mode in the first place. The dark coupling had been palette convention, not physics.

So I asked the same question of two materials — "can this work in light mode?" — and got opposite answers. Glass: no, because its identity is emission. Retro: yes, because its identity is geometry. The answer lives in the material, not in the theming API. A blanket rule in either direction — "every physics supports both modes" or "exotic physics are dark-only" — would have been wrong once.

What I'd steal from this if I were you

You don't need three materials. But if you're building or maintaining a theme system, four things transfer:

Make material an axis, orthogonal to palette and mode. Even two materials force the right architecture: components consume physics variables and stop hardcoding what light does.
Define a material as light + time. Shadows, radius, blur — and durations, easings, hover displacement. The motion half is the one everyone forgets and the one users feel most.
Let materials refuse modes. Auto-correct invalid combinations at the runtime level instead of rendering something subtly broken. A ragged support matrix you can explain beats a complete one you have to apologize for.
Before adding a theme, ask: new light model, or new colors? Almost always it's new colors — a palette entry, cheap, add as many as you want. A new light model is rare and expensive. UI history has produced about three in fifty years. If you think you've found a fourth, you're either wrong or you're early — both are worth knowing.

The whole industry is mid-transition into the glass era right now, which makes it a strange and useful moment: for once, the mainstream material and the trending material are different. A theme switcher can't express that difference. A physics axis can.

Picking Svelte in 2026: the honest tradeoff nobody tells you

Dimon — Tue, 09 Jun 2026 13:06:07 +0000

The honest version of "which framework should I use in 2026" is boring: use React. It's the safe answer. The ecosystem is enormous, every other dev already knows it, and you will never get fired for choosing it. I went with Svelte + Astro instead. Not because React is bad — it isn't — but because for the kind of work I do, the tradeoff actually pencils out.

Why I picked it anyway

The pitch is simple: Svelte gets out of your way, and Astro ships less of it.

Svelte is a compiler, not a runtime. You write something close to plain HTML with logic in it, and it compiles to small, direct DOM updates. Svelte 5's runes ($state, $derived, $effect) killed the thing I hated most in React — the bookkeeping. No dependency arrays, no useMemo gymnastics, no stale-closure traps. State is state. Derived values derive. I spend my attention on the feature, not on babysitting the render cycle.

Astro handles the rest: ship zero JS by default, hydrate only the interactive islands. My pages are fast without me trying. The default is the optimized path.

Put together: less boilerplate, smaller bundles, a mental model that stays close to the platform. For a small team — or a team of one — that compounds.

Where it genuinely costs you

Here's the part nobody puts in the headline.

The ecosystem is smaller, and you feel it. React has a pre-built answer for almost everything. Need a date picker, a data grid, a rich-text editor, a charting library with ten years of edge cases ironed out? It exists, it's maintained, and there are three competing versions. In Svelte you'll often find a solution rather than the solution — or you'll build it yourself. Sometimes that's a feature (you understand your own code). Often it's just a tax you pay in hours.
Everyone else knows React. This is the one that bites teams, not solo projects. If I want to hand off code, hire, or bring in a contractor for a week, the React talent pool is the entire industry. The Svelte pool is a puddle by comparison. If your bet is "scale the team fast," React is the rational hedge. I'm betting the other way, and I know it's a bet.
AI tooling is measurably worse at Svelte. (This is the 2026 one.) Every coding assistant was trained on far more React than Svelte. Ask for a React component and it's fluent. Ask for Svelte and you get more mistakes, plus a nasty habit of generating outdated Svelte 4 patterns when you're on 5. The AI productivity boost everyone's riding? You get a thinner slice of it by default. I've clawed most of it back — but only by writing a pile of project-specific rules to teach the AI my patterns. React devs get that for free.

So who should actually pick Svelte?

Not everyone. My honest decision rule:

Pick React if you're hiring soon, building something with heavy third-party widget needs, or you want the AI tooling to carry maximum weight out of the box.
Pick Svelte + Astro if you're a small team or solo, you value a codebase you fully understand over one full of dependencies, you care about shipping fast and light, and you're willing to invest a little to make your tooling fluent in it.

I fall squarely in the second bucket, which is why I'm here. But I'd be lying if I said the first bucket was wrong. Most teams probably belong in it.

The part that makes this credible

Svelte didn't win because it's objectively better. It won for me, for my constraints, after I'd looked the costs in the eye and decided I could live with them. The smaller ecosystem, the thinner hiring pool, the AI tax — those are real, and I pay them every week.

That's the honest tradeoff. Anyone who tells you a 2026 framework choice is free of tradeoffs is selling something — or hasn't shipped enough to get the bill yet.

The libraries I actually reach for — and the rule I use to decide

Dimon — Fri, 05 Jun 2026 16:17:11 +0000

My last two posts were about not installing things the browser already gives you — native elements over libraries. But that's only half a rule, and leaving it there would be dishonest, because I install plenty of libraries. The point was never "zero dependencies." It was "no redundant ones."

So here's the other half: the libraries I reach for without a second thought, and the simple rule I use to decide.

The rule

A library earns a place in my project when:

It solves something the platform genuinely doesn't — or doesn't do safely.
It stays focused: one job, not a framework trying to take over the app.
It's something I'd get wrong, or burn weeks on, if I built it myself. If the browser already ships it, I skip it (that was posts 1 and 2). If it fails one of those three, I skip it too. What's left is worth installing — grouped here by the kind of hard problem each one solves.

"Don't DIY this — you'll get it wrong"

sanitize-html — safe HTML. The moment you render HTML you didn't write — user comments, markdown, anything from an API — you're one mistake away from an XSS hole. Sanitizing HTML correctly is a security discipline, not a weekend regex. The platform ships no sanitizer, and "I'll just strip <script> tags" is exactly how people get breached. I never roll this myself.

zod — runtime validation. TypeScript is great, but it vanishes at runtime. The moment data crosses a boundary you don't control — an API response, a form submission, an LLM's output — TypeScript has already stopped helping. zod validates the actual value at the moment it arrives:

const User = z.object({ name: z.string(), age: z.number() });
const result = User.safeParse(await response.json());
if (!result.success) {
  // handle bad data here — instead of crashing three functions
}

TypeScript checks at compile time. zod checks at the time that actually matters.

"Deceptively hard math"

Floating UI — positioning. I mentioned this last post. The browser now gives you the behavior of a popover for free (top layer, light-dismiss, Esc). What it doesn't reliably give you yet is the placement — anchoring a panel to its trigger and flipping it when it would fall off a screen edge. CSS anchor positioning is landing for this, but support is still uneven, so for now I let Floating UI do the collision math. "Position a box near another box" sounds trivial until you handle every viewport edge, scroll container, and overflow. It isn't trivial. This is a rabbit hole worth paying someone else to have already fallen down.

"Solved and tedious — just use the good one"

marked — markdown to HTML. A markdown parser is a real project with a real spec. There's a fast, battle-tested one. I use it and move on — then hand its output straight to sanitize-html, because parsing and sanitizing are two different jobs and you need both:

import { marked } from 'marked';
import sanitizeHtml from 'sanitize-html';

const safe = sanitizeHtml(marked.parse(userMarkdown));

Lucide — icons. A consistent, maintained, open-source icon set beats hand-drawing SVGs or gluing together a mismatched pile from five different sources. Icons are a solved problem; consistency is the hard part, and that's exactly what a good icon set gives you.

Bonus — fast-average-color. The platonic example of a library worth installing: it does one tiny thing — pull the dominant color out of an image — in a few kilobytes. No framework, no lock-in, no ambition beyond its single job. That's the shape of a dependency I never regret.

The line

Here's what I want you to notice: the judgment is identical in both directions. The same instinct that installs Floating UI for positioning is the one that refuses a modal library because <dialog> already exists. One rule, applied both ways — install for the hard problem the platform doesn't own, skip for the thing it already ships.

The question was never "library or no library." It's "is this a hard problem the platform doesn't solve — safely, and on its own?" Answer that honestly each time, and your dependency list stays short and you stop reinventing wheels you'd only build worse.

That's the whole series in one line: use the platform for what it's good at, and pay for help only where it genuinely earns it.

8 native HTML elements you don't need a library for

Dimon — Thu, 04 Jun 2026 16:26:09 +0000

In my last post I wrote about staying close to the browser instead of fighting it. This is the concrete version: 8 native HTML elements that do what most projects install a library for.

I'm not anti-library. I'm anti-reinstalling-what-I-already-have. Here's the list.

1. `<dialog>` — instead of a modal library

The usual reach for an "are you sure?" prompt is a modal package. You don't need one. <dialog> does it natively: focus trapping, a styleable ::backdrop, Esc-to-close, and top-layer rendering.

<dialog id="confirm">
  <form method="dialog">
    <p>Delete this item?</p>
    <button value="cancel">Cancel</button>
    <button value="ok">Delete</button>
  </form>
</dialog>

<button onclick="confirm.showModal()">Delete</button>

method="dialog" closes it and tells you which button was pressed. No library, no z-index wars.

2. `<details>` + `<summary>` — instead of an accordion library

Open/close, keyboard support, all free. And the newer name attribute makes a group mutually exclusive — only one open at a time, which is exactly the "accordion" behavior you'd normally write JS for.

<details name="faq"><summary>What is native-first?</summary><p>…</p></details>
<details name="faq"><summary>Do I still need JS?</summary><p>…</p></details>

3. The Popover API — instead of a tooltip/dropdown-menu library

The popover attribute + popovertarget gives you a top-layer panel with light-dismiss, Esc-to-close, and proper stacking — with zero JavaScript. That's the part libraries used to own: open/close state, dismiss handling, z-index wars. Gone.

<button popovertarget="menu">Options</button>
<div id="menu" popover>
  <button>Rename</button>
  <button>Delete</button>
</div>

What it doesn't solve yet is precise positioning — anchoring the panel to its trigger and flipping it when it hits a screen edge. CSS anchor positioning is landing for that, but support is still uneven, so I reach for Floating UI to handle placement. That's the honest split: the browser gives me the behavior for free, and I bring a small, focused library for the positioning math.

4. `<select>` and `<datalist>` — instead of a dropdown / autocomplete library

<select> is an accessible dropdown that works with the keyboard, uses the native picker on mobile, and submits with the form. <datalist> adds autocomplete suggestions to a plain input.

<input list="frameworks" />
<datalist id="frameworks">
  <option value="Svelte"></option>
  <option value="Astro"></option>
</datalist>

Honest caveat: if you need a filterable, multi-select combobox, native isn't enough — that's one of the few places I still build custom.

5. `<input type="range">` — instead of a slider library

A slider, with keyboard support, that you can fully style (track and thumb) in CSS now.

<input type="range" min="0" max="100" value="50" step="5" />

6. `<input type="color">` — instead of a color-picker library

A whole color-picker package is overkill for basic "pick a color." This is one tag.

<input type="color" value="#7c5cff" />

7. `<input type="date">` — instead of a date-picker library

A native calendar that's mobile-friendly out of the box.

<input type="date" min="2026-01-01" max="2026-12-31" />

Honest caveat: styling the calendar is limited, and a date range needs two inputs. For heavy date UX you may still reach for help — but for "pick a date," the library was overkill.

8. `loading="lazy"` — instead of a lazy-loading library

This is my favorite, because it replaces an entire IntersectionObserver-based package with a single attribute.

<img src="big.jpg" loading="lazy" alt="…" />

One word. That's the whole feature.

Where I still reach for a library

Native-first doesn't mean zero dependencies — it means I don't install a library to do something the platform already does. I still reach for focused, do-one-hard-thing libraries: Floating UI for positioning (above), and a handful of others for the genuinely-hard things the platform doesn't solve well yet. Those earn their place — and they're a post of their own, coming next.

The pattern

Most developers already have all of these — the platform just doesn't get checked first, out of habit. Native-first isn't "never install anything." It's: open the platform's docs before you open npm. Half the time the thing you were about to install is one tag away.

So next time you need a modal, a menu, a slider, or a color picker — try the native element first. You'll ship less code, get accessibility mostly for free, and have fewer things to maintain later.

And it only gets better

Here's what makes native-first a long-term bet, not just a tidiness preference: the platform keeps getting more capable, and you inherit that for free. The old "you can't style native elements" complaints are falling one by one — CSS now lets you animate <details>, auto-size a <textarea> with field-sizing, anchor-position a popover, and the customizable <select> (with ::picker()) is finally landing so you can style the dropdown itself.

A native element you adopt today quietly gets better with each browser release. A library you install is frozen the day you npm install it — and from then on it's your job to maintain. Betting on the platform is betting on something that improves without you touching your code.

Why I stopped fighting the browser

Dimon — Tue, 02 Jun 2026 23:06:22 +0000

A while ago I was about to install another dropdown library. I'd already added one for modals and one for tooltips. Somewhere between npm install and opening the docs, I stopped and asked myself a dumb question: why am I doing this?

The browser already has a dropdown. It already has a modal. It already has an accordion. I was about to spend a weekend — and a few hundred kilobytes of JavaScript — rebuilding things my browser ships for free.

That was the moment I realized I'd been fighting the browser for years without noticing.

What "fighting the browser" looks like

Modern frontend has a reflex: reach for a library for everything. And to make those libraries look custom, you reset all the defaults, override the styles, and reimplement the behavior — keyboard navigation, focus trapping, ARIA roles, form integration.

The problem is that you get that behavior subtly wrong. I'm one developer. I am not going to out-engineer the people who built the browser's <select>. Every time I reimplemented one of these, I quietly reintroduced accessibility bugs the browser had already solved — and shipped more code to do it.

The shift: adapt, don't fight

So I gave myself one rule: the browser owns the behavior, I only own the looks.

Need a modal? <dialog>. It already does focus trapping, Esc-to-close, a backdrop, and it renders above everything in the top layer. I just style how it looks.
Need an FAQ or accordion? <details> + <summary>. Open/close and keyboard support, free.
Need a dropdown? <select>. Accessible, keyboard-friendly, uses the native picker on mobile, and submits with the form. I would never have built it that well.
Need a slider? <input type="range">.

The objection I had to get over

You're probably thinking what I thought: "but native elements are ugly and you can't style them."

That was true years ago. It mostly isn't now. Modern CSS lets you style form controls, a dialog's ::backdrop, accent colors, the open/close states — way more than most of us realize. In 2026, "you can't style native elements" is a habit, not a fact.

Native-first does not mean unstyled. I style mine heavily. It means the browser keeps the behavior, and I take the paint.

Where I still go custom

I'm not a purist about it. Some things genuinely have no native equivalent — a filterable combobox, a command palette (Cmd+K), a multi-handle slider. Those I build. But even then I wrap and extend the native pieces instead of starting from zero.

The point isn't "never write JavaScript." It's "don't rebuild what you already have."

Why this mattered so much for me

I built my whole design system solo. Native-first is the only reason that was even possible. Leaning on native elements means:

less JavaScript to ship and maintain,
accessibility I get mostly for free instead of bolting it on later and getting it wrong,
forms and mobile that just work.

My components got thinner. My bugs went down. And the few things I did build custom got the attention they deserved — because I wasn't burning it re-creating a dropdown.

This isn't a thought experiment for me. It's the foundation of a design system I've been building. It's not out yet, but native-first is the principle everything else sits on — and I'll be writing about the rest as I go.

If you take one thing from this: next time you reach for a dropdown library, open the docs for <select> first. Next time you need a modal, try <dialog>. You might delete more code than you write — and that's the good kind of progress.