How the first six Etch components were made

I’m Tom Chmiel, a web developer from Poland, and I designed, built and tested these six components. You copy one, paste it into the Etch builder and click Save. You can use it on personal, client and commercial sites.

AI agents write much of the code. They work from my specs and rules, and the decisions are mine: what a component should do and when it’s good enough to ship. Those decisions took many hours of my own work.

The first six

Each component is a single JSON file. Its HTML, CSS and JavaScript travel inside it, so there’s no plugin, CDN or build step.

Each component’s page has the current version, a demo and the changelog.

1. A written spec comes first

The spec is finished before any code exists, and it answers the questions that usually get skipped:

• What HTML does it render, and which elements carry the meaning?
• Which props and slots does it have, with which defaults?
• What does it show in the Etch builder, and what only on the live site?
• What happens with empty, very long or unexpected values?
• How does it behave with a keyboard, a screen reader and reduced motion?
• What happens when there are two of them on one page?

Above the specs sit three repository-wide standards: one for components, one for accessibility and one for styling with Automatic.css. They apply to every component, so the six behave alike. They’re my rules, written down so the AI agents follow them too.

2. How I work with AI agents

I build the components with AI coding agents, using the strongest models available to me:

• Claude Opus 5.5 (Anthropic), in Claude Code, does most of the building and fixing.
• Claude Fable 5.1 (Anthropic), in Claude Code, runs many of the release checks: an independent audit before a version goes public.
• GPT-6 Astra (OpenAI), in Codex, built and verified much of the early work.

An AI model left to itself will guess how Etch works, and Etch changes faster than models are trained. So the agents work inside fixed rules:

• The official Etch documentation and the published Etch API types override whatever the model remembers. Before an agent claims how Etch behaves, it has to look it up or test it.
• Written procedures (skills) cover five jobs: creating a component, auditing it, packaging it, and researching the Etch and Automatic.css docs.
• Agents work on test sites with WordPress 7.1.3, Automatic.css 4.0.1 and Etch 1.7.0 or 1.7.1. They write nothing to a live site without my explicit OK.
• Test reports name the model and the tools that ran them.

Most of these rules come from my experience with client sites: what breaks after an update, and what an editor expects to see in the builder. I also check each component in the builder myself and read the agents’ reports before I decide what to fix and when a version ships.

A lot of that time goes into saying “not yet”. One example: an agent once proposed a static placeholder in the builder “by design”. I said no. Every prop edit has to show in the canvas, and that’s now a rule for every component.

3. Etch generates the file you download

Components are assembled in the Etch builder through the official Etch Connector and the Etch Public API. When a version is done, Etch itself exports it. The JSON you copy from this site is exactly what Etch produced, byte for byte.

Nobody edits that file by hand, human or AI. Etch’s copy format is internal and undocumented, so anything written by hand would be a guess. Each export gets a SHA-256 checksum. It is then pasted back, saved, reloaded and read back before it’s marked verified.

Every prop edit shows in the builder

Change a prop in the Etch panel and the canvas updates at once, without saving. Getting there took work, because of how Etch handles props in the canvas:

• Etch updates a changed prop in place, on the element it already rendered. There’s no “prop changed” event to listen to.
• A freshly inserted, pasted or duplicated instance first renders with empty attributes and gets its values about 10 ms later.
• Replacing text that Etch rendered from a prop breaks every later edit of that prop.

So each component watches its own attributes and rebuilds only itself. The Before / After slider runs the real comparison in the canvas. Comments shows a sample discussion, so you can style it before a post has any comments.

4. Browser tests and a clean import

Testing happens in layers, and no layer replaces another:

1. Unit tests cover logic that doesn’t need a browser, such as number parsing or line ranges.
2. Nearly 400 browser test cases across the six components run with Playwright in Chromium, Firefox and WebKit, and for releases also in Chrome and Edge. They use actual keyboard input, focus, scrolling and layout, and emulate reduced motion, dark mode and forced colors.
3. Safari 27 itself runs on a Mac, driven through safaridriver, because Playwright’s WebKit isn’t the Safari your visitors use.
4. Chrome runs in an Android emulator and Mobile Safari in the iOS Simulator on an iPhone and an iPad, all driven by touch.
5. A saved QA page on the test site shows every variation side by side, for example 39 before/after cases or 27 counters. It’s checked in the desktop browsers above, with automated accessibility scans (axe).
6. Another test site keeps Automatic.css on its default settings, like a fresh install. Checks there include focus contrast, measured with real keyboard focus. That’s where the faint focus rings described under Accessibility showed up.
7. Last comes a clean import of the exact JSON you’ll download.

The clean import matters most. Etch matches a pasted component by its key and its styles by their selectors. If the site already has them, Etch silently keeps the old ones. A paste onto the site where a component was built always looks perfect, even when the file is missing CSS.

So before a release, the component’s key and selectors are freed on the test site, and the downloadable file is pasted fresh. After saving and reloading, the definition and every style must equal the source. Your site is in the same position the first time you paste a component.

When Etch ships a new version

Etch 1.7.1 came out on October 19, 2026, and all six components were checked on it the same day, in the builder and on the frontend. None of them needed a change for the new version. The build tools did: 1.7.1 changed how one Public API call links styles, and without a fix the tools would have saved components without their CSS. They now check every style link before they save.

The same day, the test site with default Automatic.css settings turned up three Back to Top bugs that have nothing to do with 1.7.1. Version 1.0.0-beta.5 fixes them.

Several instances, no global CSS

• Several instances on one page don’t share state, listeners or IDs. Comments is the exception: WordPress’s own comment form uses fixed IDs, so it’s one per post.
• Styles are scoped to the component, and its attributes are prefixed (data-ed-…). I learned why the hard way: Automatic.css styles any SVG inside an element with a data-icon attribute.
• Colors, spacing and type come from Automatic.css tokens when ACSS is installed, with fallbacks when it isn’t.

5. Accessibility is a release requirement

A component has to work with a keyboard and a screen reader before it ships. Every control needs visible focus, and focus moves only when it helps. Back to Top, for example, moves focus to the start of the page after the return.

With reduced motion, the counter shows its final value and Back to Top returns instantly. In forced colors mode (Windows high contrast), controls and states stay visible. Layouts are checked down to 320 px wide.

Automated scans can’t tell you what a screen reader says, so the agents also run NVDA on Windows, VoiceOver on a Mac and TalkBack in the Android emulator. The agent sends real key presses or touch gestures and records the speech, and the transcripts are saved with each report. The iOS Simulator has no VoiceOver, so on the iPhone and iPad the agents check the accessibility tree and touch instead.

NVDA, for example, doesn’t read a code area’s description, such as “Highlighted lines: 2–4”, when you Tab onto it. The agent tested other ways of attaching the description, and NVDA skipped all of them. It does read the description in browse mode, right after the code, so Code Block kept its markup.

The phone checks found defects too, and the current betas fix most of them. Two examples: a date link in Comments, right below a linked author name, was a smaller touch target than the 24 px WCAG 2.2 asks for, and Back to Top’s Auto-hide pulled the button out from under TalkBack’s focus.

One problem is still open. On a site that keeps Automatic.css’s default colors, the focus ring in Code Block, Comments and Audio Player measures 1.98:1 to 2.91:1 on their light surfaces, below the 3:1 that WCAG asks for. The ring is visible, but faint. Audio Player’s slider fill and thumb fall short the same way in its Inherit and Light themes. This problem and the untested areas below are why all six are still betas.

6. A release check before every public version

Before a version goes public, a separate agent session audits it. It looks for defects and leaves the design alone. It’s often a different model from the one that built the component: Fable 5.1 led the Animated Counter check, and an Opus 5.5 sub-agent reviewed the code independently, read-only. Each finding gets a severity: blocker, high, medium or low. A confirmed bug goes into the component’s bug register with the steps to reproduce it and stays open until a release fixes it.

Two problems these checks found before this launch:

• Comments had two release blockers. In the builder, WordPress’s native comments showed up as a striped placeholder, so prop edits changed nothing visible. And on Automatic.css sites, the Dark theme made quotes invisible: ACSS gives blockquote a light background but no text color, which left a contrast of about 1.1:1. Both were fixed the same day, with a sample discussion in the builder and the component’s own quote colors.
• Animated Counter played where nobody could see it. A counter that only touched the edge of the viewport, or sat in a collapsed panel, ran its animation anyway. Since 1.0.0-beta.2 it waits until it can be seen.

Every finding is reproduced before anything changes. One counter finding described a real bug but named the wrong cause. A new instance replayed in the builder because Etch fills in its attributes a moment after inserting it, and the script took that for an edit. The fix targets that cause.

What “beta” means here

All six are public betas. Some checks haven’t been run yet, and some bugs are still open:

• Physical phones. The phone checks so far ran in the Android emulator and the iOS Simulator, so VoiceOver on a real iPhone is still open.
• NVDA for four of the six (see the table above).
• Other Etch and Automatic.css versions. All six are tested with Automatic.css 4.0.1 on Etch 1.7.0 and 1.7.1, except Back to Top 1.0.0-beta.5, which came out after the update and was tested on 1.7.1 only. Earlier versions of four of them also ran on Etch 1.6.8, but the current betas weren’t tested there. Animated Counter needs Etch 1.7.0 or newer.
• Open bugs. The faint focus rings are the most serious. A few smaller ones are open too, such as Audio Player marking its title and artist as English on pages that aren’t in English or Polish.

Props and behavior can still change before 1.0. When they do, the changelog says what changed and how to upgrade.

Installing and updating

Save right after you paste

Etch adds any pasted component to your component list at once, but stores its CSS only when you save the page. If you reload or leave without saving, the component stays in the list without its styles, and pasting it again won’t repair it. Delete it from your components, paste it again and click Save.

Updating means a reinstall

Pasting a newer version over an installed component doesn’t update it, and there’s no update button for pasted components. Etch sees that the key and selectors are taken and keeps the old definition and styles. So today an update is a reinstall:

1. Note the settings of each instance, and copy any CSS you changed in the component’s own styles.
2. Delete the component from your components. Its instances disappear from every page that used it.
3. Delete its styles in the Style Manager.
4. Paste the new version and click Save.
5. Put the instances back, re-enter their settings and save. Reload any other open builder tab.

Each component’s page lists the exact styles to delete and what changed since the previous version, under How to update (Back to Top’s, for example). Overrides that set the component’s CSS variables on a parent class survive an update. Edits inside the component’s own styles don’t.

Free to use, not for resale

You can use and modify any component on personal, client and commercial websites, including paid client work. You can’t sell it as a component or put it in a competing commercial product, such as a component library, bundle or marketplace listing.

The license is FSL-1.1-MIT, the Functional Source License. It’s source-available, not open source in the OSI sense. Each version also becomes MIT two years after its release. Bundled libraries keep their own permissive licenses (MIT, BSD-3-Clause), and their notices travel inside the JSON. Read the license.