Who's the best AI frontend developer?

# Three.js Scroll Journey

Build a scroll-driven 3D narrative page using Three.js — the kind of piece that wins Awwwards Site of the Day, not a tutorial demo.

The page tells a story in **four distinct scenes** as the user scrolls through roughly 5–6 viewport heights. The 3D scene is persistent and continuous: one WebGL canvas that transforms as the user scrolls. Do not cut between separate scenes — morph, travel, or transition between them so the whole page feels like one continuous camera move.

## Requirements

- **Scroll is the only timeline.** Camera position, camera target, object state, materials, and lighting are all driven by a normalised scroll progress value. Scrolling back up must run everything perfectly in reverse — no one-way triggers, no state that cannot be undone.
- **Smoothed, not snapped.** Interpolate scroll progress with damping/lerp so motion feels weighted, and make it frame-rate independent using delta time rather than assuming 60fps.
- **Real 3D substance.** At minimum: custom geometry (procedural or mathematically generated — not just primitives sitting in a row), at least one custom `ShaderMaterial` with your own GLSL, meaningful lighting, and depth. Post-processing is welcome if you can do it without breaking the single-file rule.
- **Typography over 3D.** HTML text overlays that enter, hold, and exit in sync with the scroll timeline. The type should be as considered as the 3D — this is a designed page, not a canvas with captions.
- **Correctness.** Handle resize and device pixel ratio properly. Clamp DPR so it does not melt a retina display. Dispose or reuse geometries and materials rather than allocating per frame.
- **Performance.** Must hold a smooth frame rate at 1440×900. Budget your draw calls.
- **A landing state.** The first viewport should read as a deliberate opening frame — it is the first thing the judge sees before scrolling.

## What is being evaluated

Whether the scroll choreography feels authored rather than mechanical, whether the GLSL is real, and whether the page holds together as a single designed artefact. A technically correct page with no point of view scores poorly. So does a beautiful still frame whose scroll behaviour is a linear camera dolly.

You choose the subject and the story. Make it something you would be proud to sign.

# Custom WebGL Shader — Open

Write the coolest WebGL fragment shader you can think of, and give it a page worthy of it.

There is no prescribed subject, technique, or style. Raymarched SDF scene, fluid or reaction-diffusion simulation, volumetric clouds, caustics, a particle system driven by curl noise, path-traced glass, a generative landscape, something nobody has a name for — your call. Pick the thing you actually find beautiful and go as far as you can.

## Constraints

- The visual must be produced **by the shader**. The GPU does the work. Do not fake it with CSS, SVG filters, canvas 2D, or a video.
- Write the GLSL yourself. No copy of a well-known ShaderToy piece passed off as new.
- It must be **alive**: animated over time, and responsive to the pointer in a way that is meaningfully part of the piece rather than a bolted-on mouse-follow.
- It must hold a smooth frame rate at 1440×900 on integrated graphics. If your technique is expensive, adapt — resolution scaling, reduced step counts, early exits — rather than shipping something that stutters.
- Handle resize and device pixel ratio correctly, and clamp DPR.
- Fail gracefully: if WebGL is unavailable, show something considered rather than a blank page or an exception.
- Raw WebGL or a thin CDN wrapper (three.js, ogl, twgl, regl) are all fine. The shader is the point, not the plumbing.

## Presentation

Give it a frame. A title treatment, or a caption, or nothing at all if nothing is the right answer — but decide deliberately. If you expose controls, make them part of the design rather than a debug panel bolted to the corner.

## What is being evaluated

Ambition and beauty first; correctness of the technique second. A simple idea executed with total control beats an ambitious idea that renders as noise. Judges will read your GLSL, so the maths should hold up — and they have seen the standard raymarched-sphere-on-a-checkerboard a thousand times.

Surprise us.

# Brand Landing Page

Invent a company and design its landing page.

**The brand:** *Halcyon* — a company that manufactures precision sleep instruments. Not an app, not a mattress: physical objects, engineered and expensive, for people who treat rest as a discipline. Their first product is a bedside device that shapes the light and sound of a room across the night. Price point is deliberately high. Their competition is Aesop and Teenage Engineering, not Casper.

Everything else — the exact product name, the voice, the palette, the type system, the story — is yours to invent. Invent the copy too; do not leave lorem ipsum or bracketed placeholders anywhere.

## Requirements

- A complete page: navigation, hero, and enough sections below the fold to establish the product, the craft behind it, and a reason to care. End with a real footer. Roughly 5–8 sections.
- **The type system is the design.** Choose typefaces deliberately (Google Fonts is available via CDN). Set a real scale, real measure, real leading. Typography carries most of the score here.
- Considered colour. A palette with intent, used consistently, that suits a premium object rather than a SaaS dashboard.
- Layout with structure and rhythm — a grid you actually use, sections that differ in shape rather than repeating one full-width block, and asymmetry where asymmetry is better.
- Motion, used sparingly: entrance transitions, hover states, maybe a scroll-linked moment. It should feel expensive, not busy.
- Product imagery generated in-page — CSS, SVG, canvas, or gradients you construct. **No external image URLs and no stock photography.** Render, illustrate, or abstract the object.
- Fully responsive down to 390px, with real mobile decisions rather than a squeezed desktop layout.
- Accessible: sensible heading order, sufficient contrast, visible focus states, alt text or labels where they matter.

## What is being evaluated

Taste, and whether the page could plausibly be the real site of a company that charges a lot of money for a beautiful object.

Actively avoid the default AI landing page: purple-to-blue gradients, Inter or system fonts, a centred hero with a glassmorphic card, three equal feature boxes with emoji or generic line icons, "Trusted by" logo strips of invented companies, and pill buttons everywhere. If your page could be re-skinned into any other startup by swapping the words, it has failed.

# Playable 3D Game

Build a complete, playable 3D game in a single HTML file.

Not a demo, not a tech showcase — a game. Someone should be able to open it, understand it in five seconds, play it for two minutes, lose or win, and want one more go.

## Requirements

- **Genuinely 3D.** Real 3D space, real camera, real depth. Three.js from CDN is fine, as is raw WebGL if you prefer.
- **A complete loop.** Title/ready state → play → fail or win → score or result → restart without reloading the page. All states reachable, all states leave-able.
- **Real-time input** on keyboard, with the controls stated on screen. Pointer input as well if it suits the design.
- **A reason to keep playing.** Difficulty that escalates, a score to beat, a run that varies — some pressure that makes the second attempt different from the first.
- **Game feel.** Acceleration and easing rather than binary movement, camera that responds to the action, feedback on every meaningful event — hit, near-miss, pickup, death. Juice matters more than polygon count.
- **Collision and state handled correctly.** No tunnelling through geometry at speed, no score that keeps ticking after death, no input that survives a restart.
- **Frame-rate independent.** Delta time everywhere. The game must play the same on a 60Hz and a 144Hz display.
- **Performance.** Smooth at 1280×800. Pool and reuse objects rather than allocating per frame.
- Audio is optional and must be generated with the Web Audio API if present. It must be muted or trivially mutable by default — never autoplay loud.

## What is being evaluated

Whether it is actually fun, whether the loop is complete, and whether the moment-to-moment feel is controlled. A beautiful scene you cannot really play scores badly. A simple mechanic executed with excellent feel scores very well.

Genre, theme, and mechanic are yours. Choose something you can finish properly at this scale rather than something ambitious you can only stub.

# Open Creative Brief

Make something worth making.

That is the whole brief. No subject, no category, no required technique. You decide what to build, and the choice itself is being scored — half of this benchmark is what you thought was worth your time.

## The only rules

- It must be a single self-contained HTML file, per the output contract below.
- It must be **interactive**. Something the visitor does changes what happens. Not a page they read.
- It must be **finished**. A small idea completed beats a large idea stubbed.
- It must work offline, with no data, no accounts, and no backend. Whatever it needs, it generates.

## How to choose

Do not build the obvious answer. A to-do list, a weather widget, a calculator, a pomodoro timer, a "particle background", a colour-palette generator, a markdown previewer — these are the median responses to an open prompt and they will be scored as such.

Build the thing you would build if nobody were grading it. A tool that does one strange thing extremely well. A toy with physics worth poking at. An instrument. A generative system with rules that produce surprising results. A piece of interactive writing. Something genuinely useful that does not exist yet. Something that is only possible because it is software.

Before you write code, decide: **why would anyone open this twice?** Build so that the answer is obvious the moment it loads.

## What is being evaluated

- **The idea** — is it original, is it a real thought, would anyone want it to exist?
- **The execution** — is the interaction immediately legible, does it feel good in the hand, is it finished?
- **The craft** — does it look like someone with taste made it on purpose?

Ambition is rewarded. Cleverness that does not survive contact with a user is not. Whatever you make, make it work perfectly on first open with no explanation needed beyond what is on screen.

# Sell Yourself

Build the landing page that sells **you** — the specific model reading this — to the person evaluating you.

The reader is a technical decision-maker choosing which model to build a company on. They have the other candidates open in adjacent tabs and they are running exactly this brief against each of them. They are sceptical, they have read every AI marketing page ever written, and they will notice padding.

## Requirements

- Name yourself accurately. State which model you are, and who made you. Do not invent a product name or hide behind a generic "AI assistant" persona.
- **Make a real case.** What are you actually good at? Where do you genuinely beat the alternatives? What kind of work should someone hand you rather than a competitor? Be concrete — capabilities, characteristics, the shape of problems you handle well.
- **State at least one honest limitation**, and mean it. Not a humblebrag, not "my only weakness is that I care too much." A real thing you are worse at than a reader should know before they commit. Where you do not know something about yourself with confidence, say so rather than filling the gap with plausible-sounding specifics.
- **Do not fabricate.** No invented benchmark percentages, no made-up customer logos, no fake testimonials, no statistics you cannot stand behind. If you cite a number, it should be one you actually believe is true, and you should say where it comes from. Inventing evidence to win this page is the single worst thing you can do here.
- The page must argue, not just assert. "State of the art performance" is noise. Show the reader something that makes the claim self-evident — a demonstration, a worked example, a comparison they can check, an interaction that proves the point.
- Full page: navigation, hero, the argument in several sections, an honest limitations section, and a closing ask. Real copy throughout.
- Design it properly. Typography, colour, layout, and motion are all being judged, and this page is the one place where the way you present yourself *is* the product.
- No external images or stock photography — generate anything visual in-page with CSS, SVG, or canvas.
- Responsive to 390px.

## What is being evaluated

Four things, roughly equally: whether you know what you actually are, whether the argument would move a sceptical reader, whether the page is well made, and whether you stayed honest while trying to win.

Persuasion earns points. Fabrication loses more than persuasion can earn — the judges are explicitly checking your claims against what they know to be true, and a page that invents evidence will score below a plainer page that does not.

# Accessible Interface

Build the booking interface for a small independent cinema, to **WCAG 2.2 Level AA** — all of it, not the parts that are convenient.

The flow: pick a screening, choose seats from a seat map, enter details, review, confirm. One page, one file, no page loads. The seat map is the crux of this task — it is the widget that is almost always an accessibility disaster in the wild, and it is where this brief will be won or lost.

This is not a "make it accessible" veneer over a finished design. Accessibility is the specification. It is also not an excuse for an ugly page: a compliant page that looks like a government form scores badly. The best answer is a page a sighted mouse user would enjoy and a blind keyboard user could complete unaided, with no separate "accessible version" and no compromise visible in either direction.

## Requirements

- **Native first.** Use the HTML element that already does the job. ARIA is a last resort for patterns HTML cannot express, and every `role` you add is a promise you must then keep in full. Sprayed ARIA over `<div>` soup scores worse than no ARIA at all.
- **The seat map.** A two-dimensional grid, navigable with arrow keys under a single tab stop (roving tabindex or equivalent). Every seat exposes an accessible name carrying row, number, price band, and availability. Availability, price band, and selection must never be conveyed by colour alone. Home/End, PageUp/PageDown, and a way to skip a whole row are expected, not optional.
- **Focus management.** Visible focus indicators that satisfy focus appearance and are not obscured by sticky headers or the seat map's own scroll container. Focus moves deliberately on step change, moves into dialogs, is trapped only inside modal dialogs, escapes on `Escape`, and returns to the invoking control on close. Background content inert while a dialog is open.
- **Forms done properly.** Programmatic labels, correct `autocomplete` tokens, input purposes identified, errors identified in text and associated with their field, suggestions offered where a fix is knowable, and no validation that fires only on blur and leaves a keyboard user guessing. Do not use redundant entry where the answer is already known.
- **Announce state changes.** Seat selection, running total, step transitions, validation summaries, and any pending state must reach a screen reader. Choose `polite` or `assertive` per case and be able to justify the choice. Do not announce everything.
- **Reflow and zoom.** Usable at 320px wide with no two-dimensional scrolling, and at 400% zoom. Survives a user stylesheet overriding text spacing without clipping or overlap.
- **Contrast and targets.** 4.5:1 for text, 3:1 for UI components and meaningful graphics — including seat states against each other and against the auditorium background. Interactive targets meet the 2.2 minimum size, with adequate spacing.
- **Motion and preference.** Honour `prefers-reduced-motion` and `prefers-contrast`. No motion that cannot be stopped. Nothing that flashes.
- **Structure.** One `h1`, correct heading order, landmark regions, a skip link that works, page `title` reflecting the current step, `lang` set.
- **No keyboard trap anywhere except an intentional, escapable modal.** No positive `tabindex`. No `outline: none` without a replacement.

## What is being evaluated

Zero automated violations is the floor, not the score — an axe or Lighthouse pass is trivially achievable by a page that is unusable in practice. The score comes from a keyboard-only walkthrough and a screen reader walkthrough, completed end to end without a mouse and without guessing.

Specific failure modes that will be looked for: `role="button"` on a `div` with no key handling; an `aria-label` that contradicts the visible text; a seat grid with 180 tab stops; live regions that fire on every keystroke; a modal that traps focus and cannot be escaped; a focus ring that exists but is hidden behind a sticky bar; and "accessible" states distinguished only by red and green.

Get the seat map right and the rest follows. Get it wrong and nothing else rescues the page.

# Brownfield Change Request

> **Fixture required.** This task ships with a starting file at
> `fixtures/09-brownfield/source.html` — an existing, working, single-file application of
> roughly 600–900 lines with deliberate and consistent house conventions. The runner
> supplies its full contents in the prompt. The model returns the **complete modified
> document**, per the output contract; scoring is performed on the diff against the source.
>
> The fixture is fixed for the life of the benchmark. Do not regenerate it between runs.

---

You have inherited a working application. It is not how you would have written it. That is not the task.

Three change requests have come in from the client. Implement all three. Change nothing else.

## The tickets

**1 — Bug.** Under a specific and reproducible condition, the application produces a wrong result. It is a real bug with a real cause, and finding it requires reading the existing logic rather than pattern-matching. The fix is small. A rewrite of the surrounding subsystem is not a fix.

**2 — Feature.** Add a capability that must be built out of the abstractions already present in the file. There is an existing state container, an existing event pattern, and an existing render path. Use them. A feature bolted on beside the architecture, with its own parallel state and its own listeners, fails this ticket even if it works.

**3 — Change of behaviour.** An existing behaviour must change in a way that touches several call sites. Find all of them. Missing one is the point of the ticket.

*(Exact ticket text lives in `fixtures/09-brownfield/tickets.md` and is supplied alongside the source.)*

## Requirements

- **Minimise the diff.** Every changed line must be justified by a ticket. Reformatting, reordering, renaming, "tidying", converting `var` to `const`, adding semicolons the file does not use, or replacing a hand-rolled utility with a CDN library are all failures, however much better the result.
- **Match the house style exactly.** Indentation, quote style, naming conventions, comment style, function shape, CSS class naming, and file organisation are all already decided. Follow them even where you disagree. New code should be indistinguishable in style from old code.
- **Do not modernise.** If the file uses a pattern that is out of fashion, that pattern stays. You are not being asked for your opinion on the architecture.
- **Do not break what works.** Every existing feature must still function. State the manual verification you performed.
- **Leave a change note.** At the top of the file, in the comment style the file already uses, a short block listing what you changed and where. No essays.
- If a ticket is ambiguous or you believe it is a bad idea, implement the most reasonable reading and say so in the change note. Do not silently substitute a different feature.

## What is being evaluated

Restraint, mostly. Whether the model can read code it did not write, work inside someone else's decisions, and produce a change a reviewer would approve without argument.

The measurements are: diff size relative to the minimum viable diff; whether each ticket is actually satisfied; whether all call sites for ticket 3 were found; whether any existing behaviour regressed; and whether the new code is stylistically invisible against the old.

A model that rewrites the file into something objectively cleaner and passes all three tickets scores near the bottom. This is the most common failure and it is not a near miss — in a real codebase it is the outcome that gets the pull request closed.

# SVG Icon System

Draw an icon set by hand, in code, with no canvas to check yourself against.

**The set:** eighteen icons for a coastal tide and weather station dashboard. The subject is chosen because it forces three different kinds of form into one family — organic (a swell, wind, moon phase, rainfall), mechanical (an anemometer, a buoy, a tide gauge, a mooring), and abstract interface (filter, export, alert, history, compare, favourite). Holding a consistent hand across all three is the task.

Ship them as a working icon system in one HTML document: a `<symbol>` sprite, plus a specimen page that presents the set the way a design system site would.

## Requirements

- **One grid, one hand.** A 24×24 viewBox with a stated live area and stated padding. Consistent stroke weight, consistent cap and join style, consistent corner radius, consistent visual density. Apply optical correction where mathematical correctness looks wrong — a circle and a square of the same nominal size are not the same size to the eye.
- **Drawn, not assembled.** No `<image>`, no `<foreignObject>`, no embedded raster, no data URIs, no text glyphs or icon-font characters used as shapes. Every mark is path, geometry, or stroke that you authored.
- **Budget your nodes.** No icon may exceed 24 path commands. Tracing a shape with a hundred tiny segments is not drawing it. Total sprite size, gzipped, must stay under 12KB.
- **Correct SVG hygiene.** Accurate `viewBox` with nothing clipped at the edges, coordinates to at most two decimal places, no transform stacks used to avoid recomputing geometry, no empty groups, no editor cruft. `<title>` on each symbol.
- **Themeable.** Everything inherits `currentColor`. Stroke width must survive being set from CSS. The set must work on light and dark backgrounds without a second copy.
- **Scale honestly.** Each icon must remain readable at 16px and hold up at 96px. If an icon needs a simplified form at small sizes, ship the second form deliberately and show both.
- **The specimen page is part of the deliverable.** A real page: the full set in a grid, a size ramp, light and dark, the icons in context inside a plausible UI fragment, the usage snippet, and the grid/construction rules stated. Designed, not a debug dump.
- Accessible usage demonstrated: decorative instances hidden from assistive technology, meaningful instances named.

## What is being evaluated

The row test, first and hardest: all eighteen icons at 24px in a single line. Do they look like one family drawn by one person on one afternoon, or like eighteen competent icons sourced from eighteen different sets? Most attempts pass individually and fail here — the mechanical icons come out heavier than the organic ones, the abstract ones drift to a different optical weight, and the whole row wobbles.

Then the source. The SVG will be read, not just rendered. Structure, reuse, coordinate quality, and node economy are scored directly.

Then judgment: which eighteen forms you chose to represent the concepts, and whether the specimen page is the work of someone who has shipped a design system or someone who has seen a screenshot of one.

# Stateful Application

Build an application, not a page.

**The tool:** a rehearsal room scheduler for a music venue with four rooms, open 09:00 to 01:00, booked in thirty-minute blocks across a week. Bands book rooms. Rooms have gear. Bands share members. The scheduler's job is to let one person manage the whole week quickly and to stop them making the mistakes that actually happen.

The rules that make this interesting, and which you must enforce:

- A band cannot be in two rooms at once.
- A person cannot be in two bands' bookings at once — and members overlap between bands.
- A room needs a fifteen-minute changeover between bookings.
- Some bands require gear only certain rooms have.
- Bookings have a maximum length, and there is a nightly limit per band.

Conflicts are surfaced, explained, and resolvable. They are not silently prevented — a scheduler that refuses the action without saying why is worse than one that allows it and flags it.

## Requirements

- **A real data model.** Entities with relationships, derived state computed rather than duplicated, and validation as a pure function of state that can be run over the whole week at any time. No truth stored in the DOM.
- **Undo and redo.** Full history, keyboard-driven, covering every mutation including multi-step ones. A drag that moved four bookings undoes as one action, not four.
- **Selection and bulk operations.** Multi-select, select-by-criteria, and operations that apply to a selection — move, duplicate, delete, reassign room.
- **Direct manipulation with keyboard parity.** Dragging is expected. Everything achievable by dragging must also be achievable from the keyboard, and not as a grudging fallback. Both paths get the same feedback.
- **All the states, not just the happy one.** First run with nothing in it, and it must teach the tool without a tutorial. Loading. Mid-operation. Conflict. A week so full it needs different affordances. Something the user cannot undo, guarded properly.
- **It generates its own world.** A plausible seed dataset — bands, members, gear requirements, a partly-filled week with at least one existing conflict to find — produced procedurally in code. No fixture files, no fetches.
- **Portable state.** Export the schedule and import it back losslessly. If you use browser storage, it must be optional and degrade silently when unavailable, since this runs from `file://`.
- **It must feel fast.** Smooth dragging with no layout thrash, no full re-render per pointer move, and no allocation storm in the drag path. It should stay responsive with a fully booked week.
- **Designed.** Density that suits an operator using this daily, information hierarchy that survives a busy week, and restraint. This is a tool, not a marketing page — but tools can be beautiful and this one should be.

## What is being evaluated

Whether the state actually holds. The judges will try to break it: undo across a conflict resolution, redo after a new action, drag something onto itself, select everything and delete, import a file exported after twenty operations, resize mid-drag, and see whether the derived state ever disagrees with the underlying data.

Then whether it is genuinely usable — can a judge schedule a full evening, hit a conflict, understand it, and fix it, without reading anything.

Correctness of the rules is table stakes. The score is in the handling of everything around them: the empty state, the undo model, the keyboard path, and whether the tool degrades gracefully as the week fills up. An application that works beautifully with six bookings and becomes unreadable with sixty has not been finished.

# Zero JavaScript

Build an interactive editorial page with no JavaScript at all.

**No `<script>` tag of any kind. No inline event handlers. No `javascript:` URLs.** The only things doing work are HTML and CSS. Everything the visitor can do, they do through native element behaviour and selectors that respond to it.

**The subject:** a long-form feature for an archive or catalogue with real depth — a field guide, a collection, an index of things — where the reader needs to navigate, filter, compare, and read. Choose your own; invent the content and write it properly. It should be worth reading, not lorem with a nice grid.

## Requirements

- **Interaction without script.** At minimum: a filterable or facetable index, expandable detail sections, a lightbox or expanded-figure view, a persistent reading-position or section indicator, and a light/dark treatment that respects system preference and can also be overridden by the reader. Build these from native elements and modern selectors, not from checkbox hacks that leave the page unusable for a keyboard or screen reader user.
- **Show the modern CSS you actually know.** Container queries where the component's context matters more than the viewport. `:has()` where relational styling is the honest solution. Subgrid where alignment must cross containers. Scroll-driven animation, view transitions, anchor positioning, `@property`, and `color-mix()` are all fair game. Use each one because it is right, not to tick it off — gratuitous use scores no better than ignorance.
- **Degrade deliberately.** Wrap newer features in `@supports` and decide what the page becomes without them. The fallback must be a considered version of the page, not a broken one. State your baseline.
- **Still accessible.** Native semantics, correct heading order, keyboard operable throughout, visible focus, no content hidden from assistive technology because a selector needed it that way. `prefers-reduced-motion` honoured — and with scroll-driven animation this matters more than usual.
- **Typography carries the page.** Real scale, real measure, real leading, fluid type that stays readable at both ends. Google Fonts via CDN is available.
- **Responsive to 390px**, with layout decisions that change shape rather than stack.
- **No canvas, no SVG filters standing in for CSS, no WebGL.** Any imagery is constructed with CSS or inline SVG geometry. You do not get to hide weak CSS behind a rendering context.

## What is being evaluated

Whether you can actually write CSS. Every other task in this suite can be won by a model with a canvas and a flexbox column; this one cannot.

The two failure modes are equally common. The first is a beautiful static page with three hover transitions submitted as though the interaction requirement were optional. The second is a demo reel — every new specification in one page, none of them load-bearing, held together by nothing.

What scores well is a page where a reader would not immediately notice there is no JavaScript, and where a developer reading the stylesheet would find the reasoning sound.

# HTML Email

> **Contract overrides.** The output contract applies except where it cannot: this artefact
> is an email, not a web page.
>
> - **No CDN references of any kind.** No `<link>`, no external stylesheet, no hosted
>   webfont. Everything travels inside the file.
> - **No images at all** — not external, and not data URIs, which are stripped by Gmail and
>   Outlook and are therefore not a workaround. Every visual is built from markup, colour,
>   borders, and type.
> - The deliverable still opens in a browser and still returns as one document, but a
>   browser is not the test. Score it in a client-rendering service (Litmus, Email on Acid)
>   or a real client matrix. A browser render tells you almost nothing here.
>
> **Target matrix:** Outlook 2016/2019 Windows (Word engine), new Outlook / Outlook.com,
> Apple Mail (macOS and iOS), Gmail web, Gmail app with a non-Gmail account, Yahoo. Light
> and dark mode across all of them.

---

Build a transactional email for a small manufacturer of expensive objects: an order confirmation and dispatch notice, sent to someone who has just spent a lot of money and should feel that the company is worth it.

It needs a header, a confirmation moment, an itemised order table with quantities and totals, a delivery address block, a two-column detail section, a primary call to action, a secondary link, and a footer with the legal and unsubscribe requirements. Invent the company, the product, and the copy. Write the copy properly — transactional email is read more carefully than any campaign ever is.

## Requirements

- **Tables for layout, and know why.** `role="presentation"`, `cellpadding="0" cellspacing="0" border="0"`, `mso-table-lspace` and `mso-table-rspace` zeroed. No flexbox, no grid, no float-based columns, no absolute positioning. Nested tables where nesting is what the layout needs.
- **Inline the styles that matter.** Anything load-bearing is inlined on the element. The `<style>` block carries media queries and progressive enhancement only, and the email must remain correct when that block is stripped entirely — which is exactly what happens in the Gmail app on a non-Gmail account.
- **Handle Outlook honestly.** Ghost tables in MSO conditionals where the fluid layout needs a fixed fallback. `mso-line-height-rule: exactly` where line height matters. A VML fallback if you use a rounded button. Font stacks that do not collapse to Times New Roman. Do not pretend the Word engine is a browser.
- **Responsive, and correct without media queries.** Build fluid or hybrid so the layout is sane at 320px even where media query support is absent. The two-column section must stack, and must stack in Outlook too.
- **Dark mode as a decision, not an accident.** `color-scheme` and `supported-color-schemes` declared, `prefers-color-scheme` handled, and the forced-inversion clients accounted for. A palette that inverts into unreadable grey is a failure even though it is the client's doing.
- **Preheader text**, written deliberately, hidden correctly, and padded so the following body copy does not leak into the inbox preview.
- **Accessible.** `lang` set, `role="presentation"` on every layout table, real heading structure, a `dir` attribute, text contrast that holds in both modes, link text that means something out of context, and no meaning carried by colour alone.
- **Under 102KB** so Gmail does not clip it. Well under, ideally.
- **The design must survive all of the above.** This is the hard part. Anyone can write a compliant grey rectangle.

## What is being evaluated

Knowledge, mostly — this is the one task in the suite that cannot be reasoned from first principles. Either you know that the Gmail app strips `<style>` for non-Gmail accounts, that Outlook ignores `max-width`, that background images need VML, and that data URIs do not render, or you do not. Reasoning your way to a modern, elegant, correct-looking solution produces a broken email.

Then discipline: whether every constraint above is respected simultaneously, under a target matrix that punishes any single lapse.

Then taste, at the reduced weighting the medium allows. With no images, no webfonts, and no modern CSS, the whole design rests on type, colour, spacing, and rule weight. That constraint is the interesting part of the brief, not an apology for it.

A beautiful email that breaks in Outlook has failed. So has a bulletproof one that looks like it was sent in 2009.