你的垂直居中有問題？我竟沒法反駁 🤦🏻♂️

前言

咱們日常實現的垂直居中不是真正的垂直居中？何出此言！不少時候，每每本身明明正確的實現了垂直居中，可是 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」。爲何要這樣作呢？目的就是爲了使文本框看起來均勻 www.w3.org/TR/CSS1/#th…。

」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 屬性相關草案（還沒有成爲規範）

Name:	leading-trim
Value:	normal | start | end | both
Initial:	normal
Applies to:	block containers and inline boxes
Inherited:	no
Percentages:	N/A
Computed value:	the specified keyword
Canonical order:	per grammar
Animation type:	discrete

Name:	text-edge
Value:	leading | [ text | cap | ex | ideographic | ideographic-ink ] [ text | alphabetic | ideographic | ideographic-ink ]?
Initial:	leading
Applies to:	inline boxes
Inherited:	yes
Percentages:	N/A
Computed value:	the specified keyword
Canonical order:	per grammar
Animation type:	discrete

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

更多優質內容，佛系關注公衆號：[前端鐵蛋]