前言
咱们平时实现的垂直居中不是真正的垂直居中？何出此言！很多时候，往往本人明明正确的实现了垂直居中，然而 UI/UX 仍旧说你的垂直居中有问题，而后本人认真一看的确如同在视觉效果上存在一些偏差，然而认真看本人实现的垂直居中代码却丝毫没有问题。明天咱们就探讨一下这个乏味问题的由来、解决方案以及文字排版的将来。
Github ????
发现问题
垂直居中的形式有很多种，这里咱们在父级元素应用 display:flex;align-items:center 属性对子元素进行垂直居中，如下图：
仿佛这个垂直居中曾经十分完满了，然而你却收到了来自 UI/UX 的反馈和质疑
UI/UX：咦？你这垂直居中有问题~????
开发：哪里有问题，代码齐全没有问题啊~
UI/UX：不信你本人看，文字的上半边空白局部比下半边多了 1px
开发：还真是…????究竟是逃不过设计的眼睛啊~
而咱们真正想要成果是上面这样的
初探问题
仔细的小伙伴，马上就会发现啊，罪魁祸首就是文本的 line-height 这个属性。那咱们当初用 <p> 蕴含三个不同 font-family 的 <span> 失去了下图这样的成果，对 font-size 雷同的 font-family 不同的文本元素会产生具备不同高度。
问题找到了，导致垂直居中只是近似垂直居中的根本原因就是 line-height！在规范的文本框中，实际上文本上方和下方总是会有多余的空间，默认行高保留的多余空间会导致文本不总是在文本框中居中。因而，咱们实现的垂直居中会存在不合乎预期的状况，line-height 越大，问题就会越显著。同时，不同的字体，默认的 line-height 也会不同，因而，在字体大小，行高和文本框地位不变的状况下，更改字体也会导致文本的对齐后果。
???? 这个问题就到此为止了吗？不，咱们还不晓得 line-height 为什么是这样的，以及为什么要这样。????????♂️
追根溯源
大概140年前，印刷术依然应用单个引线盒手动设置字体。在印刷时，为了使文本更具可读性，排字机将铅条（leading）插入空格线。因而，打印的文字高度加上铅条的高度的总和就是总行高。
80 年代晚期的图形设计软件保留了雷同的传统，人们能够间接增加底部 leading 来管制基线之间的间距，同时也导致 line height 的减少。其他软件则让人们能够在间接调整行高。例如，在 1990 年公布的 Photoshop 的第一个版本中，用户能够定义 leading 的值，而后将其增加到字体大小中。许多工具也开始两个基线之间的间隔叫做 line-height 。
1989 年，当 Bert Bos 和 HåkonWium Lie 起草 CSS 的第一个提案时，起初他们依然遵循印刷世界的“旧”形式。然而很快，他们将决定做出合乎逻辑的又是根本性的扭转，将 leading 一分为二，并将其放在每行的上方和下方，称其为 “half-leading”。为什么要这样做呢？目标就是为了使文本框看起来平均（https://www.w3.org/TR/CSS1/#t…）。
”half-leading“ 十分取巧的防止了高低边框的不平均性，然而同时也带来了一些问题。字体系列中的每种字体大小都带有默认的行高。为了包容某些字符和重音符号，通常会将默认行高设置的高于其蕴含的文字。减少默认行高后再减少两个 “half-leading”，这样使得文本框变得更大了。这样一顿操作下来，就是咱们当初面临文本无奈垂直居中最基本的起因了。
多年来，Web 设计工具始终不反对半当先技术，因而，许多团队探讨了为什么屏幕设计和浏览器之间的布局差别如此之大。最重要的是，并不是每个人都晓得这种简单的技术细节，这常常导致设计师和开发人员之间容易产生一些口角????????♂️
解决方案
手动调整相干 CSS 属性
手动调整相干 CSS 属性，然而这样会呈现一系列魔幻的 margin 或者 padding 的值，同时过于随机，并且只针对特定的字体、浏览器、操作系统。很显著这不是一个很好的解决方案。
裁剪工具
EightShapes Text Crop Tool
从工具中抉择一种字体或加载自定义字体，而后应用滑块测量所需的顶部和底部裁剪。该工具会计算属性和公式，只需将生成的 SCSS，LESS 或 Stylus mixin 复制并粘贴到源代码中。
为什么只能针对一种字体，而不是所有字体都应用呢？
工具原理是通过 before 和 after 伪元素来定义负边距，这种做法在保留多行文本块中的行之间的行高的同时，删除了顶部和底部的空白。
// Top crop:
$ top-crop +（$ desired-line-height-$ line-height-crop）*（$ font-size-with-crop / 2）），0）/ $ font-size-with-crop;
//Bottom crop:
$ bottom-crop +（$ desired-line-height-$ line-height-crop）*（$ font-size-with-crop / 2）），0）/ $ font-size-with-crop;最终后果是一个混合字体，无论字体大小如何都能够工作，并且只须要无单位的行高即可执行计算。然而将 mixin 利用于其余字体时，成果却不太好。
工具实现的是将 Em Square 裁剪为字体的 baseline 和 cap height，然而，每种字体都有不同的 Em Square Definition。因而，实用于一种字体的 “magic numbers” 不肯定实用于其余字体。
新的 CSS 草案
很早开始就有很多人碰到了相似的问题，并且向 W3C 进行了反馈，咱们不是第一个遇见这个问题的人。
为修复 CSS 文本布局相干问题，Leading-trim 成为了 CSS 内联布局草案的一部分
h1 {
text-edge: cap alphabetic;
leading-trim: both;
}借助 leading-trim，最终能够解决在网站上看到的所有神秘的对齐问题。能够在不毁坏设计用意的状况下更换字体。
以下是是 leading-trim 属性相干草案（尚未成为标准）
Ref
Leading-Trim: The Future of Digital Typesetting
The 4px baseline grid — the present
Getting to the bottom of line height in Figma
The Thing With Leading in CSS
Intro to Font Metrics
Deep dive CSS: font metrics, line-height and vertical-align
CSS Inline Layout Module Level 3
Cropping Away Negative Impacts of Line Height
css-inline Leading control at start/end of block #3240
发表回复