Diagrams you declare, not draw.

What it looks like

You describe the structure. The engine works out every coordinate.

<diagram padding="16">
  <row gap="28">
    <rect id="a">Parse</rect>
    <rect id="b">Layout</rect>
    <rect id="c">Render</rect>
  </row>
  <connect from="a" to="b"/>
  <connect from="b" to="c"/>
</diagram>

Nothing in that source says where anything goes. <row> says these things sit in a row; <connect> says these two are related. Positions fall out of that.

Four ideas

The tag is the shape. <rect>, <ellipse>, <diamond>, <hexagon> — marks are the vocabulary, and the vocabulary is extensible: a shape is just data (a unit-box outline), so registering one gives you both its rendering and its connector clipping for free.

Positions are solved, not assigned. The layout tree desugars into difference-constraints, and <align> / <distribute> compile into constraints too. Explicit relations beat structural placement, so one element can be stacked, aligned and connected at once — and you can align two elements that live in different parents, which a strict layout tree cannot express.

Appearance is CSS. Output carries semantic classes and a palette of custom properties, so you restyle a diagram's chrome by overriding a few variables, and dark mode comes free via prefers-color-scheme. Two things sit outside that palette: colours a scale chose (pie slices, categorical fills) are pinned by the data, and a variable you override yourself stops following the reader's colour scheme — you have taken it over.

Charts are the same language. A Grammar-of-Graphics data layer means <plot> is a coordinate frame hosting mark layers. Pie is not a chart type; it is bars in polar coordinates. The same engine draws your architecture diagram and your bar chart.