轉:關於垂直網格與CSS基線對其的探討

網頁設計佈局中一直比較流行網格對齊,但只是針對水平的對齊,不多或者沒有涉及垂直對齊,這篇文章很詳細的講解了垂直網格,乃至基線對其的相關,而css3中的多列布局的也使其顯得更爲重要,所以仍是頗有必要去了解學習,至少也是一種思路。 這或許是由於缺乏基線網格的理解和欣賞,更或者是由於基線網格是出了名的難以實現, 迄今爲止尚未人拿着藍圖讓它成功實現。 有些人甚至認爲基線在網絡上是多餘的,基線做爲一種排版術語和網絡上的行爲,在網絡上遵循的規則有別於用於印刷的,line-height和真正的行距之間使人沮喪的差別就是最明顯的例子。 目前,不管怎樣,讓咱們先假設基線至少在某種程度上對於來講網頁設計師是一種有用的工具。可是它究竟是什麼樣的一種工具,在咱們手上有什麼能夠自由使用的工具來實現它,而且最重要的是,這到底值不值得。css

<ignore_js_op>

       垂直網格和模式識別在數學計算和爲實現基線對齊而進行將在的輕移以前,不妨來了解其根本的本質:垂直網格。在瞭解爲何的同時,也就有了很好的準備和更大的動力來着手解決怎樣去實現基線對齊,這個有時讓人沉悶而又着迷的問題。 垂直網格,能夠簡單的理解爲涉及到結構高度和垂直排列元素之間的間距,或許更爲廣泛點來講是內邊距(padding),外邊距(margin)和行高(line-height)。正如水平網格經過一個預設的單元尺寸約束佈局而達到整齊和諧的效果同樣,垂直網格也在用戶下滾的時候經過一致的,可預測的措施提供固定結構的內容。html

<ignore_js_op>
網格不只在水平方向有用,在垂直方向一樣有用

       爲何垂直網格重要?是由於垂直網格與咱們大腦如何工做相關,也與咱們如何經過模式識別來解析周圍世界相關。即便再也不深刻這個話題(其餘比我聰明的人更適合這個任務),也能夠說模式識別允許人類大腦在模式庫中儲存類似或者相同的印象(譬如基本的形狀和顏色),並在遇到新的刺激的狀況下經過模式庫檢索來快速分析。這也是爲何咱們的閱讀的時候不去注意當個獨立的字母,反而在一瞬間便可認出整個單詞(從咱們大腦記憶當中拿出之前相同模式的實例),這一樣也是爲何咱們可以很快認出當個的字母(」A」 」B」 「C」 …),即便字體、尺寸和顏色發生變化——其基本的形狀已經存儲在咱們大腦的模式庫。
       一旦任何類型的刺激都不能匹配到你以前存儲的模式,這就會促使大腦在新的記憶中存入新的模式,這反過來須要更多的腦力消耗——而這就是結構和網格(不管是水平仍是垂直)設計的重要之處,接下來,想象一個有一致段落間距爲X的簡單佈局。在第一處分析過以後,做爲一樣的模式,你的大腦會當即認出其餘全部的相同段落。但若是相反,一樣的佈局中元素之間有着不一樣的間距,讀者的大腦要分析全部獨立的元素才能理解他們的意思。用另外一句話來講:大腦須要分析的形狀越多,它所需時間便越長。css3

<ignore_js_op>
不規則的左邊比右邊須要更多的腦力消耗

       任何不規則的形狀都會打斷先流水般涌出的模式識別(所以會浪費一部分本應該用於欣賞優秀內容的腦力活動),而一種規則的,一致的而且能夠預期的結構將會使你的設計更易讀也能理解認知你的設計。創建一種固定的基線網格即是實現它的一種很好的方法。
       此外,經過基本一個每一個垂直(和水平)間距都一致,每個元素有着預設單元尺寸的系統不只消除了上述隨意的不統一性,也使得設計師的工做更加容易,設計師只需在總框架總決定基本的結構。創建一個標準,好比,頭部下面總有兩個基線的白色間距,每一個盒子都有三個基線空間的內邊距,在咱們的佈局中增長邏輯,這不只易於設計,易於實現,更重要的是易於理解。
       如今,若是垂直網格還像一個抽象概念,基線的另外一個優勢——多列水平對齊——就顯得更容易理解。這在印刷設計中更加常見,特別是雜誌和報紙,常用多列布局,相鄰段落(或者頭部)若基線對齊的很好會令閱讀沉浸而歡快,一旦對齊的很差或者根本沒有對齊閱讀便被煩人的打斷。這種來源於基線對齊的安靜的排版展示了一種視覺自信,一個看不見支架支撐着頁內全部的元素,讓讀者潛意識的安心下來。一本左手頁每一行都對齊相對右手頁的書讓人很容易感受到信任,而相反如果根本對齊的書籍,這種信任則相對少的多。web

<ignore_js_op>
多列水平對齊

       line-height的問題
       傳統意義上,基線是指大部分字母所「坐落」其上的一條看不見的線,每條基線之間造成基本的基線網格,正如以前所討論的,基線不但造成垂直網格,並且會使相鄰列之間水平對齊。一旦定義好了基線網格,接下來要作的即是強制全部的元素對齊,以此來使得成行的文本,邊框,圖片或者盒子元素老是匹配對齊到相同的垂直結構。
       問題是,像在InDesign中可以讓你點擊按鈕(準確的開啓和關閉網格)便能輕鬆調整形狀來對齊網格的工具,對應到css中只能經過控制調整行高(line-height),內邊距(padding),外邊距(margin),大小(size)——其中任何的變更均可能會引發元素總高度的變化。瀏覽器

<ignore_js_op>
傳統的基線是大部分字母所「坐落」其上線,而且基線之間的高度即是元素的總高度。

       更糟糕的是,css中的line-height屬性並無嚴格意義上基線的概念,而且每一個成行的文本都大體處於元素總高度的中間。這就意味着基於不一樣樣式和字體的文本精確對齊(基線對齊)須要進一步手動,費時的調整和像素級的輕移。
所以,咱們如何着手開始實施css的基線?由於缺乏原生的基線語法,快速到位或者瀏覽器功能性的強迫垂直對齊,咱們留給之後的實驗。咱們先開始最基本的css方法。
       好的方法:基本的css基線
       迄今爲止,尚無造成統一的正確的方法來實現css基線,有的人只要使行高和間距遵循一套規範便已知足,其餘人則更爲製做和細緻——不管怎樣——只有每一個成行的文本都漂亮的「坐落」在基線上,圖片,邊框,盒子和其餘元素都完美的對齊相同的網格才能知足。對全部人來講的好消息是:基本的css基線真的一點都不難。經過一些預先的設計決策(和堅持),它們只須要一點點的基礎數學。
       定義你的基線,最好是從你所使用的最小文本開始,大多數是你的body文本,基於此再往上計算。在我下面的例子中,我使用14px的font-size配以22px的line-height,也就是22px是個人基線之間的高度。這樣定義的結果是全部的line-height和全部元素的總高(包括邊框、內邊距和外邊距)必須是22px的倍數,以下:網絡

h1 {
font-size: 40px;
line-height: 44px;
margin-bottom: 22px;
}
p {
font-size: 14px;
line-height: 22px;
margin-bottom: 22px;
}

       如今定義的line-height和font-size並非最優的,所以爲了可伸縮性,將其轉換爲em。如此一來,會使得代碼有點難以閱讀,可是所用的數學至關的簡單——只須要記住在更改font-size的使用從新計算line-height。app

h1 {
font-size: 2.5em; /* = 40px/16px */ line-height: 1.1em; /* = 44px/40px */ margin-bottom: 22px;
}
p {
font-size: 0.875em; /* 16px is the default em size */ line-height: 1.5714285714285714em; /* = 22px/14px */ margin-bottom: 22px;
}

       注意,在通篇我都會以px爲單位說起font-size和line-height,這樣能更加清楚的代表其「物理」大小和所給例子中的比例。然而,全部的代碼,咱們都會轉換成em。
       利用可見的網格(不少人使用png或者gif的背景圖,其餘人使用諸如Baseliner的工具),咱們能夠檢測全部樣式的對齊。在此咱們發現成行的文本並無「坐落」在基線上,相反漂浮在基線之間。在此階段這並沒什麼要小心的——咱們能夠簡單的便宜咱們的背景圖片,或者在body上放增長內邊距(padding)來修復。框架

<ignore_js_op>
一個可視的網格將對設計過程頗有幫助

       到目前爲止一切順利,但咱們的代碼仍然至關的基礎。但咱們包含更多的屬性——好比上邊框——給全部的元素,將會發生什麼?天然地,屬性值須要調整,使之合併邊框高度以後的總高度仍然是基線之間高度的倍數。工具

h1 {
border-top: 3px;
padding-top: 22px;
margin-bottom: 19px; /* 22px-3px */}
<ignore_js_op>

       注意,怎樣使得3px的border-top和19px的margin-bottom之和等於基線之間高度22px
       使用SASS或者REM
       儘管這的確不是什麼高科技,但在複雜的網站中,特別是使用相對單位的時候上述的數字相加將會是個不小的挑戰。若是你願意犧牲em的可伸縮性,堅持使用px爲單位,像SASS之類的預編譯語言能夠解決一部分麻煩。使用SASS咱們能夠將基線之間高度定義爲一個變量(在個人事例中爲$baseline),並使用一次方程去定義它的倍數。以此來使得整個過程變得很是簡單,也使得css更容易閱讀。在通常的過程當中若你想從新dinginess你的基線之間高度,你只需改動一個地方。儘管下面個人示例中使用Sass,當使用rems也是同樣的道理——只在一處定義你的基線間高度,而後再整個代碼中生效。佈局

$baseline: 22px;
.box {
padding-top: 3px;
height: $baseline*15;
}
h1 {
font-size: 40px;
line-height: $baseline*2;
margin-bottom: $baseline;
}
p {
font-size: 16px;
line-height: $baseline;
margin-bottom: $baseline;
}

       在圖片和複雜的佈局上使用JavaScript
       在簡單的文字排版佈局上使用基線網格要相對簡單點,但咱們必須保證其餘的元素相圖片也要對齊網格。對於容器,按鈕,和網頁分界線來講,經過css讓任何的單元都是基線間高度的倍數,這是一個很重要的約定。但從另外一個方面來講,圖片不多遵照這一約定,其通常爲一系列任意的高度,所以在這樣的例子中,少許的JavaScript即可以幫咱們的大忙。我不會在此深究,可是jQuery的插件Baseline.js和Matthew Wilcox關於垂直網格的文章卻是值得一看。若是你正在進行一個複雜的佈局,無妨看看FtColumnflow——一段「修復css多列布局缺陷」的代碼,它普遍使用在音樂《金融時報》的web app上,而且若是你想找一個更爲健壯的方案,它或許更加合適。
       上述基礎的方案。經過保證咱們的行高,內邊距,外邊距,高度——任何的屬性——相加和老是等於基線間高度的倍數,就能夠保證咱們整個垂直網格不受影響,這很簡單,對吧?
固然,若是接下來不繼續深刻,你也不會看這篇文章了。
       很爛的方案:任意可變式
壞消息是,大多數的設計師在受限的條件下工做,有時一個22px的基線間的高度對他們來講更像是一個使人煩惱的阻礙,而不是有用的約束。例如,遵循黃分割的規則,一個16px的段落主體部分能夠推導出26px的段頭(儘管下部段落主題可能適用高於20px的任何值,這取決於字體)。保持咱們的基線間高度爲22px,你或許會發現一個簡單的22px的基線間高度的行距太窄了以致於不能溫馨的閱讀,然而一個雙倍的基線間高度又顯得太寬了,只有在h2呈兩行顯示的狀況下才會有這樣的爭論,固然理論上能夠假設列的寬度足夠的長,這樣折行就永遠都不會發生,嗯哼,這只是理論上。

<ignore_js_op>
h2要麼小的尷尬要麼行高太大

       若是在此有一種快速到位的方法,就不會發生上述的問題,就像咱們能夠簡單的將h2不該用基線網格,看看緊隨它的短可能是不會魔術般的落到正確的位置。遺憾的,並不存在這樣可行的魔法,咱們只能實事求是的去思考找出一種解決方案。
       在文章的開始我曾推薦從你有着最小文本的line-height開始定義你的基線間的高度,就像body的文本。正如咱們所看到的,一個固定的,22px(或者你body line-height的任意值)的最小單元會使得固定字體的line-height值變得很不合適。但若是讓咱們的原始的基線間高度減半會怎樣?技術上來說咱們的body的文本就會有兩個基線間高度的line-height,但這只是紙上談兵。在大多數的示例中,這樣帶來的可變性和排版自由的結果是值得的,咱們使用黃金分割的比例來快速的定義一些h元素的大小(四捨五入,保持em值整潔),咱們能夠很容易的看到每次值得增長都會有一個合適的line-height值,例如:16px/22px ,28px/33px,40px/44px等。

h1 {
font-size: 2.5em;
line-height: 1.1em;
margin-bottom: 22px;
}
h2 {
font-size: 1.625em; /* 26px/16px */ line-height: 1.2692307692307692em; /* 33px/26px */ margin-bottom: 11px;
}
<ignore_js_op>
h1, h2, 和 p都對齊了基線網格

       醜陋的方案:偏移的方式
       在我繼續以前,我必須認可的是,下述的內容徹底是實驗性的甚至大家其中一部分人甚至會認爲它實踐起來也很糟糕。但若是你準備繼續遷就我,即便它變得醜陋也繼續閱讀。好吧,我說的醜陋是源於「代碼整潔」的觀點。或許從設計的角度來講,它可能確實很漂亮。
       基於上述的基本的方案和帶一點實用性(可選)的隨意可變得方案,如今咱們有知識和工具去改善大多數佈局的基線網格,可是對於真正基線卻沒有實現。正如前面所提到的,css中line-height計算的方式意味着字符大約處於行距的垂直中點,而不是字符的下邊緊挨着基線(先InDesign和Quark)。許多人理所應當的認爲這就這是應該的。這就是css中iine-height工做的方式,咱們無法改變。沒錯,可是咱們的眼睛並不知道css的概念。咱們的眼睛並不習慣去按照x軸中心去掃描成行的文字——它們習慣於跟隨字符的地步,基線來閱讀,而且當相鄰行錯位的時候可讀性就會變差。
       來看一下下面的額例子:

h1 {
font-size: 2.5em;
line-height: 1.1em;
margin-bottom: 22px;
}
h2 {
font-size: 1.625em; /* 26px/16px */ line-height: 1.2692307692307692em; /* 33px/26px */ margin-bottom: 11px;
}
p {
font-size: 0.875em;
line-height: 1.5714285714285714em;
margin-bottom: 11px;
}
p.intro {
font-size: 1.125em; /* 18px/16px */ line-height: 1.22222222em; /* 22px/16px */ margin-bottom: 22px;
}

       在相鄰兩列的狀況且,儘管基線已經正確的貫穿介紹段落,但介紹段落的字母的底部(下圖紅線)並無對齊和主段落對其,這正是由於字體計算以後的line-height所致使。

<ignore_js_op>
css中line-height卻是誇列並無對其

       如今到了它變醜陋的地方。爲了可以在全部列中的成行文本都對齊(固然是最重要的一點是從基線網格開始),咱們必須手動偏移樣式。一個簡單的方法是增長padding-top的值直到字符緊挨到基線,而且相應調整margin-bottom來彌補增長的值。

h1 {
font-size: 2.5em;
line-height: 1.1em;
padding-top: Xpx; /* This requires trial and error, as X depends on your font and line-height */ margin-bottom: 22px-Xpx;
}
h2 {
font-size: 1.625em; /* 26px/16px */ line-height: 1.2692307692307692em; /* 33px/26px */ padding-top: Xpx;
margin-bottom: 11px-Xpx;
}
p {
font-size: 0.875em;
line-height: 1.5714285714285714em;
padding-top: Xpx;
margin-bottom: 11px-Xpx;
}
p.intro {
font-size: 1.125em; /* 18px */ line-height: 1.22222222em; /* 22px */ padding-top: Xpx;
margin-bottom: 11px-Xpx;
}

       混亂?也許是的。確實乏味。但同時也沒有什麼能像施了魔法般的讓基線完美的對齊複雜佈局同樣使人欣喜而愉悅了。

<ignore_js_op>
全部的元素多列對齊。

       噓。若是你仍然還在閱讀,或許你要麼是受虐狂,要麼是對細節有着病態的迷戀,而對於後者,恭喜你,毫無疑問你的基線就像外牆的磚同樣牢固。
       這值得嗎?
       下面是咱們全部的。基礎css的基線,至關的簡單,只須要很少的數學和組織便可改進你的佈局。而在天平的另外一端,咱們能夠手動的調整padding和margin值來模擬像打印設計中精確的基線,這種概念無疑會讓純css主義者面帶愁容。更實在的問題固然是,手動的偏移樣式對視覺效果帶來好處是否值得。在某種狀況下,好比設計驅動的項目和微型站點中,這確實值得。
其餘狀況,大部分的狀況是,對於更爲複雜的站點(你的項目經理會絞盡腦汁想知道你爲何須要花那麼長的時間來構建初始模版)或者由數個開發者維持一樣的代碼的協做性項目,這樣確實不值得。咱們須要面對的是——咱們所談論的在某些極端的例子中不只會增長體力勞動,並且會讓代碼變得更爲負責和難以維護。在一個足夠的大的項目中甚至會影響你站點的加載時間。
可是想一想看,僅僅是幾年前,從行業領袖到黑客不多有人提倡並不討巧的「sliding doors」技術,但如今css3已經讓它變得司空見慣。使用兩個div而不是一個來實現圓角這是否值得?很顯然,對一些人來講是值得的——但其餘人認爲就是浪費時間,致使了實施的困難和語義上有缺陷的代碼。可是關鍵的一點是:若是沒有人嘗試如此勞力和代碼密集的技術,咱們可能不會有成熟語法的技術時代了。
       實驗性的,糟糕的體驗,hacks,醜陋的代碼——不管咱們怎樣稱呼它——它已經推出了,而且將會繼續推出,咱們的語法會改善,咱們將使用新的工具來建立和發佈下一代的在線內容。爲了迴應Mark Boulton的「若css可以無痛的建立基線網格這將會有多酷」不管你的執念有多強——不管你的字符是緊挨着基線或者懸浮在基線之間——垂直網格都會是一個重要的思路,使用任意本文所列的方法都會給你一個滿意的基線網格。
       固然,會有一些例子比較難以實施網格的約束,像一些元素如,題注,導航或者列表項目好像不能正確的對齊到預先定義的結構中。在這些例子中,須要注意的是一些妥協並非世界末日。一些設計時,像傑出的設計時Khoi Vinh,認爲基線在你內容主體的上下文才最爲重要,一些次要的元素能夠在不破壞佈局的狀況下不遵照基線對齊。
       但願可以理解的是在此並無正確或者錯誤的實現基線的方法,這也會激勵你在未來可以後在你的項目中嘗試,在此我也鼓勵任何一個喜歡排版的人貢獻這個正在進行的項目,能在將來的的網頁設計中讓垂直網格和水平網格同等重要。
文章來源:伯樂在線