DEV Community: pop3zxcv

Four things SVG and CSS did that I did not expect

pop3zxcv — Sat, 22 Aug 2026 12:46:28 +0000

I spent a while building an icon editor that runs entirely in the browser
(icons.jamuny.com, free, no account). Here is what cost me the most time.

A presentation attribute loses to any author CSS rule

I was scaling handle stroke widths by 1 / zoom and writing the result as an
attribute. The value was never used.

handle.setAttribute('stroke-width', String(0.35 / zoom));

.handle { stroke-width: 0.35 } in the stylesheet outranks it, because a
presentation attribute sits at the very bottom of the cascade.

Measured in Chromium: an attribute of 0.05 computed as 0.35px. Every handle
thickened on screen as you zoomed in, for months, with no error anywhere.

The fix is a custom property, which is an ordinary declaration and wins where an
attribute cannot:

layer.style.setProperty('--px', String(1 / zoom));
/* .handle { stroke-width: calc(0.35 * var(--px)) } */

Geometry attributes like r and width are unaffected. They have no CSS
counterpart here, so nothing was ever overriding them.

A focused SVG element gets a focus ring measured in user units

My canvas is 24 units wide and about 620 pixels. Chrome drew its default focus
ring at outline-width: 2.72727px in user units, which is about 24 screen pixels.

A fat blue disc appeared around every point you clicked. It was reported to me
four times, and four times I thinned something of my own that was not the cause.

getComputedStyle(document.activeElement).outline

That one line found it. My rule only covered :focus-visible, which is the
keyboard case, and the keyboard case is the one where I draw a ring of my own.

var() does work in a presentation attribute, and I wrote down that it doesn't

I needed a segment colour that changes with the theme, so the value is
oklch(var(--band-l) var(--band-c) 47). I applied it through a style and put a
comment beside it saying var() is not substituted in presentation attributes.

It is. Both forms compute to the same colour, including on an element built
detached and appended afterwards:

a.setAttribute('stroke', 'oklch(var(--band-l) var(--band-c) 47)');
b.style.stroke      =    'oklch(var(--band-l) var(--band-c) 47)';
// both: "oklch(0.52 0.09 47)"

Nothing broke, because both work. But the comment passed a full test suite and a
deploy, which is the point: a claim about the browser that nobody pointed a
browser at is worth exactly nothing.

Making an overlay translucent breaks contrast in a way tests cannot see

Each drawing command wears its own colour band over the icon. A request came in
to make those bands 74% opaque instead of solid.

A translucent colour takes on whatever is behind it, so one palette stopped
serving both themes. Over white it landed at 2.29:1 against that white, under
the 3:1 that WCAG 1.4.11 asks of a graphic.

I swept the lightness range and no single value clears the bar in both themes at
that opacity. So the lightness became a theme token: 0.52 on light, 0.74 on dark.

My contrast test stayed green through all of it, because it read the band's raw
stroke and a raw colour says nothing about opacity. It composites now:

const over = (colour, backdrop, alpha) =>
  colour.map((part, at) => alpha * part + (1 - alpha) * backdrop[at]);

I checked the fix by forcing each theme's lightness onto both and watching the
test go red. A test you have not seen fail is not known to protect anything.

One more thing about palettes

I had a tab of coolors.co open on "soft" palettes while doing this. Pulled the
hex values out of the top twelve and measured them.

Every one lands between 5.6:1 and 6.1:1 on a dark ground and between 1.03:1 and
1.08:1 on a white one. They are dark-ground palettes, not soft ones.

The editor is at icons.jamuny.com. No account, no upload, and the CSP says
connect-src 'none' so it could not upload anything if I wanted it to.

I built a Chrome extension that makes webpages easier to read Universal Web Accessibility Companion is now available on the Chrome Web Store.

pop3zxcv — Thu, 13 Aug 2026 13:13:41 +0000

Small text, tight spacing, distracting layouts and unfamiliar letter shapes can make ordinary webpages tiring to read.

Universal Web Accessibility Companion is made for people who have trouble reading standard webpage layouts. It is now available on the Chrome Web Store.

The extension can enlarge text, change letter shapes and spacing, focus attention on one line at a time, add a reading ruler or read the page aloud. Settings can be saved for individual websites, and the original page can be restored with one click.

The CSS controls were fairly straightforward. Compatibility took most of the time.

A blanket font or spacing rule can easily damage forms, code editors, menus, and web applications. Much of the development work went into identifying those areas, leaving them alone, and restoring the original page cleanly when the extension is turned off.

Privacy was another firm requirement. Page content is handled inside the browser. There is no UWAC server, tracking system, advertising network, or account.

There are honest limits. It is not a screen reader, Chrome prevents extensions from changing some protected pages, and no extension can repair every accessibility problem on every website.

If you want to try it:
https://chromewebstore.google.com/detail/mofpdgjakcjgjdnbmgaikmhpdnaeaikj

I’d be interested in hearing about websites where it behaves well, as well as the ones that expose something I missed.

A whiteboard that can't upload your drawing, because the browser won't let it

pop3zxcv — Sun, 09 Aug 2026 17:07:56 +0000

I wanted to sketch a database schema last month and the first three whiteboards I opened asked me to sign in. So I wrote my own. While I was at it I decided the no-upload thing shouldn't be a line in a privacy policy, because you can't check a privacy policy.

It's at board.jamuny.com. Below is what I hit building it.

One CSP directive does most of the work

The page ships with this header:

Content-Security-Policy: default-src 'self'; script-src 'self';
  img-src 'self' blob: data:; font-src 'self'; connect-src 'none';
  object-src 'none'; form-action 'none'; frame-ancestors 'none'

connect-src 'none' blocks fetch, XMLHttpRequest, WebSocket, EventSource and sendBeacon at the browser level. If I got sloppy in six months and pasted in an analytics snippet, it wouldn't quietly start working. The browser would refuse the connection and log a policy violation.

You can check this yourself in about thirty seconds: open devtools, draw a few shapes, watch the network panel stay empty.

There's a Playwright test that fails if it ever stops being true:

test('draws, switches boards and reloads without a single request', async ({ page }) => {
  const requests: string[] = [];
  page.on('request', (r) => requests.push(r.url()));
  page.on('websocket', (ws) => requests.push(ws.url()));
  // draw, switch boards, reload, export PNG and SVG
  expect(requests.filter(isNotOwnAsset)).toEqual([]);
});

One thing worth knowing if you write a test like this: page.on('request') doesn't fire for WebSocket handshakes. I had the request listener alone for a while, and an actual WebSocket connection would have gone straight past it. You need page.on('websocket') too.

The obvious cost is that there's no collaboration and there won't be. Multiplayer needs a server, a server means the strokes leave your machine, and then I've built the thing I was trying to avoid.

No framework, for fairly boring reasons

Astro emitting static HTML, plus a couple of <script type="module"> islands. No React, no Svelte.

This isn't asceticism about bundle size. A framework's job is reconciling a component tree against the DOM, and the DOM here is one <canvas> element that never changes. I'd be paying for hydration to manage a toolbar. Script weight sits around 23KB transferred, with a Lighthouse assertion that fails the build if it creeps up.

There are two canvases stacked, actually. One holds the committed scene, the other holds whatever stroke you're currently drawing. Repaint the whole board on every pointermove and it gets sluggish once there are a few hundred elements on it, so the overlay keeps an in-progress stroke down to one shape's worth of drawing.

roughjs draws a rectangle as four separate lines

The board gives you Clean or Sketch per shape. Sketch runs through roughjs for the hand-drawn wobble, and Clean originally did too, with roughness dialled to zero.

Then I got a bug report saying the rectangles looked like "a line connecting four edges."

I dumped the ops roughjs was producing for a rectangle:

["move", "bcurveTo", "move", "bcurveTo", "move", "bcurveTo", "move", "bcurveTo"]

Four independent subpaths, one per edge. That's correct for a sketchy look, since each edge is meant to read as its own pencil stroke. The consequence is that there's no line join anywhere, because as far as the canvas API is concerned there's no corner, just four lines that happen to end near each other. At stroke width 2 nobody notices. At width 8 there's a chunk missing from every corner.

Clean mode draws with plain canvas calls now (ctx.rect(), ctx.ellipse(), moveTo/lineTo), one beginPath/stroke per shape so lineJoin applies. Sketch still uses roughjs, where none of this was ever a problem.

There's a related one I only caught by opening an exported PNG. I was stroking an arrow's shaft and its head as a single path, so ctx.setLineDash() applied to both. A dashed arrow came out with the head chopped into two or three dash fragments, and a dotted one barely had a head at all. On screen at normal zoom it reads as a slightly scruffy arrowhead, which is why I'd been looking at it for days without registering it. At 2x in an export it's obvious.

Fixing it meant touching three places that all have to agree: the canvas renderer, the SVG exporter and the roughjs path. The roughjs one was the annoying bit. A Drawable's options (including strokeLineDash) are shared across every opset inside it, so a dashed shaft and a solid head can't be one Drawable however you build the path string. It has to return two.

The style panel spent two revisions in the wrong place

It started in the top toolbar. That row ended up carrying the tools plus seven stroke colours, five fills, four widths, Clean/Sketch, and Solid/Dashed/Dotted. Around twenty controls, which clipped off the right edge on a normal laptop window. You'd get Clean | Sketch | Solid | D… and everything past that was gone.

So I floated the panel over the canvas's top-left corner. That corner then stopped accepting pointer events, so you couldn't draw there. Nobody files a bug about this. They just feel like the app is slightly broken and don't come back.

What shipped is a docked rail: a real flex column next to the canvas, with the canvas at flex: 1; min-width: 0. Every canvas pixel is drawable because of how the layout is built, rather than because someone remembered to leave a gap.

That created a layout shift problem, since the rail's width depends on what's selected. The fix was to stop doing it in JavaScript:

.rail:has(> #style-panel:not([hidden])),
.rail:has(> #app-menu:not([hidden])) { width: 213px; }

The script only toggles the hidden attribute it was already toggling. The static markup ships in the same expanded state the script lands on a moment later, so there's no frame where the canvas box jumps. CLS measures 0.0000.

One more that took me a while to see. Clicking an unselected shape starts a drag and populates the selection in the same pointerdown. The next frame widens the rail, which shifts the canvas out from under a drag whose anchor was captured against the old edge, so the shape jumps sideways by the width of the rail while your finger hasn't moved. The rail is frozen for the duration of any live gesture now.

I'd been using the wrong contrast standard

The stroke palette started life as the syntax colours from another tool of mine, which are held to WCAG's 4.5:1 because they're text. Carried over to drawing strokes, that made everything dark and slightly muddy. The feedback I got was that the colours all looked pale, which was fair.

4.5:1 is the figure for text. WCAG 1.4.11 asks 3:1 of non-text content, which is what a drawing stroke is. Moving to the correct bar is what made a bright palette possible at all, and I measured every value rather than relaxing the test until it passed.

Two things went wrong doing it. First, white isn't the only background a stroke sits on, since you can draw on top of a filled shape. My new lime cleared 3:1 against the canvas and came in at 2.67 against the blue fill tint.

The second cost me a deploy. My selection colour was resolved like this:

STROKE_COLORS.find((s) => s.id === 'blue')!.value

The palette rewrite renamed blue to sky. find returned undefined, the ! kept TypeScript quiet, and .value threw a TypeError at module load, so the whole island stopped booting. All 737 unit tests stayed green, because nothing imports that constant. What caught it was a Lighthouse assertion on errors-in-console, which is the only gate I have that loads the real page in a real browser.

Where it is now

Pen, rectangle, ellipse, line, arrow and text. Select, move, resize, delete. Clean or Sketch per element, solid or dashed or dotted. Boards as tabs, stored in IndexedDB. Undo and redo per board. Infinite canvas with pan and zoom. PNG and SVG export.

There's no account system, no sync, and no image tool yet.

If you'd rather verify than believe me: devtools, draw something, watch the network panel.

board.jamuny.com

Built on perfect-freehand (MIT), roughjs (MIT) and idb (ISC).

I got tired of reverse-engineering design systems by hand, so I built a Chrome extension

pop3zxcv — Sat, 08 Aug 2026 11:24:05 +0000

I spend a lot of time looking at how websites are put together. My usual process was slow: open DevTools, inspect a few elements, copy colors, check font sizes, look through media queries and write everything down somewhere.

That process eventually became a Chrome extension.

Design System Extractor reads the visual system of the page in your active tab and packages the results into a ZIP. Version 1.4.0 has now been published on the Chrome Web Store.

The basic workflow

Open a page you are allowed to inspect, launch the extension and click Capture.

The extension checks the page's DOM and styles for colors, typography, spacing, border radii, shadows, breakpoints, motion, contrast pairs and interaction states. It also looks for familiar components such as buttons, inputs, cards and badges.

Before downloading, you can review the detected items and remove anything you do not want.

The ZIP can contain JSON tokens, CSS custom properties, a Tailwind theme, Style Dictionary files and an inventory of the components found on the page.

Screenshot capture was harder than expected

Capturing a webpage sounds simple until the page has sticky headers, lazy-loaded sections, nested scrolling areas or an endless feed.

I decided against generating one huge full-page screenshot. The extension finds useful sections, scrolls them into view and creates separate crops instead. Each crop can be checked before it enters the export.

This also keeps endless pages under control. Capture has a hard stopping point rather than continuing to scroll through an infinite feed.

What happens to the page data

Processing stays inside the extension on your computer.

There is no backend and no analytics service. I do not receive the page URL, extracted styles, screenshots or usage information. Temporary viewport images are kept in memory only while the component crops are being made.

The extension also avoids form values, passwords, cookies, authentication tokens and browser storage.

Try version 1.4.0

The extension is available here:

https://chromewebstore.google.com/detail/gohgeagmchgejaecbdjnngcjjcgimlkm

This is the first public release. I am particularly interested in pages where the capture misses a section, chooses a poor crop or extracts a token incorrectly. Those examples will help me decide what to fix next.

Why Your AI Agent Costs 6x More Than You Calculated

pop3zxcv — Mon, 03 Aug 2026 18:27:06 +0000

Pricing an LLM call is simple arithmetic. Input tokens times the input rate, plus output tokens times the output rate. Every pricing page shows you this, every calculator computes it, and for a chatbot it is correct.

For an agent it is wrong by a factor of six, and the factor gets worse the longer the agent runs.

The reason is not hidden or subtle. It follows from one property of language models that everybody knows and almost nobody puts into their cost estimate.

Models have no memory

A language model does not remember your last request. Each call is independent. If you want the model to know what happened three steps ago, you send it again.

So an agent loop does this:

step 1  send: system prompt + task
        get:  a tool call

step 2  send: system prompt + task + step 1 output + tool result
        get:  another tool call

step 3  send: system prompt + task + step 1 + step 2 + both tool results
        get:  another tool call

Take a concrete shape. A 2,000-token system prompt with tool schemas, a 500-token task, 400 tokens of model output per step, and 1,200 tokens of tool results per step. Here is what each step actually sends:

Step	Context sent
1	2,500 tokens
2	4,100 tokens
3	5,700 tokens

Each step costs more than the one before it, forever. Step 3 is more than twice the price of step 1 and it is doing the same amount of new work.

The formula

Across N steps, every step pays for the system prompt and the task. That part is linear:

N × (system + user)

The accumulated history is the part that hurts. Step i carries the output and tool results of all i − 1 steps before it. Summing that over the whole run gives the triangular number:

(output + tool_result) × N × (N − 1) / 2

Put together:

total input tokens = N × (system + user) + (output + tool_result) × N × (N−1) / 2

The second term is quadratic. Double the step count and that part roughly quadruples.

What that does at different step counts

Same workload shape as above, no retries, no caching:

Steps	Raw conversation	Billed input	Multiplier
3	7,300	12,300	1.7×
5	10,500	28,500	2.7×
10	18,500	97,000	5.2×
12	21,700	135,600	6.2×
20	34,500	354,000	10.3×
30	50,500	771,000	15.3×
50	82,500	2,085,000	25.3×
100	162,500	8,170,000	50.3×

"Raw conversation" is the number you get if you add up everything the agent said and everything it read. It is the number your intuition reaches for. "Billed input" is what appears on the invoice.

At 3 steps the gap is small enough to ignore. At 12 steps you are paying 6.2 times your estimate. At 50 steps, 25 times. A deep research agent that runs a hundred steps bills fifty times the tokens the conversation contains.

Nothing is broken when this happens. It is what the pricing model does when you loop it.

Retries make it worse

A failed tool call, malformed JSON, a guardrail rejection: whatever the cause, a retry re-sends the context too, at whatever depth the failure happened.

At a 10% retry rate the 12-step example moves from 6.2× to 6.9×. Not dramatic on its own, but it stacks on top of a number that is already six times your estimate, and retry rates in production are rarely zero.

Three things that move the bill

Take the 12-step agent at a 10% retry rate on Claude Sonnet 5. Baseline is $0.351 per run. At 1,000 runs a day that is $10,534 a month.

Prompt caching. Most of what you are paying for is context re-sent verbatim, and cache reads cost roughly 90% less than fresh input. A 90% hit rate takes the run to $0.109. That is 69% off, with the same model and the same agent.

Step count. Halving the loop from 12 steps to 6 takes it to $0.112, or 68% off. Almost identical to what caching bought you, which is worth sitting with for a second: removing half the reasoning steps and caching everything are about equally valuable.

Tool result size. Trimming tool results from 1,200 tokens to 400 takes it to $0.235, or 33% off. Smaller than the other two but easier than either. Every tool result is re-sent by every step that follows it, so truncating a verbose search result compounds down the whole run.

The counterintuitive one

The instinct when a bill is too high is to switch to a cheaper model. Compare that against cutting steps, on a 20-step agent:

Change	Cost per run	Saving
Baseline: Sonnet 5, 20 steps	$0.867
Swap to Haiku 4.5, still 20 steps	$0.433	50%
Stay on Sonnet 5, cut to 10 steps	$0.257	70%

Ten steps on the frontier model is cheaper than twenty steps on the small one, and you keep the better model.

This is not a quirk of these two models. Price is linear: a model at half the rate costs half as much, and that is the ceiling on what switching can buy you. Step count is superlinear, so halving it saves more than half. The gap widens as the agent gets longer.

Which means the first question about an expensive agent is not "what cheaper model could do this", it is "why does this take twenty steps".

Why most calculators miss it, and who does not

Nearly every LLM pricing calculator prices one request. Input times rate, plus output times rate. That is the right model for a chat completion and it is what the pricing pages describe, so it is a reasonable thing to build.

Two tools go further and deserve naming.

Kenodo's agent calculator models the same cumulative context this post describes, and says so directly: input tokens for step N include the system prompt plus every prior output and tool response. It covers eight models with a cache-hit slider. If you want a second opinion on your numbers, run them there too.

Softcery's voice agent calculator applies a flat 1.8x "reality factor" and notes in a footnote that conversation history "compounds O(n²) with turns". For voice at roughly four turns a minute with short turns, a constant is a fair approximation, and theirs also absorbs function-calling round trips and barge-in handling.

Tool-using agents sit elsewhere on the curve. Turns are fewer but each drags a large tool result behind it, so the quadratic term takes over earlier. A constant fitted to a voice call will not fit a research loop, which is the argument for computing the curve rather than picking a number.

The gaps I still wanted filled: a retry rate, since failures resend context too and nobody runs at a 0% failure rate. Per-step accumulation, so you can see where the curve bends instead of only the total. And a source URL with a verification date behind every rate, because provider pricing moves constantly and a calculator with stale numbers is worse than none.

What this arithmetic does not tell you

Worth being clear about the edges.

Retries here are a flat multiplier on the total. Real retries happen at a specific depth, so a failure at step 18 costs far more than one at step 2, and a flat rate under-counts late failures.

Cache hit rate is one number. In reality your system prompt might cache at 99% while your tool results never cache at all.

Providers tokenize differently, so comparing token counts across vendors is approximate. And cache writes are not free everywhere: OpenAI's GPT-5.6 charges 1.25× uncached input to write to cache, which the numbers above do not include.

None of this changes the shape of the curve. It does mean you should treat any figure here as a planning estimate rather than a billing forecast.

Run it on your own numbers

I built a calculator that models the loop instead of a single request: step count, tool result size, retry rate, cache hit rate, across 17 models, with the per-step accumulation and cost attribution broken out. Free, no signup, runs entirely in the browser.

costperrun.com

The pricing data is on GitHub with a source URL and verification date against every rate. If you find a stale price, open an issue.

The number worth checking first is your step count. It is almost always higher than you think, and it is the term that squares.