DEVCLUSTERAI
STU-13 — THE LETTERS · EIGHT EMAIL TEMPLATES, RENDERED AND CHECKED
PLATE 01 — THESIS
I

The letters.

Eight email templates for the cluster's waitlists, rendered from their committed source with the example data the confirmation sends use, and shown here as the markup that ships — not as pictures of it. Each was drawn in three browser engines at two widths, every CSS property it uses was checked against caniemail's dataset, and every line was measured against the transport's 998-octet limit.

What this sheet is honest about: no paid render farm was used. Read plate 03 before trusting plate 02.

8
TEMPLATES
48
ENGINE RENDERS
308
FEATURES IN THE DATASET
0
PAGE ERRORS
>>_PLATE 03
III

The method, and its limit

Three checks were run, each a real measurement. What they cannot see is stated at the same size as what they can.

3 BROWSER ENGINES

Blink, WebKit and Gecko, driven by Playwright: the engines under Gmail's web and Android clients, under Apple Mail and every browser on iOS, and under Thunderbird. Each letter at 640 and at 375, full-page, with scroll height, horizontal overflow, image count and page errors recorded. 48 renders; 0 page errors; 0 with overflow after the fix in finding 01.

308 FEATURES, CANIEMAIL.COM

The dataset at api/data.json, last updated 2026-09-16. Every CSS property and HTML feature each letter uses was looked up against Gmail, Outlook, Apple Mail and Yahoo on the platforms we actually send to — fifteen client-platform pairs. The matrix on plate 05 is that lookup, not an opinion.

998 OCTETS PER LINE, RFC 5321

The transport's line limit. A real send on 22.09.26 exceeded it and the letter arrived corrupted. Every rendered line was measured in octets; the longest now is 884, in the altineris letter, and none of the eight crosses the limit.

WHAT WAS NOT DONE
No paid render farm.

Litmus and Email on Acid photograph the actual clients. Neither was used, so there are no real Gmail or Outlook screenshots on this sheet. An engine render plus a support matrix is a strong proxy: it catches the structural faults — overflow, broken images, lines the transport will fold — and it names every property a client will drop.

It does not catch what Outlook on Windows will do once its Word rendering engine gets the markup, and it does not see the dark-mode transforms Gmail and Outlook apply on their own. Those remain unverified here, and the last check — one real send, read by a person in a real inbox — is what stands in for them.

>>_PLATE 04
IV

Findings

Four things the checks turned up, re-verified on 23.09.26 against the letters as merged. One of them is the reason this sheet exists.

01A REAL BUG, FOUND AND FIXED

Thirty-two pixels, in every engine

optin.html, welcome.html and newspaper.html — the generic three, the templates every product starts on — each set .wrap { width: 100%; padding: 32px 16px } with no box-sizing. Content-box is the default, so the block was the whole viewport plus its padding: exactly 32 px of horizontal overflow at 640, at 375 and at 320, in Blink, WebKit and Gecko alike.

The web-developer reflex is box-sizing: border-box. caniemail says that property is unsupported in Outlook on Windows, in all of Yahoo, and in Gmail's mobile webmail. The obvious fix would have looked right in all three engines here and failed silently in the clients that matter most.

The fix that went in drops width: 100%. A block fills its container by default, and every client agrees on that. Re-rendered: 0 px of overflow in all 48. This is the study's point — an email-specific constraint making the web reflex the wrong answer, and the engine render alone would not have said so.

BEFORE — .WRAP AT 375
VIEWPORT 375
WIDTH 100% + 16 + 16 PADDING
32 PX
AFTER — WIDTH DROPPED
VIEWPORT 375
BLOCK, PADDING 16 + 16 INSIDE
0 PX
THE REFLEX — BOX-SIZING
OUTLOOK WINDOWS YAHOO, ALL THREE GMAIL MOBILE WEBMAIL
THE FIX — NO WIDTH
BLOCK DEFAULT, EVERY CLIENT 0 PX AT 640 · 375 · 320 ALL THREE ENGINES

SUPPORT VERDICTS FROM CANIEMAIL, 2026-09-16. THE DRAWING IS TO THE CSS, NOT TO SCALE.

02CLOSED — ALTINERIS

The plate was never missing

The Altineris letter carries one remote image, the 560 × 96 animated plate of the Readers, now at the foot of the letter. Revision A of this sheet rendered it broken in all six of its renders and left the item open. The cause was the audit's own example data, which named assets.devclusterai.com — a host that does not resolve. A bad test fixture, not a missing upload. The template reads {{ .Tx.Data.meta.plate_url }} from the product's meta column, and that column was right all along.

Checked again on 23.09.26, from this sheet's build: mail.devclusterai.com/altineris/readers.gif, the R2 bucket the repository documents, answers 200 with a 10,382-byte GIF of 8 frames; the live product row's plate_url, read from D1, is that same address; and the fixture now names it too. Re-rendered: 0 broken images in 48. With images blocked the letter still reads — the wordmark, the headline and the orbit scene are table cells, and only the Readers are a picture.

THE CHAIN, AS CHECKED
TEMPLATEoptin-altineris-v2.html · <img src="{{ .Tx.Data.meta.plate_url }}">
DRAWN BYscripts/make-readers-gif.py · 560 × 96 · 8 FRAMES, THE FIRST COMPLETE FOR OUTLOOK
REV A FIXTUREassets.devclusterai.com/… · HOST DID NOT RESOLVE
HOSTEDmail.devclusterai.com/altineris/readers.gif · 200 · 10,382 B · 23.09.26
LIVE ROWproducts.meta.plate_url, D1 · SAME ADDRESS · 23.09.26
FIXTURE NOWoptin-data-v2-prod.json · SAME ADDRESS · SO THE FRAME ABOVE IS WHAT A SUBSCRIBER SEES

THE PLATE URL, ITS STATUS, SIZE AND FRAME COUNT, AND THE LIVE ROW ARE READ AT BUILD TIME; NONE OF THEM IS TYPED.

03CHECKED — DEVCLUSTERAI

Font-stretch, and which way it fails

font-stretch is unsupported in Gmail on Android, Outlook on Windows and Android, and all of Yahoo. It appears once across the eight letters: on the DevClusterAI headline — the river take, chosen over two earlier ones and since named plainly optin-devclusterai.html — as font-stretch: 112% beside font-variation-settings: 'wdth' 112 and a Google Fonts link for Archivo at that width. 112 is an extended width, not a condensed one.

Where the <link> survives and the web font loads — Apple Mail, Outlook for Mac — Archivo arrives as a single wdth-112 face and there is nothing for font-stretch to choose between. Where the link is dropped — Gmail, Yahoo, Outlook.com and Outlook on iOS and Android, per the same dataset — Archivo never loads and the headline sets in the fallback stack: 'Arial Narrow', 'Roboto Condensed', Helvetica.

So the failure runs the other way from the one feared. The headline does not fail to condense; it condenses where it was drawn wide. The thing to reconsider is the fallback stack, not the property.

THE HEADLINE'S FONT RULE, AS SHIPPED
font-family: 'Archivo', 'Arial Narrow',
  'Roboto Condensed', 'Helvetica Neue',
  Helvetica, Arial, sans-serif;
font-stretch: 112%;
font-weight: 620;
font-variation-settings: 'wdth' 112, 'wght' 620;
font-size: 42px;
LINK KEPTAPPLE MAIL · OUTLOOK MACOS — ARCHIVO 112 LOADS. OUTLOOK WINDOWS KEEPS THE LINK BUT @FONT-FACE IS ONLY PARTIAL THERE
LINK DROPPEDGMAIL · YAHOO · OUTLOOK.COM · OUTLOOK IOS, ANDROID — FALLBACK, NARROW

VERDICTS FOR <LINK>, @FONT-FACE AND FONT-STRETCH FROM CANIEMAIL, 2026-09-16.

04CLEARED — THE TRANSPORT

Under 998, all eight

RFC 5321 gives a line of text at most 998 octets. On 22.09.26 a real send crossed that and the transport folded the line, which corrupted the letter in transit. The template source has since been wrapped (scripts/wrap-lines.py), and the audit measures the rendered output rather than the source, because the data can lengthen a line. Longest rendered line: 884 octets, in the altineris letter. Violations: none.

LONGEST RENDERED LINE, OCTETS
03ALTINERIS884
05PERSONAL739
01AUTO-E2E603
02DEVCLUSTERAI512
04RESEARCH STACK503
06GENERIC OPT-IN194
07WELCOME194
08NEWSPAPER — CAMPAIGN185

LIMIT 998. GENERIC LETTERS ARE SHORT BECAUSE THEY CARRY NO DRAWING.

>>_PLATE 05
V

The support matrix

Every feature used by at least one letter that at least one client we send to does not support. The verdict shown is the worst across that client's platforms; the count says how many of them. The last column names the letters that use it.

SUPPORTED ON EVERY PLATFORM PARTIAL SOMEWHERE UNSUPPORTED SOMEWHERE
FEATUREGMAILOUTLOOKAPPLE MAILYAHOOUSED BY
color-schemeNO · 4/4NO · 5/6YESNO · 3/306 07 08
font-stretchNO · 1/4NO · 2/6YESNO · 3/302
overflow-wrapNO · 3/4NO · 5/6PART · 2/2NO · 3/301
text-underline-offsetNO · 4/4NO · 6/6YESNO · 3/301 02
background-sizeNO · 1/4NO · 2/6YESYES01
text-decoration-colorNO · 1/4NO · 2/6YESYES05
word-breakPART · 3/4NO · 1/6PART · 2/2NO · 3/301 02 03 04 05 06 07
background-imageYESNO · 2/6YESPART · 3/301
background-positionYESNO · 2/6YESYES01
border-radiusYESNO · 2/6YESPART · 3/301 04 06 07
border-spacingYESNO · 3/6YESYES01
floatPART · 2/4NO · 2/6YESPART · 3/308
heightYESPART · 1/6YESNO · 3/301 02 03 04 05 06 07 08
max-heightYESNO · 2/6YESYES01 02 03 04 05
min-widthYESNO · 2/6YESYES05 06 07
outlineYESNO · 2/6YESYES03
overflowPART · 4/4NO · 2/6PART · 2/2PART · 3/301 02 03 04 05 06 07
table-layoutYESNO · 2/6YESYES01
text-decoration-styleYESNO · 2/6YESYES05
white-spacePART · 2/4NO · 2/6YESPART · 2/301 02 03 04 05
word-wrapPART · 2/4NO · 3/6YESYES05

READ ACROSS: color-scheme — THE GENERIC THREE'S DARK-MODE HANDLING — IS HONOURED ONLY BY APPLE MAIL; GMAIL, OUTLOOK AND YAHOO APPLY THEIR OWN TRANSFORMS INSTEAD. border-radius, background-image AND background-size FALL AWAY IN OUTLOOK ON WINDOWS, WHICH IS WHY THE DESIGNED LETTERS DRAW IN TABLE CELLS. height IS DROPPED BY YAHOO EVERYWHERE.

PARTIAL ONLY
FEATUREGMAILOUTLOOKAPPLE MAILYAHOOUSED BY
backgroundYESPART · 2/6YESPART · 3/301 02 03 04 05 06 07 08
borderYESPART · 2/6YESYES01 02 03 04 08
displayPART · 2/4PART · 2/6YESPART · 3/301 02 03 04 05 06 07
font-sizeYESPART · 2/6YESPART · 3/301 02 03 04 05 06 07 08
font-weightYESPART · 2/6YESPART · 3/301 02 03 04 06 07 08
letter-spacingYESPART · 2/6YESYES01 02 03 04 06 07 08
line-heightYESPART · 2/6YESYES01 02 03 04 05 06 07 08
list-stylePART · 4/4PART · 2/6YESPART · 3/306 07
marginPART · 4/4PART · 5/6YESPART · 3/301 02 03 04 05 06 07 08
max-widthYESPART · 2/6PART · 1/2YES01 02 03 04 05 06 07 08
paddingYESPART · 2/6YESYES01 02 03 04 05 06 07 08
text-alignPART · 2/4PART · 3/6YESPART · 3/301 03 04
text-decorationPART · 2/4PART · 2/6YESYES01 02 03 04 05 06 07 08
text-transformYESPART · 2/6YESYES01 02 03 04 06 07 08
widthYESPART · 1/6YESYES01 02 03 04 05

PARTIAL MEANS CANIEMAIL RECORDS A CAVEAT — A VALUE IGNORED, A UNIT REJECTED, A CONTEXT WHERE IT DOES NOT APPLY. NONE OF THESE IS A STRUCTURAL FAULT; ALL OF THEM ARE WHY THE APPROVAL INBOX IS STILL THE LAST CHECK.

>>_PLATE 06
VI

The renders register

All 48 renders on one table: scroll height in pixels per engine at 640 and 375, then the faults counted across the six. Heights differ between engines by a few pixels where the fonts fall back differently; that is normal, and the numbers are shown so the differences are visible rather than smoothed.

LETTERBLINK 640BLINK 375WEBKIT 640WEBKIT 375GECKO 640GECKO 375OVERFLOWBROKEN IMGERRORS
I AUTO-E2E143017911431179214101792000
II DEVCLUSTERAI114312791143127811371273000
III ALTINERIS102811291028112910291129000
IV RESEARCH STACK104015021040150210401502000
V PERSONAL900900900900900900000
VI GENERIC OPT-IN900900900900900900000
VII WELCOME900900900900900900000
VIII NEWSPAPER — CAMPAIGN900900900900900900000

A HEIGHT OF 900 IS THE VIEWPORT: A LETTER SHORTER THAN THE WINDOW READS 900. THE THREE ENGINES NOW AGREE ON EVERY LETTER WITHIN 21 PX; THE WIDEST SPREAD IS AUTO-E2E AT 640. IN REVISION A WEBKIT DREW ALTINERIS 464 PX TALLER THAN THE OTHER TWO, BECAUSE IT RENDERS A DEAD IMAGE AS A FULL-WIDTH PLACEHOLDER BOX WHERE BLINK AND GECKO COLLAPSE IT TO ITS ALT TEXT — A SCREEN OF EMPTY SKY, WHICH IS WHAT A DEAD PLATE URL WOULD LOOK LIKE IN APPLE MAIL. THE PLATE WAS NEVER DEAD; THE FIXTURE WAS. SEE FINDING 02.