ひとつの体系を、
5 つのプラットフォームへ。

ずれない仕組みを、最初から

link

description

信頼できる情報源は 2 つだけ

人が書く契約は、デザイントークンとコンポーネント仕様の 2 つだけです。各プラットフォームのコード、このドキュメント、ステータス表はすべてそこから導かれ、食い違いが生じれば CI が失敗します。

extension

同一ではなく、パリティ

どのプラットフォームでも、トークン・状態・アクセシビリティの意味は同じです。一方で API の形は各プラットフォームの慣習に従います。Compose なら enabled、Flutter なら onPressed に null、SwiftUI なら .disabled(_:) です。

menu_book

実績のある構造

リファレンス・システム・コンポーネントの 3 層トークン、カラーロール、タイプスケール、テーマとコントラストごとに生成するトーナルパレット。見た目は抑制が効いていて、ほぼモノクロームです。

verified

構造で守るアクセシビリティ

コントラストの組み合わせは、すべてのテーマとコントラストレベルについてビルド時に検証されます。見た目の大きさがヒット領域を決めることはなく、フォーカスリングはすべての操作可能なコンポーネントの仕様に含まれます。

次に読む

link

はじめにお使いのプラットフォームでの導入と使い方。基礎ブランド、トークン、カラー、タイポグラフィ、形状、エレベーション、モーション、アクセシビリティ。ステータス各プラットフォームに今あるもの。リポジトリから自動生成しています。Tanrei の作り方5 つのプラットフォームを正直に保つ、仕様起点のワークフロー。