Replies: 3 comments
-
|
Diagram update: Section 2 (Proposed architecture) now uses two diagrams instead of one: a high-level overview (left-to-right flow: Foundation → Platform Repos → Shared Tooling) and an inside a platform repo view (manifest, resolved set, validation, outputs). This should be easier to read than the previous single diagram with many crossing edges. |
Beta Was this translation helpful? Give feedback.
-
|
Update (March 2026): Refocused this thread as the umbrella RFC. Detailed distributed design moved to #715; token/cascade detail is in #646. Added |
Beta Was this translation helpful? Give feedback.
-
Multi-Platform Output Flow (from Figma Variables PoC)Following up on PR #804 (Figma Variables export proof of concept) — here is an updated architecture diagram showing how each platform repo generates its own outputs, including platform-specific Figma Variables. The key insight: because the spec defines a shared manifest + cascade model, each platform team owns its resolved token set and can independently export to Figma for its designers. There is no single centralized Figma export — each platform produces Figma Variables that reflect its own overrides and extensions. graph TD
subgraph Foundation["Foundation — spectrum-design-data"]
SPEC["Design Data Specification"]
TOKENS["Base Token Values<br/>(colors, dimensions, typography)"]
SCHEMAS["JSON Schemas + Validation Rules<br/>(SPEC-001 → SPEC-010)"]
end
subgraph Platforms["Platform Repos + Manifests"]
WEB["Web<br/>pins foundation v2.1<br/>include: color, layout<br/>override: web spacing"]
IOS["iOS<br/>pins foundation v2.1<br/>include: color, typography<br/>extend: iOS dimensions"]
ANDROID["Android<br/>pins foundation v2.1<br/>include: color, layout<br/>override: density"]
end
subgraph WebOut["Web Outputs"]
WJSON["Legacy JSON"]
WCSS["CSS Custom Properties"]
WFIG["Figma Variables<br/>(Web)"]
WDTCG["DTCG Format"]
end
subgraph iOSOut["iOS Outputs"]
ISWIFT["Swift Constants"]
IFIG["Figma Variables<br/>(iOS)"]
end
subgraph AndroidOut["Android Outputs"]
AKOTLIN["Kotlin Constants"]
AFIG["Figma Variables<br/>(Android)"]
end
subgraph Teams["Consumers"]
RSP["React Spectrum"]
SWC["Web Components"]
IOST["iOS Team"]
ANDT["Android Team"]
DSWEB["Designers<br/>(Web)"]
DSIOS["Designers<br/>(iOS)"]
DSAND["Designers<br/>(Android)"]
end
TOKENS --> WEB
TOKENS --> IOS
TOKENS --> ANDROID
SPEC -.->|defines contract| Platforms
WEB -->|resolve + generate| WJSON
WEB -->|resolve + generate| WCSS
WEB -->|resolve + export| WFIG
WEB -->|future| WDTCG
IOS -->|resolve + generate| ISWIFT
IOS -->|resolve + export| IFIG
ANDROID -->|resolve + generate| AKOTLIN
ANDROID -->|resolve + export| AFIG
WJSON --> RSP
WJSON --> SWC
WCSS --> SWC
WFIG --> DSWEB
ISWIFT --> IOST
IFIG --> DSIOS
AKOTLIN --> ANDT
AFIG --> DSAND
This builds on the architecture in Section 4 above and the platform manifest diagram. The Figma Variables PoC (PR #804) demonstrated this working end-to-end for the Web/foundation case — the same Related:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
[DRAFT RFC] Spectrum Design Data Specification
1. Vision
The Spectrum Design Data Specification is a family of RFCs (not a single document) that together define how Spectrum design data is structured, validated, authored, versioned, and consumed across platforms and products.
2. Problem statement (summary)
Today, most Spectrum design tokens and related data live in
spectrum-design-data. We need platform ownership (each implementation ships on its own cadence), a shared foundation (one spec and base values), controlled variation (subsets, type-safe overrides, extensions), and tooling (authoring via PRs, validation, Figma variables from resolved data, automated upgrade PRs).Full problem framing and migration notes: RFC #715.
3. Token naming and cascade (overview)
Naming: taxonomy, vocabulary, and formatting
Token names are decomposed into three independent layers with different malleability profiles (RFC #806,
spec/taxonomy.md):hover→highlighted)The token name object carries semantic fields (identity and structure:
property,component,structure,substructure,anatomy,object,variant,state,orientation,position,size,density,shape) and dimension fields (cascade axes:colorScheme,scale,contrast, plus platform-declared). Semantic fields are validated with advisory severity against the registry; dimension fields are validated strictly against declared modes.Cascade resolution
Normative detail:
spec/cascade.md,spec/dimensions.md, RFC #646.4. Architecture (at a glance)
High-level overview: Foundation publishes spec and base tokens; platform repos consume via a versioned dependency and manifest; shared tooling operates on platform data.
flowchart LR subgraph foundation ["Foundation (spectrum-design-data)"] direction TB spec["Spec + Schemas + Registry"] baseTokens[Base Token Values] end subgraph platforms ["Platform Repos"] direction TB swc[Web Components] rsp[React Spectrum] ios[iOS] android[Android] end subgraph tooling [Shared Tooling] direction TB mgmt[Management App] figma[Figma Variable Generator] bot[Upgrade Bot] report["Report / Diff Generator"] end spec --> baseTokens foundation -->|"versioned dependency + manifest"| platforms mgmt -->|"PRs as authenticated user"| platforms platforms -->|"resolved token sets"| figma foundation -->|"new release"| bot bot -->|"automated upgrade PRs"| platforms platforms --> report baseTokens --> reportInside a platform repo: pinned foundation version, manifest (include/exclude, overrides, extensions, formatting), validation, resolved outputs.
flowchart TB foundationDep["Foundation Dependency (pinned version)"] subgraph manifest [Platform Manifest] include["include (query)"] exclude["exclude (query)"] overrides["overrides (type-safe)"] extensions["extensions (new tokens, registry terms, schemas, formatting)"] end foundationDep --> manifest manifest --> resolved[Resolved Platform Token Set] resolved --> outputs["Outputs: CSS vars, Swift, Kotlin, Figma vars, etc."] validation["GitHub Actions Validation"] --> manifest foundationDep --> validationManifest fields, distribution channels, validation severity, tooling roles, semver, and deprecation flow: RFC #715.
5. Distribution (summary)
spectrum-design-data.Details: #715.
6. Tooling (summary)
7. Relationship to RFCs in this family
name.structureshape evolved into the canonical flat name object inspec/token-format.md.spec/evolution.mdspec/token-format.mdandspec/evolution.mdRepo coordination doc:
docs/rfc-coordination.md(living outline for editors).8. Open questions (umbrella)
Resolved
Query language for manifest— Implemented: filter notation defined ininclude/excludespec/query.mdand CLIquerysubcommand.Alias resolution ordering through cascade— Confirmed: aliases resolve after cascade layer + specificity merge. Documented inspec/cascade.md.Still open
anatomy-terms.jsoninto Component Anatomy, Token Objects, and Taxonomy Categories registries (see #806, #661).9. Request for feedback
Comment on #715 for distributed-design details, on #806 for naming/taxonomy specifics, and on #646 for token format history; use this thread for cross-cutting spec narrative feedback.
Beta Was this translation helpful? Give feedback.
All reactions