mcpField
M
modular-scale-typography

modular-scale-typography

github.com/dembrandt设计与 UI174904 次安装1 周前更新
代码仓库

关于 modular-scale-typography

面向设计师和前端开发者的排版指南,介绍如何用基准字号与比例构建模块化字体阶梯,并涵盖屏幕阅读、字距和换行等实践。

主要功能

  1. 01用基准字号和比例生成字体阶梯
  2. 02将字号映射为 CSS 与 Tailwind 令牌
  3. 03按页面场景选择字号范围
  4. 04规范字距、字重与数字对齐
  5. 05用换行规则和布局处理溢出

适用场景

  1. 01为产品界面建立一致的字号层级
  2. 02将字体阶梯配置到 CSS 或 Tailwind
  3. 03检查小字号文本的可读性
  4. 04修正标题、段落和标签的换行

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/dembrandt/dembrandt-skills --skill modular-scale-typography

安装后在 Claude Code 中输入/modular-scale-typography确认已加载。

详细介绍

模块化比例排版

当所有字号都通过一个统一的数学比例相互关联时,排版会显得协调一致。如果没有比例,字号就会被随意选定,结果看起来杂乱无章——标题之间的对比不够明显,正文与说明文字的字号过于接近,标签也会与内容混在一起。

什么是模块化比例

模块化比例从一个基准字号开始,通过乘以或除以一个比例,生成系统中的所有字号。

size(n) = base × ratio^n

因此,每个字号都是与基准字号之间经过精心设计的变化,而不是随意猜测。

选择比例

比例名称感受适用场景
1.067小二度非常紧凑密集数据 UI、仪表板
1.125大二度微妙长篇阅读、编辑出版
1.200小三度均衡大多数 UI 应用
1.250大三度层次分明营销、落地页
1.333完全四度对比强烈展示页、主视觉区域
1.414增四度戏剧化作品集、品牌设计
1.500完全五度极具戏剧性谨慎使用

默认建议: 1.25(大三度)——各级之间有足够的对比,显得经过精心设计,但又不会过于夸张。

生成比例尺

还原现有比例尺,不要手动逆向推导(dembrandt engine,可选)。 如果品牌已有线上字体,get_typography 会返回从实时 DOM 计算出的实际字号、字重和行高——先据此推断底层比例,再用下面的方法将其规范化,而不是猜测原本想要使用哪些字号。参见 extract-design。

从 base = 16px、比例 1.25 开始:

步长公式数值四舍五入用途
-216 ÷ 1.25²10.24px10px说明文字、label-xs
-116 ÷ 1.2512.80px13px标签、小号
01616px16px正文(基准)
+116 × 1.2520px20px正文-lg、导语
+216 × 1.25²25px25pxH4
+316 × 1.25³31.25px31pxH3
+416 × 1.25⁴39.06px39pxH2
+516 × 1.25⁵48.83px49pxH1
+616 × 1.25⁶61.04px61px展示

将数值四舍五入到整数像素或 rem 即可——比例体现了设计意图,像素值的精确取整没有问题。

设计令牌(CSS 自定义属性)

:root {
  --text-xs:   0.625rem;  /* 10px  — caption */
  --text-sm:   0.813rem;  /* 13px  — label   */
  --text-base: 1rem;      /* 16px  — body    */
  --text-lg:   1.25rem;   /* 20px  — lead    */
  --text-xl:   1.563rem;  /* 25px  — h4      */
  --text-2xl:  1.938rem;  /* 31px  — h3      */
  --text-3xl:  2.438rem;  /* 39px  — h2      */
  --text-4xl:  3.063rem;  /* 49px  — h1      */
  --text-5xl:  3.813rem;  /* 61px  — display */
}

Tailwind 配置

// tailwind.config.js
fontSize: {
  'xs':   ['0.625rem', { lineHeight: '1rem' }],
  'sm':   ['0.813rem', { lineHeight: '1.25rem' }],
  'base': ['1rem',     { lineHeight: '1.5rem' }],
  'lg':   ['1.25rem',  { lineHeight: '1.75rem' }],
  'xl':   ['1.563rem', { lineHeight: '2rem' }],
  '2xl':  ['1.938rem', { lineHeight: '2.25rem' }],
  '3xl':  ['2.438rem', { lineHeight: '2.5rem' }],
  '4xl':  ['3.063rem', { lineHeight: '1.1' }],
  '5xl':  ['3.813rem', { lineHeight: '1' }],
}

为什么这样能让排版显得协调一致

没有比例时,设计师和开发者会凭直觉或习惯选择字号(14px、16px、18px、24px、32px、48px)。这些字号会让人隐约觉得不对劲,因为间隔不均匀——从 14 到 16 的变化很小,从 32 到 48 的变化很大,而且它们之间没有共同的逻辑。即使读者说不出原因,也能察觉这种不一致。

采用模块化比例后,每个字号级别的变化都具有相同的视觉分量。层次关系一目了然,因为每个级别与相邻级别之间都是成比例的变化,而非随意设置的间隔。

最小字号

正文基准字号:至少 16px。 浏览器默认值如此设定自有道理:低于这个阈值,阅读舒适度会明显下降,尤其是在屏幕上。

  • 16px — 标准正文字号,默认基准
  • 14px — 可少量用于次要 UI 文本(标签、说明文字、元数据)
  • 低于 14px — 不要使用。即使在高 DPI 屏幕上,低于 14px 的文本也无法满足 WCAG 对普通文本的对比度要求,并会造成无障碍问题。

在模块化比例尺中,这意味着基准(step 0)应为 16px,负数级别(step -1、step -2)只用于真正的次要内容,绝不能用于正文或主要标签。

1% 经验法则。 小于 16px 的文本应是罕见的例外(目标:占页面内容约 1% 以下,且绝不能小于 14px)。没人会逐字统计,因此可按用途来判断:

  • 可以小于 16px — 仅限一份固定白名单中的快速浏览类用途:时间戳、说明文字、表格元数据、辅助文本、细则、徽章标签。
  • 绝不可以 — 正文、主要标签、列表项标题,以及任何需要实际阅读才能完成任务的内容。

检查方法:浏览一个屏幕,统计不同的小于 16px 的用途。白名单中有两三种很合适;达到五种或更多,或出现任何需要阅读的内容,都说明字号缩得过小。这是布局密度问题,不是字体问题:减少显示的内容,而不是缩小字号来适应。

字体渲染细节

字号和比例决定结构;这些细节决定字体在屏幕上是否真正易读。

字间距
  • 正文和默认文本: 字间距保持为 0。在连续文本中增加字间距会拖慢阅读速度,也会让字体显得松散。
  • 大写字母和小字号标签: 这是字间距能起到帮助的唯一场景,因为大写字母在视觉上较为紧密。上限为 0.04em,且仅在标签确实需要留白时使用。
  • 规律:小写正文的字间距为零,大写标签最多稍微增加(≤ 0.04em),不要一概而论。字间距过大会显得过时,而非高级。
全大写标签周围的视觉间距

全大写或没有下伸部的标签,其行框底部会留白。检查器中,上下边距相同,但视觉上下面的间距会显得更大。应从可见字形而非文本框测量间距,并将下方间距缩小几像素,直到上下看起来相等。这就是人们觉得间距“不对”却说不清原因的情况。

深色背景上的字重

深色背景上的浅色文本在视觉上会显得更细——这是一种光晕效应,明亮的字体会向暗色背景中扩散。应将字重提高一级来补偿:浅色背景上使用常规字重(400)时,深色背景上对应的文本应使用中等或半粗体。这样可确保不同模式下的感知字重一致,避免深色模式中的文本显得单薄。

等宽字体

等宽字体适用于需要字符对齐的技术内容,例如代码、ID、数字表格和差异比较。不要将其用作默认 UI 字体,并避免将等宽字体与全大写搭配使用(等宽字符加上高大的大写字母很难快速浏览)。

原位变化的数字

计数器、倒计时、实时更新的价格、数字列——比例数字的宽度各不相同,因此每次更新时文本都会左右抖动,列也无法对齐。在数字更新或纵向排列的地方使用等宽数字;正文则保留比例数字,因为等宽数字会显得疏松。

.stat, .price, td.numeric { font-variant-numeric: tabular-nums; }
换行位置

标题是控制换行的位置。text-wrap: balance 能让较短标题的行宽更均衡,避免最后一行只剩一个词;text-wrap: pretty 只会避免孤行,用在段落上开销更低。浏览器会限制均衡排版的行数,因此它适用于标题,不适用于正文。

在样式表中一次性为同类元素设置好。把 text-balance 工具类零散地加在某个组件上,只对该组件有效;下一个人构建页面时,它就会悄无声息地失效。

h1, h2, h3, h4, h5, h6,
figcaption, blockquote, dt { text-wrap: balance; }

p, li, dd { text-wrap: pretty; }

三种浏览器都支持均衡排版;只有 Chrome 和 Safari 支持 pretty。这两种方式都不能作为关键依赖。均衡排版最多处理 6 行(Chrome)或 10 行(Firefox),所以绝不要用于正文。标题、提示、工具提示、说明文字和换行按钮也会出现孤词:将它们按类名加入同一条规则。均衡排版改变的是换行位置,不是文本框,因此应先用 max-width 和 ch 为左对齐标题限制宽度。

绝不要为了消除孤行而手动用 <br> 换行。它只会在某个视口宽度下恰好正确,在其他宽度下都会出错。按组件调整换行是设计师提出的特殊需求,不应作为默认做法。

用不换行空格将词语与后面的内容绑定在一起,例如 10&nbsp;kg、Figure&nbsp;3,以及姓名与头衔。单位独自落到下一行时,看起来就像拼写错误。

文本超出预留空间

text-wrap: balance 能修正标题不自然的换行,但无法解决文本本身对于预留空间来说太长的问题。在这种情况下使用它,只会掩盖问题,让它在某个视口宽度下消失,却在下一个视口宽度下再次出现。

当一行只剩一个孤词,或说明文字在标题旁换成三行时,只有三种合适的修正方法:

  1. 缩短文本。 通常这是正确的做法。为标签预留的空间,本就不是用来放句子的。
  2. 将字号缩小一级。 标题旁的辅助文本应比标题小一到两级,而不是与标题同大。
  3. 调整父级布局。 当文本已经无法再缩短而不影响含义时,问题出在容器。可以在该断点减少网格列数、加宽列、让文本独占一行或调整位置。在宽度为 1280px 的视口中,横排 6 个卡片时,每个卡片只有约 190px,再怎么改写也无法让一个数字、一个标签和一段说明同时放得下;同样的宽度下改为横排 3 个就可以。

顺序很重要。只有前两种方法都行不通时,才调整布局:如果为了挽救本应缩短为三个词的句子而加宽容器,同一个问题就会出现在下一个断点。

以下做法不算修正:放任不管,或不断微调容器,直到内容刚好适合当前查看的宽度。

图例不是句子。 “柱形高度代表总数,填充部分代表已完成数量”这句话有 13 个词,却要塞进只适合放 3 个词的标题区域。它会换行,还会让最后一行只剩一个孤词。两个色块各配一个词,表达的含义相同,也不会出现难看的换行:

■ completed   □ total

轴标签、表格标题、标签文本,以及所有放在较大元素旁边的说明文字也都适用同样的原则。如果确实需要用一句话来解释,就应将它放在元素下方,而不是旁边。

一个槽位中的两行

带有下方说明的标签其实承担了两项工作,因此视觉上也应该像两项工作。若两行的字号、字重和颜色相同,它们就会合并成一块灰色,读起来什么都不像:


<div class="w-36">
  <div class="text-sm font-medium text-gray-500 truncate">Imported</div>
  <div class="text-sm font-medium text-gray-500 truncate">rows without a matching account are skipped</div>
</div>

通过字重和墨色而非字号将它们区分开来——这也是上文“不同的工作应拉开层次”的例外:两行都已经接近 14px 的下限,因此把第二行再缩小一级就会低于最低值;而在这种字号下,缩小两级几乎也看不出来。主文本用半粗体,次要文本用中等字重和柔和的颜色就足够了,而柔和颜色本身也需要设定下限:如果将调色板中最淡但仍可读的颜色与最轻的字重(400)搭配,即使单看颜色时通过了 WCAG 对比度要求,文字仍会难以辨认,因为对比度计算只考虑颜色,不考虑笔画粗细。凡是使用柔和/次要文本令牌的地方,都应将最低字重设为 500,而不只是这里。

不要截断说明。 名称被截断后仍能辨认,因为读者可以通过开头几个字符认出它。句子则不然:被截掉的部分往往承载着含义;把它移到 title 属性中,会让触屏用户、键盘用户以及不会想到悬停查看的人都看不到——因此,下文“行截断”中允许使用 title 属性的例外,仅适用于用户无需据此采取行动的辅助描述,绝不适用于承载所附内容含义的说明。截断标识符。让说明换行、缩短说明,或为列增加空间。

按页面上下文划分的字号阶梯

落地页和营销界面适合使用大而富有表现力的字体——标题字号提升 +4 到 +6 级,可以营造戏剧性效果和品牌感。

功能页和应用 UI应采用更克制的范围——标题提升 +2 到 +3 级,正文字号则为第 0 级。在功能性 UI 中使用过大的标题会分散对内容的注意力,并让布局显得失衡。

应根据界面的用途,而不只是品牌,来匹配比例和字号的使用方式。

每个视图最多四级。 在同一个视图和上下文中,无论是面板、叠层还是页面区域,字号阶梯都不应超过四级。四级并非审美上的界限,而是单个视图所需的文本角色数量:标题、正文、标签、元数据。上限由这些角色决定,因此,如果一个视图看起来需要第五级字号,实际上它承担了一个尚未命名的第五种角色;将其命名后,通常就会发现它属于另一个视图,或属于布局尚未划分出来的一组内容。每增加一种字号,也是在声明一种层级关系;超过四级后,视线便无法再区分它们的高低,于是相邻字号看起来像错误,而非层级。这与下文“三则规则”对标题层级的论述相同;此处讨论的是屏幕上的文本字号。即使视图中只有一个标题层级,也可能触及四级字号的上限。

标题层级与页面复杂度

成功的标题字号阶梯不只依靠字号大小来区分层级,也会尊重页面的认知负荷限制。

区分方式

如果标题之间只有细微的字号差异,扫一眼时就很难区分。可以使用以下方式建立更明确的层级:

  • 大小写: 对较小的低层级标题(H4–H5)使用大写(text-transform: uppercase),无需放大字号也能增强其视觉分量。
  • 字母间距: 对大写或粗体标题,最多只增加一点点 letter-spacing(≤ 0.04em)——而且仅在标题确实需要留白时才使用。保持克制;过度拉开字距会显得过时,而非高档。
  • 颜色: 使用品牌主色或略柔和的灰色来区分次级标题,使其与主黑色/深灰色文本有所区别。
  • 样式: 对补充性标题或元数据式标题使用斜体或低调的下划线。
三层规则(H1–H3)

大多数设计良好的页面只需要 三个层级的标题(H1、H2、H3)。

  • 简单明了: H1–H3 足以涵盖页面标题、章节标题和小节标题。
  • H4–H6 暴露的是结构复杂问题,而非排版问题。 如果你发现自己需要用到 H4、H5 或 H6,说明页面试图承载过多内容。增加更小的标题层级只会掩盖症状。应将其视为一个信号,并从结构上做出调整:
    • 拆分 — 页面实际上包含两个功能,或一个页内子页面。将内容拆分到多个页面,或采用模块化结构(侧边栏、标签页、主从布局)。
    • 移除 — 深层章节可能根本没有保留的必要。
    • 简化 — 扁平化子层级,使其符合 H1–H3 的范围。
    • 用展开/折叠元素隐藏 — 将次要内容放入模态框、手风琴或面板中(参见 information-architecture)。

需要 6 级标题的页面,大多数用户都会读到一半就放弃。

阅读舒适度与编辑模式

排版不只是字号的问题,也关乎内容的节奏和结构。

行长(版心宽度)

为获得最佳阅读体验,正文每行应保持在 45–75 个字符(约 500–700px)。

  • 行太长会让读者难以找到下一行的起点。
  • 行太短会打断阅读节奏,并产生令人分心的参差感。
版心宽度、行距和字号相互影响

行长、行高(行距)和字号并非三个独立的调节项,而是一个整体系统。这是基础排版原则(Bringhurst 的 The Elements of Typographic Style),已在数字平台上反复得到验证,也是 Material 和 Apple HIG 字体比例中行高阶梯的基础。

版心越宽,眼睛所需的行距越大,才能从一行末尾顺畅地移回下一行开头。在窄栏中读起来刚好的紧凑行高,用在宽栏中会让人感到疲惫。

版心宽度建议的正文行高
窄(约 45ch)1.4
舒适(55–66ch)1.5
宽(约 75ch)1.6–1.7

实用规则:

  • 正文: 行高设为 1.4–1.7,多行文本绝不能低于 1.4。WCAG SC 1.4.12 还要求,当用户将行高调整到 至少 1.5 时,文本仍须保持可读,因此设计时要预留足够空间。
  • 标题: 大字号需要更小的行距——字号越大,行高越应收紧至 1.1–1.25,否则行与行会逐渐分开,不再被视为一个整体。行距与字号成反比。
  • 解决根因,而非表象: 如果正文读起来吃力,可以增大行距或缩窄版心,不要只缩小字号。这三者相互影响。
行数限制

在内容长度不可预测的网格、卡片或列表中,限制文本行数,以保持视觉节奏一致,并让卡片高度相同。将描述限制为 2–3 行,让同一行中的所有卡片保持相同高度。

多行限制。 将标准 line-clamp 与 -webkit- 回退方案配合使用——要完整支持各浏览器,仍需使用旧式 -webkit-box 写法,因此两者都要保留。

.card-description {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  line-clamp: 3;
  overflow: hidden;
}

单行限制。 对于绝不能换行的标题和标签,请改用省略号模式。

.card-title {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

在 flex 或 grid 中。 如果项目无法收缩到小于其内容宽度,文本截断就会悄无声息地失效。为受限的子元素添加 min-width: 0(或 min-inline-size: 0),使其可以收窄。

无障碍——切勿丢失内容。 行数限制只会在视觉上隐藏文本;完整字符串仍保留在 DOM 中,屏幕阅读器也会完整读出,但视力正常的用户将无法再看到它。务必提供查看剩余内容的途径:

  • 提供包含完整文本的 title 属性(或无障碍提示框),或
  • 链接到详细视图或“阅读更多”页面,展示完整内容。

此补充途径适用于用户无需据此采取行动的辅助性描述。如果被截断的部分会影响解释的含义,则不适用——请参阅上文的“不要截断解释”。

切勿限制用户必须阅读才能采取行动的文本(价格、错误信息、法律文案、主要说明)——仅对截断不会造成问题的辅助性描述限制行数。

固定尺寸页面。 在使用 overflow: hidden 的固定页面文档中(打印、PDF、A4 预览),渲染器根据测量内容填满页面后,再追加到该页面的文本会落在可视区域下方,完全不会打印在任何页面上,也不会报错。生成或撰写的文案应单独占一页,并放在页脚上方的边界框内;行数限制则应在浏览器中应用,因为换行也在那里发生。字符数预算无法预测页面在哪里结束;只有布局引擎才知道。

编辑层级

采用明确的字体角色来提供上下文,引导用户了解内容:

角色视觉样式用途
前置标题(眉题)小号(12–13px),通常全大写,字距微妙(≤ 0.04em),颜色柔和提供上下文或类别信息,同时不分散用户对主标题的注意力
标题大号、粗体,模块化比例阶跃 +3 至 +5主要吸引点或主题
导语(引导文本)大于正文(阶跃 +1),略粗或行高略大概述核心价值,衔接标题和正文
正文基础字号(16px),常规字重,舒适的行高(1.5)主要阅读内容
措辞与语气
  • 使用主动语态。 用“开始”代替“轻松开始并不难。”
  • 简洁有力。 使用清晰、具体且能体现成果的标签。
  • 保持一致。 在整个产品中,对相同操作使用相同术语。

响应式字号比例

在较小视口上,应通过收紧比例来压缩字号阶梯,而不是手动覆盖单个字号。底部(正文、标签)保持稳定——可读性有明确的最低限度。顶部(H1、展示标题)则显著缩小。比例变化会让每个标题级别按比例缩放,因此层级关系仍保持协调。

规则: 桌面端使用较宽的比例(更有张力),移动端使用较紧的比例(更克制)。基础字号保持不变,顶部字号让步缩小。

  • 桌面端 → 较宽的比例(例如 1.25–1.333):H1 与正文之间对比鲜明
  • 平板端 → 适中的比例(例如 1.200):字号阶梯有所收紧
  • 移动端 → 较紧的比例(例如 1.125):H1 明显变小,正文保持不变

切勿从字号阶梯的底部开始缩小。16px 的正文已经是下限——压缩始终应从顶部开始。

使用 clamp() 实现流式字号

与其在固定断点处切换字号,不如让最大字号在下限和上限之间平滑缩放,使用 CSS clamp(MIN, PREFERRED, MAX) 即可。中间的视口相对值负责缩放;下限和上限则确保字号不会过小或过大。

:root {
  --text-body: 1rem;                         /* the floor stays fixed */
  --text-h1: clamp(2rem, 1.5rem + 3vw, 3.5rem);
}
  • MIN 是移动端字号,MAX 是桌面端字号——与阶梯字号体系采用相同的下限/上限思路,只是通过插值实现。
  • 将 clamp() 用于字号体系的顶部(标题、展示文字)。正文和标签保持固定字号——可读性有硬性下限,因此下限不得变化。
  • 在首选值中加入 rem 项(例如 1.5rem + 3vw,而不是单独使用 3vw),这样文本仍会响应用户缩放和根字号变化——纯 vw 值会破坏缩放无障碍性。
相邻流式字号可能会趋于相同

如果设计系统将多个较小字号也设为流式字号(如 text-fluid-xs、text-fluid-sm 等),而不是保持固定,两个相邻的限制字号就不一定能在整个视口范围内始终保持差距。每个 clamp() 都会根据自身的下限和上限,沿各自的斜率进行插值,因此,两个具有不同 vw 系数的字号可能会在某个中间宽度处变得很接近,甚至得到完全相同的计算值,即使它们在最窄和最宽视口下看起来间距合理。只检查两个端点会掩盖这个问题:重要的是整个范围内的最小间距,而不是任一端点的间距。

/* Looks fine at 375px and 1440px. At ~860px both resolve to ~14.9px. */
--text-fluid-xs: clamp(0.75rem, 0.65rem + 0.4vw, 0.875rem);
--text-fluid-sm: clamp(0.8125rem, 0.7rem + 0.45vw, 0.9375rem);
  • 不要让相邻的小字号都变成流式字号。 这与上文“正文和标签保持固定字号”的规则相同,只是针对实际违反规则的情况:紧邻正文的说明文字,或彼此相邻的两个标签字号,应使用固定字号,正是为了避免它们之间的差距缩小。将 clamp() 留给字号体系的顶部,因为同一行上通常不会有一个标题与另一种字号紧挨着。
  • 如果较小字号必须保持流式, 请检查整个范围内的间距,而不仅是 MIN 和 MAX:在几个中间宽度下采样这两个字号的计算值(或绘制两个 clamp() 表达式),并确认它们在任何中间宽度都不会交叉,也不会缩小到相差不到几 px,而不只是检查碰巧选中的断点。
  • 优先使用相同的系数。 让相邻流式字号使用成比例相关的 vw 系数(例如,根据相同的模块比率推导)可以让它们的曲线保持平行,避免各自选取的斜率彼此交叉。

所有阅读文本优先使用 16px

提示、元数据、说明文字和 HUD 标签也需要阅读,因此默认与正文一样使用 16px。优先通过字重、颜色和间距来构建层次;只有这些方式都用尽后,才向下调整字号。次要文本不得小于 14px。每个低于基础字号的字号都是有意为之的例外,而不是所有所谓次要文本的默认值。

审查清单

  • 是否所有字号都由一个基础字号和比例推导而来?
  • 基础字号是否为 16px 或更大?
  • 14px 是否仅用于次要文本/元数据,而从不用于正文?
  • UI 中是否没有任何小于 14px 的文本?
  • 统计屏幕上不同的 16px 以下文本角色后,是否只有少数几种(≤3),且都属于次要文本白名单——绝不用于阅读内容?
  • 正文的字间距是否为 0,大写标签的字距是否不超过 0.04em,且仅在需要留白时使用?
  • 浅色深色文本是否使用稍粗的字重,以补偿光晕效应?
  • 全大写标签周围的间距是否根据可见字形而非行框来平衡?
  • 等宽字体是否仅用于技术内容,从不作为默认字体或与大写字母搭配使用?
  • 正文与最大标题之间是否至少有 3–4 个不同的字号级别?
  • 相邻级别(例如正文与标签)是否有足够差异,能让人一眼分辨?
  • 字号 token 是否按角色(--text-body、--text-h1)或级别(--text-base、--text-2xl)命名,而非按原始像素值命名?
  • 所选比例是否适合 UI 密度?(数据密集型 UI 使用较紧凑的比例,营销页面使用较宽松的比例)
  • 正文行长是否在 45–75 个字符之间?
  • 标题旁的辅助文本是否会换行,或让单个词落在单独一行?应缩短文本、调低字号级别,或为其留出空间;绝不要让这种情况发生。
  • 是否只设置了一次 text-wrap: balance,用于标题和短文案类,并对正文关闭?
  • 图例、坐标轴标签和标签芯片文本是否写成标签,而非句子?
  • 缩短文本后仍然放不下时,是否重新考虑该断点下的列数,而不是进一步挤压文本?
  • 标签及其说明在同一位置堆叠时,是否通过字重和墨色区分,而非显示为两行完全相同的灰色文本?
  • 是否仅对标识符使用截断,而绝不截断含义会因裁切而受损的说明?
  • 正文行高是否随行长调整(窄列约为 1.4 → 宽列约为 1.6+),保持 ≥1.4,并为 WCAG 1.4.12 留出 1.5 的覆盖空间?
  • 标题字号增大时,行高是否收紧(约 1.1–1.25),以确保大号字体仍作为一个整体阅读?
  • 是否使用行数限制来保持网格/卡片布局一致?
  • 被限制行数的文本是否仍可查看完整内容(通过 title/工具提示或详情视图),且必读内容从不受行数限制?
  • 如果使用流式字号(clamp()),是否仅应用于字号级别的顶部,并使用基于 rem 的首选项,以确保缩放仍然有效?
  • 如果两个相邻级别都使用流式字号(例如 xs/sm),它们在整个视口范围内是否始终明显不同,而不只是在 MIN/MAX 极值处不同?
  • 是否使用前置标题和导语等编辑性文本角色来提升可扫读性?
  • 标题是否通过字号以外的方式(例如颜色、大小写、间距)加以区分?
  • 是否尽可能将每个视图中的标题层级限制在 H1–H3?
  • 阅读文本(包括提示和元数据)是否默认采用 16px,优先通过字重和颜色而非字号来体现层级,且没有任何文本小于 14px?

常见反模式

反模式问题修正方法
相邻字号使用 14、15、16、17px 等大小级差太小,难以区分层级至少使用 1.125 的比例,让每一级都能清晰感知
使用毫无关联的任意字号(13、18、27、36px)没有内在逻辑,层级显得随意从单一基准字号和比例重新生成
在组件中硬编码像素值,而不是使用设计令牌调整字号级别时,需要逐个查找并修改所有文件将其一次性定义为 CSS 自定义属性或设计令牌
显示标题和密集数据表格使用相同的字号级别一种比例很少能同时适用于这两种极端情况数据场景使用较紧凑的比例(1.125),营销场景使用较宽松的比例(1.25–1.333)
为正文添加字间距字体显得松散,阅读速度变慢正文字间距保持为 0;只有需要留白时,才为大写标签添加最多 0.04em
深色背景上使用常规字重的白色文字光晕效应会让文字看起来又细又弱浅色文字置于深色背景上时,字重提高一级(中等/半粗)
将等宽字体用作默认 UI 字体,或将等宽字体与全大写搭配使用难以快速浏览,显得“未经设计”仅在代码/ID/数字数据中使用等宽字体
相邻的小字号级别都分别设置独立的 clamp() 值即使 MIN/MAX 极值看起来正常,其曲线也可能在视口中部收敛或交叉将相邻的小字号/标签字号设为固定值;仅在字号级别的顶部使用 clamp()

评论

支持 Markdown