Skip to content

统一 Web UI 主题与颜色 Token 治理计划 #1197

@limityan

Description

@limityan

背景

当前 Web UI 已经具备主题预设、运行时 CSS 变量注入、组件库 token 和 generated widget theme payload 等多条主题链路,但颜色定义分散在多个层级。组件样式、运行时主题服务、静态 token、widget iframe、编辑器/终端/语法高亮等专用区域之间缺少统一的治理边界,导致主题调整、视觉一致性验证和后续维护成本持续上升。

这个 issue 是主题与颜色 token 治理的顶层规划入口,用于描述背景、问题、核心方案、风险和关键里程碑。它不用于维护逐项进度,也不用于记录具体 PR 列表。后续 PR 可以引用此 issue 作为背景,但不应使用自动关闭关键字关闭它。

核心问题

  1. 颜色字面量和 fallback 分散在大量组件文件中,同一语义角色存在多种写法,容易形成隐性的第二套色板。
  2. 静态 token、运行时 ThemeService 注入变量、generated widget payload 暴露变量之间没有完全统一的注册契约,某些 UI 形态可能依赖局部 fallback 或运行时偶然存在的变量。
  3. 近似色、重复色和历史命名 alias 混在一起,缺少判断标准。直接合并可能削弱区域边界、交互状态、状态语义、diff/git 语义或主题个性。
  4. editor、terminal、Mermaid、syntax、diff、generated widget 等专用视觉域与通用 app token 的边界不够清晰,容易在“减少色值数量”时被错误归一。
  5. 当前缺少可重复的审计工具和颜色预算约束,新增组件仍可能继续引入 raw color、局部 fallback 或未登记的 token 名称。

核心解决方案

采用分层 token 治理模型:

  • Primitive palette:承载基础 hue、neutral、alpha ramp,不直接作为普通组件的业务语义色使用。
  • App semantic token:承载背景、文本、边框、状态、交互、intent 等产品级语义,是普通 UI 的默认使用层。
  • Component token:只在通用 semantic token 无法表达组件契约时使用,例如 Flow Chat、tool card、diff/git、widget frame、editor/terminal 等。
  • Compatibility alias:保留历史命名和迁移期别名,先补齐契约再逐步迁移调用点,避免删除 fallback 后造成早期渲染、嵌入式渲染或隔离 iframe 样式丢失。
  • Exception namespace:为 editor、terminal、syntax、diff、Mermaid、theme personality 等专用色板建立明确例外空间,避免它们被错误压缩到普通 app token。

治理原则:

  • 极其相似、肉眼难以区分且语义一致的颜色可以直接合并。
  • 其他近似颜色必须有明确依据,包括语义角色、相邻显示风险、状态区分、数据含义、主题覆盖和可访问性影响。
  • 目标是减少色值数量,但不是抹平有用户理解价值的视觉差异。
  • 一个应用的色值数量应有明确上限,新增 raw color 或 component token 必须能说明语义和边界。

相关风险

  • 相邻 surface 的近似背景色被错误合并,可能导致 panel、card、input、canvas、floating overlay 等区域边界变弱。
  • hover、active、selected、focus、disabled、loading、drag-over 等状态色被合并,可能削弱交互 affordance。
  • success、warning、error、info、destructive、git/diff 等 intent 或数据语义被过度归一,可能影响用户判断。
  • 静态 token、运行时注入和 widget payload 不一致,可能在 iframe、静态渲染、早期渲染或主题切换场景下出现 UI 差异。
  • 大规模迁移 PR 容易产生 review 疲劳,导致视觉回归、contrast 回归或专用色板误迁移漏审。
  • 过早启用严格 CI 约束可能被历史债务阻塞;过晚启用约束则可能继续新增同类问题。

关键里程碑

  1. 建立颜色审计基线:统计 raw color、fallback literal、token 使用、未定义 token、重复色、近似色和高风险 surface。
  2. 明确 canonical token 契约:对齐静态 token、运行时主题注入和 generated widget payload,补齐兼容 alias。
  3. 迁移精确重复项:优先处理完全重复、格式差异、历史 alias 和明确等价 fallback,不改变用户可见视觉语义。
  4. 收敛组件 fallback:按 component-library、Flow Chat、tool card、review panel、git/diff、widget 等 surface 分批迁移。
  5. 抽取必要 component token:为高密度或专用 UI surface 建立清晰的组件级 token,而不是让组件继续携带 raw color。
  6. 审慎合并近似色:每个非完全等价合并都需要调用点、相邻关系、状态语义和视觉证据支持。
  7. 建立防回退约束:在迁移期使用 baseline-aware audit,逐步阻止新增普通组件 raw color、未登记 token 和无依据的 fallback。

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions