Yesterday I wrote about the page editor and the typed tree underneath it. The useful thing about that tree is what it is not. It is not a page. A page is one way of rendering it.

So the question stops being how do I build a page editor and becomes what else is a tree of sections and blocks. Over the past few weeks the answer has been most of what a marketing site is made of. Pages and posts. Headers and footers. Sidebars. The templates that arrange them. Dialogs. Forms. And email, which fights back.

None of those needed a second editor. Each one is the same tree in a different table, with a palette offering the blocks that make sense there. A help centre and a documentation site are the same shape again, and I expect they arrive the same way when I get to them.

They divide into three groups, and what separates them is small.

Content someone reads. A page, a post, an email. These have a lifecycle. They are drafted, published, sometimes scheduled. Someone arrives at one of them deliberately.

Chrome that wraps content. A header, a footer, a sidebar, a dialog, and the template that positions them. Nobody navigates to a header. It is always live, there is no draft of it, and changing it changes every page it wraps.

Forms. A form is a tree of blocks like everything else, except its blocks collect input instead of displaying it. A text field is a block. A select is a block. The submit button is a block. Laying out a form uses the same canvas and the same drag targets as laying out a page.

What differs between the three: which table the row lands in, whether the type has a published state, and which blocks the palette offers. Everything else is the same code, not merely the same approach. One tree shape, one set of drag interactions, one undo stack.

A template has to contain a page it does not know about, which is the one thing in the tree that could not be solved by another block type.

It was solved by another block type. A template is an ordinary tree, edited in the ordinary canvas, except four of the block types available in it render nothing at all. One says the header goes here. One says the footer goes here. One says a sidebar goes here, and how wide. And one says this is where the body goes, whatever the body turns out to be.

At render time the server walks the template, swaps each marker for the tree it points at, and hands the result to the renderer as one flat set of sections. The renderer never learns that a template existed. It receives a page and draws it.

A person editing a template drags those markers around like any other block. Putting the sidebar on the left means dragging the sidebar marker before the body marker. There is no template editor, no template language, and nothing new to learn.

Most of those surfaces render the way a page does: HTML, in a browser, which is forgiving. Email does not.

An email is a hostile target. Tables inside tables, a decade of client quirks, no reliable stylesheet, rules that were old when the browser was young. A page and an email are different engines with a different set of things that work.

A button is still a button in both places, with the same options. The person who placed it thought about a button, not about either rendering. Here it is on its way to the inbox:

Email gets its own block types, which is the one place the model breaks down. An email heading and a page heading are separate definitions, because the constraints are different enough that a single block would render badly in both places. The vocabulary is shared, the code is not. When the page button gained an outline variant and a border radius, the email button gained them too, and the compiler learned to express them in a way a mail client would honour.

Every surface relates to the palette the same way. A block declares which contexts it belongs to, and the palette is that registry filtered. The email palette and the page palette are two views of one library. A form field never appears while you are laying out a header, and nobody maintains a second list to make that true.