The spec-config.yaml header says:
This file is the single source of truth for the DESIGN.md format specification.
But the Color type definition is hardcoded as prose in spec.mdx, not derived from the yaml config. This means spec-config.yaml is the source of truth for sections, units, typography properties, component sub-tokens, and recommended token names, but not for what a Color actually is.
The typography properties are fully data-driven from the yaml (typography_properties list), and the spec generator renders them dynamically. The Color type definition should follow the same pattern.
Current state
spec-config.yaml references type: Color in component_sub_tokens but never defines what Color means
spec.mdx has the Color definition as a static paragraph (line 46)
- If someone reads only
spec-config.yaml to understand the spec, they would not know what color formats are accepted
Suggestion
Add a types section to spec-config.yaml that defines the primitive types (Color, Dimension, etc.) with their descriptions and accepted formats. Then update the spec generator to render these type definitions from the config instead of hardcoding them in the mdx template.
Something like:
types:
Color:
description: "A color value is any valid CSS color string."
formats:
- "Hex: #RGB, #RGBA, #RRGGBB, #RRGGBBAA"
- "Named colors: red, cornflowerblue, transparent"
- "Functional: rgb(), rgba(), hsl(), hsla(), hwb()"
- "Wide-gamut: oklch(), oklab(), lch(), lab()"
- "Mixing: color-mix(in srgb, ...)"
note: "All color values are internally converted to sRGB for WCAG contrast checking."
Dimension:
description: "A dimension value is a string with a unit suffix."
units: [px, em, rem]
Related
The spec-config.yaml header says:
But the Color type definition is hardcoded as prose in
spec.mdx, not derived from the yaml config. This meansspec-config.yamlis the source of truth for sections, units, typography properties, component sub-tokens, and recommended token names, but not for what aColoractually is.The typography properties are fully data-driven from the yaml (
typography_propertieslist), and the spec generator renders them dynamically. The Color type definition should follow the same pattern.Current state
spec-config.yamlreferencestype: Colorincomponent_sub_tokensbut never defines whatColormeansspec.mdxhas the Color definition as a static paragraph (line 46)spec-config.yamlto understand the spec, they would not know what color formats are acceptedSuggestion
Add a
typessection tospec-config.yamlthat defines the primitive types (Color,Dimension, etc.) with their descriptions and accepted formats. Then update the spec generator to render these type definitions from the config instead of hardcoding them in the mdx template.Something like:
Related