Does .gui store layout intent or fixed pixels?

There’s a sharp version of the "is this just SVG?" critique that’s worth taking head-on: the hard call for any UI format is whether a file stores layout intent or absolute geometry. Store absolute positions and you’ve reinvented SVG. Store intent and you have to commit to one layout model that iOS, Android, and web will each disagree with. That’s exactly the right framing, and .gui chooses intent, knowingly, because it’s the only choice that makes the format more than a screenshot with editable text.

What "intent" means concretely

A geometry-only file says "this box is at x=16, y=240, 343 wide." An intent file says "these cards are a col with gap="16", each one full-width, inside a frame with 16 padding." The second form carries the reason the layout looks the way it does, so a renderer on a wider screen, or a different platform, can re-run the rule instead of replaying stale coordinates (row vs col vs grid). .gui’s layout vocabulary (stacks, grids, gap, nine-point align per RFC-0012, and tokens for values meant to repeat per RFC-0005) exists precisely so the file records rules, not resolved pixels.

Semantic roles are the same instinct one level up: role="nav-bar" records what a subtree is, not just how it was drawn, so a tool reading the file inherits the author’s intent rather than guessing it back from geometry (RFC-0041). A card grid that only carries coordinates will be rebuilt by the next tool as boxes that happen to line up; one that carries "this is a grid, these are cards" can be rebuilt as the same idea.

The honest cost of choosing intent

Committing to intent means committing to one layout model, and no single model maps losslessly onto every platform’s engine: flexbox, Auto Layout, and Compose’s modifiers genuinely disagree at the edges. This is the real spec work, and the format doesn’t pretend otherwise. Two design decisions keep it tractable rather than solved-by-fiat: the layout primitives are deliberately a small set (a single stack with row/col/grid as sugar, per RFC-0006), so there’s less surface for platforms to diverge on; and open edge cases are worked out in public RFCs rather than hidden in a reference implementation, so the grid system’s unresolved corners, for instance, are argued out in RFC-0032.

The precedent the format follows on purpose is the one that already survived this: the layout model that gets nailed down is defined by the renderer conformance corpus, not by prose in the spec. Where GTK’s .ui, QML, and XAML each kept a single reference implementation and let platforms diverge silently, the intent-vs-geometry line only holds if "what this layout means" is pinned by shared pass/fail fixtures every renderer must agree on (Versioning and the conformance corpus).

So: SVG or not?

Not SVG, because SVG is the geometry answer by design: it has shapes and absolute paths and no concept of a layout that re-runs (.gui vs SVG). .gui pays a real price for taking the intent side of the fork (a layout model it has to defend across platforms), and that price is the whole reason the format is useful instead of being SVG with extra tags.