feat(spec): add textTransform typography token

[edgarasben]

Summary

Adds textTransform as an optional typography token property.

This enables DESIGN.md files to express text casing rules, such as uppercase labels, in a machine-readable way instead of relying only on prose.

Motivation

Text casing is currently only expressible through natural language, for example:

Labels should be uppercase.

That works for humans, but it is harder for tooling and agents to interpret consistently. Adding textTransform lets a design system define casing behavior directly in typography tokens.

Example

typography:
 caps:
   fontFamily: Inter
   fontSize: 12px
   textTransform: uppercase

Changes

• Adds textTransform to the typography token spec
• Updates the generated spec documentation
• Updates the README typography token reference
• Adds model support for reading textTransform
• Adds a model test covering textTransform

Compatibility

This is optional and backward-compatible. Existing DESIGN.md files do not need to change.

[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.

[edgarasben]

@davideast what do you think?

[davideast]

Hey @edgarasben! Thank you for taking the time to contribute!

I'm a bit on the fence about this one. One one hand it fits in nicely with the tokens but on the other it also is common to see in prose within the typography section. We need to figure out a better way to prevent contradictions via prose and tokens and also tackling variants so you are not fixed to only uppercase headings for everything.

Let me look over some of the proposals and ideas for contradictions and variants and I'll get back to you shortly.

[edgarasben]

@davideast in my experience, some brands prefer some or all of their title/heading styles to be in uppercase for example.

[davideast]

Hey @edgarasben, apologies for the delay but I'm finally following up on this.

Since my last reply we published a PHILOSOPHY.md that explains the direction for how the spec evolves. The core idea is that the spec defines a structural minimum and the prose is where the design lives. The model already knows CSS. It doesn't need textTransform re-encoded in the spec to understand "labels should be uppercase."

textTransform is a good example of the tension. It's a real property that real design systems use. But it's one of many CSS typography properties that could be added (text-decoration, text-indent, word-spacing, white-space, etc.). Adding them one by one expands the spec toward CSS coverage.

What we're building instead is a configurable linter (#89 raised the same tension from a different angle). Projects will be able to register custom properties that the linter recognizes, so your design system can use textTransform in typography tokens without getting warnings, and without needing it in the spec itself.

In the meantime, you can already use textTransform in your DESIGN.md. The format accepts any property in typography tokens. The linter will note it as unrecognized, but it won't block anything.

I'm going to close this PR for now since we're not expanding the core typography vocabulary at this time. But the use case is valid and will be supported through configuration. Thank you for raising it.