Posts Subscribe to Posts RSS feed

Ever opened someone else’s repository after a while and found a bunch of unfamiliar files sitting there? Next to README.md there’s a CLAUDE.md, an AGENTS.md shows up too, and some repos even have a DESIGN.md. They’re all .md files, but what are they actually for? They’re all documents written to be read by AI — not by people. Just a few years ago, the only markdown files in a repository were the README and maybe a license. But now that AI coding tools have become part of everyday work, projects need to tell AI, too, “here’s how we do things around here.” Instead of repeating the same explanation in chat every time, teams started writing it down in files. That’s how we ended up with the files you’re looking at now. ...

Have you ever asked an AI to “put this in a table” and gotten back text littered with pipes (|) and dashes (-)? It looked like a clean table right there in the chat window — but the moment you copied it into a messaging app, it turned into a mess of symbols. Those symbols are Markdown. These days you run into it everywhere — GitHub READMEs, technical blogs, note-taking apps like Notion, even the replies an AI chatbot sends you. ...

Opening: treating scroll as “time” When you build scroll-based animations, you eventually hit this thought: “What if scroll were not just an input event” “but a proper timeline?” Scroll-Driven Animation is that idea made explicit. Instead of treating scroll as a trigger, you treat it as the timeline itself. In this post, I group implementation strategies into three families: Native CSS Scroll-Driven Animation IntersectionObserver for state changes scroll + requestAnimationFrame with manual progress mapping For each one, we will cover the principle, strengths, tradeoffs, and accessibility concerns. The code samples here are minimal and correct by themselves, and each section ends with a link to a live demo you can poke at directly. ...

This is Part 22 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary What do you end up with when you stack tests onto one small app, one layer at a time? This article is the retrospective on that journey — and a map of frontend testing as a whole. The layers we stacked were these: unit tests that check whether a single function does its one job, component tests that poke at the screen the way a user would, real-browser E2E that sweeps end to end, accessibility checks that protect users who never look at the screen, and CI that runs all of it for you on every PR. By the end, we’d even gotten to verifying code and tests written by AI. ...

This is Part 21 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary AI-written code is fast, it runs, and the screen looks good. The problem is that it’s wrong in plausible ways. Two spots go empty especially often. One is accessibility — the things people who use the web without looking at a screen need. The other is what happens in moments that rarely come up — an empty search box submitted, a server returning a 500. We call these edge cases. Both fall into “nobody covers it unless you ask” territory. ...

AI now drives the browser itself. A practical map of Playwright codegen and MCP agents: why Playwright MCP reads the accessibility tree rather than screenshots, and why self-healing selectors aren't a Playwright feature.

This is Part 19 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Can you just ask AI (large language models like ChatGPT and Claude) to write your tests? Yes. Just don’t trust them as-is. AI produces plausible tests in seconds, but tends to quietly skip the boundary, failure, and accessibility cases that matter most. This article is about employing AI properly as a test-writing assistant — from getting good drafts to the checklist that proves the tests actually work. ...

A green support table doesn't mean everyone can use it. Here's a 2026 accessibility check on popover, anchor positioning, dialog, and view transitions — and what you still have to do yourself for each.

This is Part 18 of the “Frontend Testing, Done Right” series. Browse the full series · Glossary Open a coverage report and four numbers stare back — Stmts, Branch, Funcs, Lines. Which one matters? This article is about reading that report: which number is honest (spoiler: branch), what to fill in from the red lines, and where to look for the team health that numbers can’t show. If you’ve been following the series, this is the hands-on follow-up to the strategy part’s point that “coverage is a reference, not a target.” First time here from a search? That’s fine too — we use Vitest, but reading a report works the same no matter which tool you’re on. ...

Where WCAG 3 (3.0) stands in the March 2026 W3C Working Draft: the 12-category, 44-guideline structure, requirement counts, and the return of Bronze/Silver/Gold.