Whole sections an author drops in one click — a hero, a feature row, a pricing table.

The palette lists 183 components and the Studio's Presets tab is a catalogue of whole-page themes that nothing on disk supplies. Between the two there was nothing: to get a landing page you placed a grid, then a heading, then a paragraph, then a button, then set the column count, and repeated it for every band down the page. Elementor and Gantry both answer this with a section library, and it is the single thing that decides whether someone who is not a developer finishes a page.

Why these are plain HTML and Tailwind

A block that reached for chelekom-card would be a block that fails on an install without Chelekom, and the whole point of the kit-agnostic work is that no part of the editor assumes one kit. Every block here is div/h2/p/a with utility classes, so it renders on any install, and every node inside it is an ordinary element the Inspector already knows how to style. An author who does have a kit can replace any piece afterwards.

What a block is

A %{id, title, category, template} map. template is HEEx that Tree.parse/1 accepts, and it may have several roots — Tree.insert/4 splices them into the sibling list as ONE undoable op, so a fourteen-node hero arrives and leaves in a single step.

Blocks are code, not content: they ship with the CMS, are the same for every tenant, and are never edited in place. Anything an author saves for reuse is a MishkaCmsCore.Runtime.Snippet, which is a different thing with a different lifetime.

Why every block opens with a band tag

MishkaCmsCore.Runtime.PageBuilder.Placement reads band-ness off the head node's tag, and a component head is not a band. A block whose template started with <.form> or a <div> would be treated as a leaf and land inside whatever was clicked rather than beside the other slices of the page, so every block here opens with a <section>, <header>, <footer> or <main>.

What a form block is

A real form rather than a picture of one. <.form> is Phoenix.Component.form/1 and <.input> is MishkaCmsCore.CoreComponents.input/1; both are imported into every compiled page and both are resolved by the editing canvas, so a form block renders the same on the palette card, on the canvas and on the published page — on an install carrying no UI kit at all. An author who does have one swaps a field for the kit's own through the Inspector, per site.

Five attributes carry everything a form needs and all five come from one seed the author types once: contact gives id="contact-form", as={:contact}, for={assigns[:contact_form]}, phx-change="contact_validate" and phx-submit="contact_submit". MishkaCmsCore.Runtime.PageBuilder.PageForms.Naming mints and renumbers them, so dropping one block twice gives contact and contact_2 rather than two forms sharing one page assign, and gives each form a token as it lands (contact-k7m2q-validate, contact-k7m2q-submit). The page compiler reads the markup back through MishkaCmsCore.Runtime.PageBuilder.PageForms and generates both handlers, so a dropped form works with no Elixir written anywhere.

What is checked is the HTML constraint attributes already on the field — required, minlength, maxlength, data-format — declared once, enforced by the browser and re-checked on the server, so the two cannot disagree. data-success on the form node is what the visitor is told afterwards.