The Milda Language
The Milda Language is a formal, platform-neutral description of a design system - every component, behavior, style decision, and token, written down precisely enough that generators can turn it into real code. It is the canonical form of the IR: the Studio authors it, every generator consumes it.
#A spec, not a syntax you type
You never hand-write the Milda Language. Its canonical shape is plain data - a JSON AST with a normative schema - and the visual editor is what produces it. There is a human-readable surface syntax, but it exists for trust: so you can diff a release, review a change, and inspect exactly what your system is. The language is the contract between the editor and the generators, not an authoring surface.
This matters because it changes what a design system is. Instead of a React library that happens to encode your decisions, your decisions become the artifact - and libraries are compiled from them. See The IR for how this fits the pipeline.
#The four layers
Everything the language can say falls into four layers:
- Behavior atoms - interaction modeled as small, formal state machines: a toggle flips a boolean, a presentation opens and closes, a selection tracks the chosen member. Atoms emit states (
checked,open,selected…) and compose through a small wiring algebra. See Behaviors reference. - Archetypes - component blueprints. An archetype bundles an invariant contract (data in and out), a published anatomy (named, platform-neutral parts), and a composition of behavior atoms. The built-in catalog covers the patterns shared by every major design system. See Archetypes reference.
- Style facets - an abstract paint vocabulary (
fill,ink,elevation,ring…), token-valued and keyed by behavior-emitted states - never CSS properties or pseudo-classes. See Facets & tokens. - Layout - structure expressed in the propose/choose model shared by SwiftUI, Compose, and Flutter, with per-axis sizing intents instead of flexbox mechanics. See Layout model.
Beneath all four sit tokens - the typed, layered, context-aware value layer described in Foundations.
#One model, many platforms
The language contains no CSS, no HTML tags, no framework APIs. Anything platform-specific is a realization - how a generator resolves the neutral model on a concrete target. Divergence is handled by two mechanisms, split by what diverges:
- Style and value divergence (elevation, focus rings, spacing, color) collapses into token aliasing over context dimensions - platform, color scheme, density. No per-platform style code exists anywhere.
- Behavior and structure divergence (a select is a popover listbox on the web but can be a wheel on iOS; a checkbox becomes a switch) is a declared realization or substitution of the same archetype. The contract never changes - same contract, same component, however deep the per-platform difference runs.
#Where the language lives in practice
The built-in catalog - atoms, archetypes, facets, states, capabilities - is the language's prelude, its standard library. When you create a component in the Studio you pick an archetype from the prelude; the document the Studio maintains is a design-system instance written in the language; and a release is that document compiled by a generator. Authoring walkthrough follows a component through that whole arc.
#In this section
- Behaviors reference - the atoms, composites, decorations, and non-behaviors.
- Archetypes reference - every built-in component blueprint, grouped by category.
- Facets & tokens - the paint vocabulary and context-aware token binding.
- Layout model - propose/choose, sizing intents, and positions.
- Authoring walkthrough - how a component comes to life in the Studio.