AI 摘要：文章深入探讨了如何利用代币（tokens）、组合（composition）和配置（configuration）来构建灵活且可扩展的多品牌设计系统。作者通过一个“卡片”组件的实例，详细演示了如何使用 CSS 自定义属性（Custom Properties）实现主题切换，如何通过插槽（slots）和局部组件（partials）实现内容的灵活定制，以及如何结合这些方法来创建高度适应不同品牌和用例的组件，最终达到减少代码重复、提高开发效率和保持系统一致性的目标。

1. 设计系统核心理念
• 系统灵活性与可扩展性：设计系统不仅要保证一致性，更要具备灵活性，以适应多品牌和多样化的使用场景。
• 三大核心要素：代币（tokens）、组合（composition）和配置（configuration）是实现组件灵活性的关键。

2. 基础卡片组件结构
• 组件需求：一个包含横幅、图片、标题、描述和按钮的简单卡片。
• 技术栈：示例使用 Vue 编写，但其原则适用于任何基于组件的设计系统，包括原生 Web Components。
• 初始代码实现：展示了卡片组件的模板、脚本和样式。

3. 使用代币（Tokens）支持多品牌/主题
• 基本修改：通过代币（变量）来支持不同品牌或主题的切换。
• CSS 自定义属性（Custom Properties）：文章以 CSS 自定义属性为例，但代币不仅限于 CSS，Design Tokens Community Group 提供了更全面的定义。
• 代码优化：将硬编码值转换为变量，提高代码可维护性和复用性。
• 主题切换实现：通过更改 CSS 变量或添加主题类来轻松切换卡片样式，无需修改组件结构。

4. 使用可组合插槽（Composable Slots）定制内容
• 解决内容多样性问题：当需要展示不同类型的内容（如列表而非描述）时，插槽提供了一种灵活的解决方案。
• 插槽（Slots）的引入：将组件中的特定区域定义为插槽，允许外部传入自定义内容。
• 示例：将描述区域替换为名为 card-details 的插槽，并展示如何传入不同的内容（如段落或列表）。
• 组织化实践：为了避免插槽内容过于随意，可以提供“预制”的子组件或局部组件（partials），作为推荐的插槽内容，以维护代码整洁和一致性。

5. 扩展配置与组合实现更深层次的定制
• 进阶应用：组合和配置不仅限于组件的某个特定区域，可以应用于更广泛的布局和样式。
• 可配置元素与可组合部分：区分通过属性（attributes）控制的可配置元素和通过插槽控制的可组合部分。
• 示例：将横幅位置设置为可配置属性，并将整个内容区域设为插槽，实现更自由的布局组合。
• 拆分局部组件：将复杂的组件拆分为更小的局部组件（如 CardMedia），提高复用性和可维护性。
• 高度适应性：通过灵活运用配置和组合，可以创建高度适应不同布局和内容需求的卡片组件。

6. 将原则付诸实践
• 核心原则总结：再次强调代币、组合和配置在构建灵活设计系统中的重要作用。
• 代币（Tokens）：集中管理设计决策，实现品牌快速切换。
• 组合（Composition）：通过插槽和局部组件提供结构化的内容扩展能力。
• 配置（Configuration）：通过属性暴露常用选项，确保组件适应性。
• 实践效益：减少重复组件、加速交付、保持系统一致性，使设计系统更具弹性。

Frontend Masters

Exploring Multi-Brand Systems with Tokens and Composability

Design systems aren’t just about keeping everything looking the same; they’re about making things flexible enough to handle whatever gets thrown at them.

AI 摘要：文章主张 <Tooltip> （提示框）组件在设计系统中不应独立存在，因为它常被误用，导致可访问性和一致性问题。作者认为应通过更高层级的组件（如带有 title 属性的 <Button>、<IconButton>、<InfoIcon> 等）来统一提示行为。这种做法能确保键盘操作可达性、用户体验一致性，并减少错误使用的可能，是“限制创造力反而带来更好设计”的典型案例。

1. 问题背景：为什么 Tooltip 容易被误用
• Tooltip 在网页中常被视为简单组件，但其实现需兼顾可访问性（Accessibility）与交互性（Interactivity）。
• 很多设计系统提供 <Tooltip> 组件，却被开发者误用或滥用。
• 根因在于这是一个抽象层级过低的组件，不易强制正确实践。

2. 键盘交互问题（Keyboard Interactivity）
• 非交互元素（如纯图标或徽章）包裹 Tooltip，导致使用键盘导航的用户无法触发提示。
• 举例：Material UI 的 <Tooltip> 示例在非交互元素上无法聚焦。
• React Aria 提供更佳方案：不为非交互元素显示 Tooltip，并通过 <Focusable> 组件确保焦点可达。

3. 用户体验一致性（Least Surprise Principle）
• Tooltip 容易出现在不合适的位置，如句中词语或无法预测的界面处。
• 缺乏一致性会让用户预期混乱、有的图标无说明、有的却多余提示。
• 结论：Tooltip 使用应可预测且统一。

4. 替代方案与系统设计（Higher-level Pattern Components）
• 不提供通用 Tooltip，而是通过更高层级组件统一规则：
• <Button> 或 <Link> 增加可选 title 属性。
• <IconButton> 强制要求 title 属性，保证含义明确。
• <InfoIcon> 明确显示“更多信息”图标，内部控制提示逻辑。
• <InfoText> 组件强调文字说明，可聚焦且视觉可区分。
• 通过这些约束可提升一致性与可访问性。

5. “限制反而带来创造力”的思考
• 限制 Tooltip 的使用让团队重新思考信息展示方式。
• 空间不足时，应改进界面而非“藏信息”。
• 设计系统的目标：减少误用、提升用户体验。

tkdodo.eu

Tooltip Components Should Not Exist

A look at why tooltip components are often the wrong abstraction in design systems, leading to accessibility issues, misuse, and inconsistent user experiences.