SML

SML (Samva Markup Language) is the source language behind Samva email templates, an HTML-like set of primitives plus an email-safe Tailwind class subset, written in .samva files. It's the same syntax the editor's canvas edits, the source pane shows, and Samva's built-in template agent (and any BYO agent, via MCP) writes directly.

Why a language instead of raw HTML

Email HTML is a minefield: Outlook renders with Word's layout engine, Gmail strips <style> tags in some contexts, and display:flex/grid/position silently do nothing in the clients that matter most. Hand-written HTML+CSS either targets the lowest common denominator by memory, or breaks in a client nobody tested.

SML takes a different approach: compiled, compliant-by-construction. You write a small, closed set of primitives (<Section>, <Row>, <Column>, <Button>, ...) and a class subset chosen for guaranteed cross-client rendering. The compiler, not you, owns every client-compat trick: Outlook table layout, mso-* conditional comments, the Yahoo/AOL body-style workaround, the Outlook button padding hack, dark mode <style> duplication for Outlook.com. If your source compiles, it renders correctly in Gmail, Outlook (classic and new), Apple Mail, and Yahoo. That's the guarantee the grammar exists to make.

No Raw, ever

There is no escape hatch that injects arbitrary HTML into an SML document. Every document is valid SML, full stop, because the grammar itself is the integration contract. The built-in agent and a customer's own agent (over MCP) write to the exact same surface: valid SML in, typed compile diagnostics with fixes out. Punching an arbitrary-HTML hole would mean two ways to author templates, one of them uninspectable by the checks engine. (Raw HTML is still supported at the send API for one-off sends. That's a separate surface, unrelated to templates, and still linted by the same checks engine.)

Strict grammar, on purpose

SML's grammar is JSX-strict, not HTML5-lenient: every tag is closed, every attribute is quoted, and only known tags/attributes/classes are legal. There's no "tag soup" repair pass silently reinterpreting malformed input. An unclosed tag or an unknown class is a compile error with a source span and a suggested fix, not guesswork.

This costs agents nothing and saves everyone debugging time. LLMs already write well-formed HTML+Tailwind by default; strictness just means the first mistake surfaces immediately, with enough information to fix it in one retry, instead of rendering "mostly right" and shipping a broken email.

The .samva extension

SML source files use the .samva extension, following the vendor-language pattern of .svelte, .vue, .astro, and .prisma. The name and extension are deliberately channel-agnostic, but SML is email-only: SMS and WhatsApp templates stay structured documents, because those channels have different customization and approval constraints.

What's next