中文竖排应选 vertical-rl,因其符合传统从右向左阅读习惯、标点直立自然、兼容性好;vertical-lr 仅适用于特殊场景,且需配合 text-orientation: mixed 等调整字符朝向,否则易出现标点错位、数字倒置等问题。

vertical-lr 和 vertical-rl 到底该选哪个
取决于文字阅读方向和浏览器默认行为,不是“哪个更高级”,而是“哪个符合你的排版逻辑”。中文传统竖排从右向左(vertical-rl),日文也常用;而 vertical-lr 是从左向右竖排,适合部分少数民族文字或特殊设计需求,但现代网页中极少用。
常见错误是直接写 writing-mode: vertical-lr 后发现标点位置错乱、数字倒置——因为 CSS 的 text-orientation 和 unicode-bidi 会联动影响。比如中文句号「。」在 vertical-lr 下默认会横过来,而 vertical-rl 下保持直立更自然。
-
vertical-rl更贴近中文出版习惯,兼容性好(Chrome 48+、Firefox 41+、Safari 12.1+) - 若强制用
vertical-lr,需额外加text-orientation: mixed控制字符朝向 - IE 完全不支持
writing-mode的垂直值,只认旧语法-ms-writing-mode: tb-rl(已废弃)
text-orientation 怎么配合 writing-mode 用才不翻车
text-orientation 决定单个字符的旋转方式,它和 writing-mode 是搭档关系,不是可选项。不设的话,浏览器按默认规则处理:CJK 字符直立,拉丁字母/数字自动顺时针旋转 90°,但标点(如括号、引号)可能方向混乱。
典型现象:竖排段落里英文单词歪着,中文引号「」变成横的「"」状,或者数字 123 看起来像在“躺平”。
立即学习“前端免费学习笔记(深入)”;
- 中文竖排推荐
text-orientation: upright:所有字符直立,包括英文字母和数字(适合标题、强调短语) - 常规正文用
text-orientation: mixed:CJK 字直立,拉丁字母/数字自动旋转,标点依上下文调整(最稳妥) - 避免用
text-orientation: sideways:整行当一个块旋转,失去竖排意义 - 注意 Safari 对
upright支持不稳定,某些版本下仍会微调小写字母角度
line-height 和 padding 在 vertical-rl 下为什么“变矮了”
因为 writing-mode: vertical-rl 把行内方向(inline-axis)变成了垂直方向,原本控制“行高”的 line-height 实际控制的是“列宽”,而 padding-top/padding-bottom 变成了左右内边距——视觉上就像元素突然被压扁、留白错位。
你调了半天 line-height: 2 没反应?不是失效,是它现在决定的是字与字之间的横向间距(即列间距),不是你眼睛看到的“行距”。
- 想控制字与字之间的垂直距离(即传统“行距”),该调
line-height,但它数值含义已变为“相对于 font-size 的垂直空间倍数” -
padding-top在vertical-rl下实际作用于右边缘,padding-left才是顶部留白 - 用
margin-block-start/margin-block-end替代margin-top/margin-bottom,能真正对应逻辑方向 - Flex/Grid 布局中,
align-items和justify-content的主轴也会随writing-mode切换,别硬套水平布局经验
font-feature-settings 和竖排标点对齐怎么搞
纯靠 writing-mode 不足以实现出版级竖排,尤其标点悬挂、避头尾、全角标点居中等细节,得靠 OpenType 特性。比如中文句号「。」在竖排时应略向下偏移以视觉居中,但默认不会动。
常见表现:竖排文本里冒号「:」、顿号「、」明显偏上,引号「『』」贴边难看,破折号「——」断成两截。
- 启用竖排优化特性:
font-feature-settings: "vert", "vkrn"(vert启用竖排字形,vkrn启用竖排字距) - 不是所有字体都支持
vert表,思源黑体、Noto Sans CJK、霞鹜文楷等开源字体有较完整覆盖 - WebFont 加载时加
font-display: optional避免回退到无 vert 特性的系统字体 - 注意
font-feature-settings优先级高于font-variant-east-asian,后者仅控制比例(proportional-width/tabular-width)
writing-mode,而是后续所有盒模型、排版流、字体特性的连锁响应——它们不会自动“跟着转过来”。










