Versioning, interactivity, and the conformance corpus

Two of the most substantive questions raised about the format weren’t about syntax. They were about time and trust: does it handle component state and interactivity? and the ecosystem is the existential question, not the spec. Both are fair, and both have the same shape of answer: a deliberate order of operations, published in the open, rather than a promise everything already works.

Where the format is: v0.2, visual first

The current spec (v0.2) already covers the visual building blocks: frames, stacks, grids, text, images, shapes, tokens, styles, variants, fonts, effects, and light/dark modes. The whole point of the 0.x line is to find what’s still missing on the visual side and close it, so that v1.0 can credibly claim to describe any static UI completely. That’s the near-term work: coverage of the visual surface, not new capability categories.

Interactivity and state: planned for v2.0

Today .gui describes components, variants, and styles, so a button’s hover and pressed appearances can exist as variants, but it does not yet describe behavior: what triggers a state change, conditional visibility, data binding, or motion. That’s intentional sequencing, not an oversight. The plan is to stabilize the visual format through v1.0 first, then layer motion and richer interactivity on top in v2.0, the same way SVG settled its static drawing model before SMIL animation was built over it. Designing interactivity before the visual base is stable would mean specifying behavior against a moving target.

The ecosystem question, answered honestly

The sharpest critique is historical: SVG and HTML won because standards bodies shipped thousands of pass/fail conformance tests alongside reference renderers, so platforms couldn’t diverge silently. XAML, QML, and GTK’s .ui each had a single reference implementation, no public test corpus, and each platform drifted until the format stayed an export target. A UI format’s real spec is its conformance corpus, not its prose, and any serious effort has to ship fixtures (nested grids, RTL, intrinsic sizing) before it ships features.

The format takes that seriously rather than waving it off. Two things already point that direction: the engine is 100% deterministic (validation, rendering, and scoring make zero AI calls, per RFC-0010), which is a precondition for reproducible pass/fail tests at all; and every change to the format goes through a public RFC process in dotgui/core, so the edge cases that break naïve renderers (see RFC-0032 on grids) get argued out in the open before they’re fixed in one implementation’s quirks. The honest status: a growing fixture corpus and a second independent renderer are the work that matters most for the format’s survival, and they’re treated as such, not as something the spec already finished.

What "1.0" will actually mean

A credible v1.0 is not "more tags." It’s (1) visual completeness, nothing static a designer needs that the format can’t express, and (2) enough of a conformance corpus that two independent renderers agree on the fixtures. Motion, behavior, and data binding are explicitly deferred to v2.0 so that 1.0 can be a stable, testable, boring foundation. That ordering is the roadmap.