feat(attrs): design + demos for token-based text attributes

[jitendra-jimdo]

Summary

• Adds an engineering reference under docs/ mapping the editor's build, architecture, attribute system, and a feature proposal — written from a fresh read of the codebase after the 6-year hiatus.
• Adds two runtime-only HTML demos that prototype semantic, token-based text attributes (data-font, data-color, data-underline) without modifying src/ or dist/.
• Pins Ruby 2.6.10 via mise.toml and ignores /vendor/bundle + /.bundle so the local Ruby toolchain stops fighting the macOS system Ruby.

What this PR is not

This PR makes no changes to src/ or dist/. It's design + demos. The demos work against the shipped dist/trix.js via three runtime monkey-patches living inside the demo HTML — not the editor itself. The follow-up PR will land the source changes.

The design

Three independent text attributes, each with its own value vocabulary defined by the host theme:

Trix attribute	HTML attribute	Allowed tokens (per current CMS spec)
font	data-font	headline, body, accent
color	data-color	primary, secondary, shade1, shade2
underline	data-underline	pattern1…pattern5

Dimensions are orthogonal — a single piece can carry any combination. HTML output for a piece with {font: "headline", color: "primary", bold: true}:

<strong data-font="headline" data-color="primary">text</strong>

The token-to-style mapping lives in CSS at the consumer (CMS theme), keeping the editor agnostic.

How the demos work (the three runtime patches)

Inside each demo's <script> block, before <trix-editor> is parsed:

1. Trix.HTMLSanitizer.sanitize is wrapped to append the new data-* attribute names to allowedAttributes (default allow-list is style href src width height class target plus data-trix-*).
2. Trix.PieceView.prototype.createElement is wrapped to honour a custom attributeName config key. After the stock function handles tagName / styleProperty / style, our wrapper calls setAttribute(config.attributeName, value) so the token becomes an HTML attribute on the rendered element.
3. Trix.config.textAttributes.{font,color,underline} is registered, each with {attributeName, inheritable: true, parser}. The parser uses Trix.findClosestElementFromNode to walk up to the matching [data-*] ancestor — same shape as href's parser.

Roadmap to a release

When the CLI Tools toolchain is fixed locally (or built elsewhere), the source-side changes are mechanical:

• src/trix/config/text_attributes.coffee — register font / color / underline (~15 lines).
• src/trix/views/piece_view.coffee — extend createElement with the attributeName branch (~3 lines).
• src/trix/models/html_sanitizer.coffee — extend DEFAULT_ALLOWED_ATTRIBUTES (one line).
• Tests in test/src/unit/html_parser_test.coffee and test/src/system/text_formatting_test.coffee.
• bin/blade build → regenerate dist/.
• Bump package.json to 0.13.0, npm publish.
• Consume from workspace/apps/cms/components/editors/TextEditor/TrixTextEditor/index.tsx.

docs/05-color-feature-proposal.md has the full reasoning for the single-colour version of this; it should be either generalised or replaced with a "tokens" version when the source PR lands.

Test plan

• Open color-demo.html in a browser served from the repo root — pick a colour token, see data-color="..." in the serialized HTML pane on the right.
• Open tokens-demo.html — combine font + colour + underline on the same selection, confirm they stack on a single element.
• In tokens-demo.html click Reload from serialized HTML — editor re-parses its own output, all tokens survive.
• Apply bold first, then colour — <strong data-color="...">…</strong> round-trips.
• Cmd+Z reverses the last token change in one step.

To serve locally without the Ruby build:

python3 -m http.server 9292
# then visit http://localhost:9292/tokens-demo.html

🤖 Generated with Claude Code