feat(spec): add 9 standard CSS component sub-tokens

[tn819]

Summary

Extends the component_sub_tokens vocabulary from 8 to 17 entries to support real-world design systems that use standard CSS properties within component definitions.

Problem

The current 8-token vocabulary (backgroundColor, textColor, typography, rounded, padding, size, height, width) is insufficient for production design systems. Real-world components need additional standard CSS properties:

Missing Token	Real-World Usage
minHeight / minWidth	Touch-target compliance (44 px, 56 px buttons)
fontFamily / fontWeight / fontStyle	Per-component type overrides (serif CTAs, italic margin-notes)
borderColor	Card, chip, and container borders
borderLeftColor / borderLeftWidth	Directional border patterns (left-edge accent)
paddingLeft	Directional padding (margin-note inset)
elevation	Shadow classes (floating SOS/elevated buttons)

Without these in the spec, every real design system that uses them gets a wall of "not a recognized component sub-token" warnings. This makes lint output noisy and obscures actual issues.

Change

Adds 9 new entries to component_sub_tokens in spec-config.yaml, each with:

• A descriptive name matching CSS naming conventions
• An appropriate type (Color, Dimension, string, or number | string)
• An optional description with usage context

All additions follow existing spec patterns. Directional variants (borderLeftColor, paddingLeft) use standard CSS box-model naming.

Testing

Existing tests should pass (no token removals, only additions). The change is backwards-compatible — existing valid DESIGN.md files continue to validate, and the new tokens are recognized.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[davideast]

Hey @tn819, thank you for this. The table of real-world usage is helpful and clearly thought through.

I've been working through a set of similar proposals (#41, #47, #49, #65) and recently published a PHILOSOPHY.md that explains the direction for how the spec evolves. The spec defines a structural minimum and the prose is where the design lives. We're cautious about expanding the token vocabulary toward CSS coverage because the model already knows CSS. It doesn't need minHeight or borderLeftColor re-encoded in the spec to understand those properties.

That said, the problem you're describing is real. Getting a wall of "not a recognized component sub-token" warnings for standard properties like fontFamily or borderColor is noisy and makes the linter output less useful.

I think the fix is in the warning behavior, not in the token list. Right now the linter warns on every unknown component sub-token. That made sense when the list was meant to be exhaustive, but it doesn't fit a format that's designed to be extensible. A better approach would be to either:

1. Downgrade the severity. Unknown sub-tokens could be an info instead of a warning, so they show up but don't clutter the output alongside actual problems.
2. Only warn on likely typos. Similar to how the unknown-key rule works at the top level — use Levenshtein distance to warn when a sub-token looks like a misspelling of a recognized one, and stay silent for clearly intentional custom properties.

Either approach solves the noisy-output problem without adding CSS properties to the spec one by one, which is a path that doesn't have a natural stopping point.

Would either of those approaches address what you're running into? If you're interested in taking on the fix, I'd be happy to work with you on it.