CSS基線之道

9ikblog發表於2013-01-06

英文原文:CSS Baseline,編譯:飛鳥分享

譯者注:網頁設計佈局中一直比較流行網格對齊,但只是針對水平的對齊,很少或者沒有涉及垂直對齊,這篇文章很詳細的講解了垂直網格,乃至基線對其的相關,而css3中的多列布局的也使其顯得更為重要,因此還是很有必要去了解學習,至少也是一種思路。

——————————譯文———————————

這或許是因為缺少基線網格的理解和欣賞,更或者是因為基線網格是出了名的難以實現, 迄今為止還沒有人拿著藍圖讓它成功實現。 有些人甚至認為基線在網路上是多餘的,基線作為一種排版術語和網路上的行為,在網路上遵循的規則有別於用於印刷的,line-height和真正的行距之間令人沮喪的差異就是最明顯的例子。 目前,無論怎樣,讓我們先假設基線至少在某種程度上對於來說網頁設計師是一種有用的工具。但是它到底是什麼樣的一種工具,在我們手上有什麼可以自由使用的工具來實現它,並且最重要的是,這到底值不值得。

CSS基線之道

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

CSS基線之道

網格不僅在水平方向有用,在垂直方向同樣有用

為什麼垂直網格重要?是因為垂直網格與我們大腦如何工作相關,也與我們如何通過模式識別來解析周圍世界相關。即使不再深入這個話題(其他比我聰明的人更適合這個任務),也可以說模式識別容許人類大腦在模式庫中儲存相似或者相同的印象(譬如基本的形狀和顏色),並在遇到新的刺激的情況下通過模式庫檢索來快速分析。這也是為什麼我們的閱讀的時候不去注意當個獨立的字母,反而在一瞬間即可認出整個單詞(從我們大腦記憶當中拿出以前相同模式的例項),這同樣也是為什麼我們能夠很快認出當個的字母(”A”  ”B” “C” …),即使字型、尺寸和顏色發生變化——其基本的形狀已經儲存在我們大腦的模式庫。

一旦任何型別的刺激都不能匹配到你之前儲存的模式,這就會促使大腦在新的記憶中存入新的模式,這反過來需要更多的腦力消耗——而這就是結構和網格(無論是水平還是垂直)設計的重要之處,接下來,想象一個有一致段落間距為X的簡單佈局。在第一處分析過之後,作為同樣的模式,你的大腦會立即認出其他所有的相同段落。但如果相反,同樣的佈局中元素之間有著不同的間距,讀者的大腦要分析所有獨立的元素才能理解他們的意思。用另一句話來說:大腦需要分析的形狀越多,它所需時間便越長。

CSS基線之道

不規則的左邊比右邊需要更多的腦力消耗

任何不規則的形狀都會打斷先流水般湧出的模式識別(因此會浪費一部分本應該用於欣賞優秀內容的腦力活動),而一種規則的,一致的並且可以預期的結構將會使你的設計更易讀也能理解認知你的設計。建立一種固定的基線網格便是實現它的一種很好的方法。

此外,通過基本一個每個垂直(和水平)間距都一致,每一個元素有著預設單元尺寸的系統不僅消除了上述隨意的不統一性,也使得設計師的工作更加容易,設計師只需在總框架總決定基本的結構。建立一個標準,比如,頭部下面總有兩個基線的白色間距,每個盒子都有三個基線空間的內邊距,在我們的佈局中增加邏輯,這不僅易於設計,易於實現,更重要的是易於理解。

現在,如果垂直網格還像一個抽象概念,基線的另一個優點——多列水平對齊——就顯得更容易理解。這在印刷設計中更加常見,特別是雜誌和報紙,經常使用多列布局,相鄰段落(或者頭部)若基線對齊的很好會令閱讀沉浸而歡快,一旦對齊的不好或者根本沒有對齊閱讀便被煩人的打斷。這種來源於基線對齊的安靜的排版展現了一種視覺自信,一個看不見支架支撐著頁內所有的元素,讓讀者潛意識的安心下來。一本左手頁每一行都對齊相對右手頁的書讓人很容易感覺到信任,而相反若是根本對齊的書籍,這種信任則相對少的多。

CSS基線之道

多列水平對齊

line-height的問題

傳統意義上,基線是指大部分字母所“坐落”其上的一條看不見的線,每條基線之間形成基本的基線網格,正如之前所討論的,基線不但形成垂直網格,而且會使相鄰列之間水平對齊。一旦定義好了基線網格,接下來要做的便是強制所有的元素對齊,以此來使得成行的文字,邊框,圖片或者盒子元素總是匹配對齊到相同的垂直結構。

問題是,像在InDesign中能夠讓你點選按鈕(準確的開啟和關閉網格)便能輕鬆調整形狀來對齊網格的工具,對應到css中只能通過控制調整行高(line-height),內邊距(padding),外邊距(margin),大小(size)——其中任何的變動都可能會引起元素總高度的變化。

CSS基線之道

傳統的基線是大部分字母所“坐落”其上線,並且基線之間的高度便是元素的總高度。

更糟糕的是,css中的line-height屬性並沒有嚴格意義上基線的概念,並且每個成行的文字都大致處於元素總高度的中間。這就意味著基於不同樣式和字型的文字精確對齊(基線對齊)需要進一步手動,費時的調整和畫素級的輕移。

因此,我們如何著手開始實施css的基線?因為缺少原生的基線語法,快速到位或者瀏覽器功能性的強迫垂直對齊,我們留給以後的實驗。我們先開始最基本的css方法。

好的方法:基本的css基線

迄今為止,尚無形成統一的正確的方法來實現css基線,有的人只要使行高和間距遵循一套規範便已滿足,其他人則更為製作和細緻——無論怎樣——只有每個成行的文字都漂亮的“坐落”在基線上,圖片,邊框,盒子和其他元素都完美的對齊相同的網格才能滿足。對所有人來說的好訊息是:基本的css基線真的一點都不難。通過一些預先的設計決策(和堅持),它們只需要一點點的基礎數學。

定義你的基線,最好是從你所使用的最小文字開始,大多數是你的body文字,基於此再往上計算。在我下面的例子中,我使用14px的font-size配以22px的line-height,也就是22px是我的基線之間的高度。這樣定義的結果是所有的line-height和所有元素的總高(包括邊框、內邊距和外邊距)必須是22px的倍數,如下:

 

現在定義的line-height和font-size並不是最優的,因此為了可伸縮性,將其轉換為em。如此一來,會使得程式碼有點難以閱讀,但是所用的數學相當的簡單——只需要記住在更改font-size的使用重新計算line-height。

注意,在通篇我都會以px為單位提及font-size和line-height,這樣能更加清楚的表明其“物理”大小和所給例子中的比例。然而,所有的程式碼,我們都會轉換成em。

利用可見的網格(很多人使用png或者gif的背景圖,其他人使用諸如Baseliner的工具),我們可以檢測所有樣式的對齊。在此我們發現成行的文字並沒有“坐落”在基線上,相反漂浮在基線之間。在此階段這並沒什麼要當心的——我們可以簡單的便宜我們的背景圖片,或者在body上放增加內邊距(padding)來修復。

CSS基線之道

一個可視的網格將對設計過程很有幫助

到目前為止一切順利,但我們的程式碼仍然相當的基礎。但我們包含更多的屬性——比如上邊框——給所有的元素,將會發生什麼?自然地,屬性值需要調整,使之合併邊框高度之後的總高度仍然是基線之間高度的倍數。

CSS基線之道

注意,怎樣使得3px的border-top和19px的margin-bottom之和等於基線之間高度22px

使用SASS或者REM

儘管這的確不是什麼高科技,但在複雜的網站中,特別是使用相對單位的時候上述的數字相加將會是個不小的挑戰。如果你願意犧牲em的可伸縮性,堅持使用px為單位,像SASS之類的預編譯語言可以解決一部分麻煩。使用SASS我們可以將基線之間高度定義為一個變數(在我的事例中為$baseline),並使用一次方程去定義它的倍數。以此來使得整個過程變得非常簡單,也使得css更容易閱讀。在一般的過程中若你想重新dinginess你的基線之間高度,你只需改動一個地方。儘管下面我的示例中使用Sass,當使用rems也是一樣的道理——只在一處定義你的基線間高度,然後再整個程式碼中生效。

在圖片和複雜的佈局上使用JavaScript

在簡單的文字排版佈局上使用基線網格要相對簡單點,但我們必須保證其他的元素相圖片也要對齊網格。對於容器,按鈕,和網頁分界線來說,通過css讓任何的單元都是基線間高度的倍數,這是一個很重要的約定。但從另一個方面來說,圖片很少遵守這一約定,其一般為一系列任意的高度,因此在這樣的例子中,少量的JavaScript便可以幫我們的大忙。我不會在此深究,但是jQuery的外掛Baseline.js和Matthew Wilcox關於垂直網格的文章倒是值得一看。如果你正在進行一個複雜的佈局,無妨看看FtColumnflow——一段“修復css多列布局缺陷”的程式碼,它廣泛使用在音樂《金融時報》的web app上,並且如果你想找一個更為健壯的方案,它或許更加合適。

上述基礎的方案。通過保證我們的行高,內邊距,外邊距,高度——任何的屬性——相加和總是等於基線間高度的倍數,就可以保證我們整個垂直網格不受影響,這很簡單,對吧?

當然,如果接下來不繼續深入,你也不會看這篇文章了。

很爛的方案:任意可變式

壞訊息是,大多數的設計師在受限的條件下工作,有時一個22px的基線間的高度對他們來說更像是一個令人煩惱的阻礙,而不是有用的約束。例如,遵循黃分割的規則,一個16px的段落主體部分可以推匯出26px的段頭(儘管下部段落主題可能適用高於20px的任何值,這取決於字型)。保持我們的基線間高度為22px,你或許會發現一個簡單的22px的基線間高度的行距太窄了以至於不能舒適的閱讀,然而一個雙倍的基線間高度又顯得太寬了,只有在h2呈兩行顯示的情況下才會有這樣的爭論,當然理論上可以假設列的寬度足夠的長,這樣折行就永遠都不會發生,嗯哼,這只是理論上。

CSS基線之道

h2要麼小的尷尬要麼行高太大

如果在此有一種快速到位的方法,就不會發生上述的問題,就像我們可以簡單的將h2不應用基線網格,看看緊隨它的短多是不會魔術般的落到正確的位置。遺憾的,並不存在這樣可行的魔法,我們只能實事求是的去思考找出一種解決方案。

在文章的開始我曾推薦從你有著最小文字的line-height開始定義你的基線間的高度,就像body的文字。正如我們所看到的,一個固定的,22px(或者你body line-height的任意值)的最小單元會使得固定字型的line-height值變得很不合適。但如果讓我們的原始的基線間高度減半會怎樣?技術上來講我們的body的文字就會有兩個基線間高度的line-height,但這只是紙上談兵。在大多數的示例中,這樣帶來的可變性和排版自由的結果是值得的,我們使用黃金分割的比例來快速的定義一些h元素的大小(四捨五入,保持em值整潔),我們可以很容易的看到每次值得增加都會有一個合適的line-height值,例如:16px/22px ,28px/33px,40px/44px等。

CSS基線之道

h1, h2, 和 p都對齊了基線網格

醜陋的方案:偏移的方式

在我繼續之前,我必須承認的是,下述的內容完全是實驗性的甚至你們其中一部分人甚至會認為它實踐起來也很糟糕。但如果你準備繼續遷就我,即使它變得醜陋也繼續閱讀。好吧,我說的醜陋是源於“程式碼整潔”的觀點。或許從設計的角度來說,它可能確實很漂亮。

基於上述的基本的方案和帶一點實用性(可選)的隨意可變得方案,現在我們有知識和工具去改善大多數佈局的基線網格,但是對於真正基線卻沒有實現。正如前面所提到的,css中line-height計算的方式意味著字元大約處於行距的垂直中點,而不是字元的下邊緊挨著基線(先InDesign和Quark)。許多人理所應當的認為這就這是應該的。這就是css中iine-height工作的方式,我們沒法改變。沒錯,但是我們的眼睛並不知道css的概念。我們的眼睛並不習慣去按照x軸中心去掃描成行的文字——它們習慣於跟隨字元的地步,基線來閱讀,並且當相鄰行錯位的時候可讀性就會變差。

來看一下下面的額例子:

在相鄰兩列的情況且,儘管基線已經正確的貫穿介紹段落,但介紹段落的字母的底部(下圖紅線)並沒有對齊和主段落對其,這正是因為字型計算之後的line-height所導致。

CSS基線之道

css中line-height倒是誇列並沒有對其

現在到了它變醜陋的地方。為了能夠在所有列中的成行文字都對齊(當然是最重要的一點是從基線網格開始),我們必須手動偏移樣式。一個簡單的方法是增加padding-top的值直到字元緊挨到基線,並且相應調整margin-bottom來彌補增加的值。

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

CSS基線之道

所有的元素多列對齊。

噓。如果你仍然還在閱讀,或許你要麼是受虐狂,要麼是對細節有著病態的迷戀,而對於後者,恭喜你,毫無疑問你的基線就像外牆的磚一樣牢固。

這值得嗎?

下面是我們所有的。基礎css的基線,相當的簡單,只需要不多的數學和組織即可改進你的佈局。而在天平的另一端,我們可以手動的調整padding和margin值來模擬像列印設計中精確的基線,這種概念無疑會讓純css主義者面帶愁容。更實在的問題當然是,手動的偏移樣式對視覺效果帶來好處是否值得。在某種情況下,比如設計驅動的專案和微型站點中,這確實值得。

其他情況,大部分的情況是,對於更為複雜的站點(你的專案經理會絞盡腦汁想知道你為什麼需要花那麼長的時間來構建初始模版)或者由數個開發者維持同樣的程式碼的協作性專案,這樣確實不值得。我們需要面對的是——我們所談論的在某些極端的例子中不僅會增加體力勞動,而且會讓程式碼變得更為負責和難以維護。在一個足夠的大的專案中甚至會影響你站點的載入時間。

但是想想看,僅僅是幾年前,從行業領袖到黑客很少有人提倡並不討巧的“sliding doors”技術,但現在css3已經讓它變得司空見慣。使用兩個div而不是一個來實現圓角這是否值得?很顯然,對一些人來說是值得的——但其他人認為就是浪費時間,導致了實施的困難和語義上有缺陷的程式碼。但是關鍵的一點是:如果沒有人嘗試如此勞力和程式碼密集的技術,我們可能不會有成熟語法的技術時代了。

實驗性的,糟糕的體驗,hacks,醜陋的程式碼——無論我們怎樣稱呼它——它已經推出了,並且將會繼續推出,我們的語法會改善,我們將使用新的工具來建立和釋出下一代的線上內容。為了回應Mark Boulton的“若css能夠無痛的建立基線網格這將會有多酷”無論你的執念有多強——無論你的字元是緊挨著基線或者懸浮在基線之間——垂直網格都會是一個重要的思路,使用任意本文所列的方法都會給你一個滿意的基線網格。

當然,會有一些例子比較難以實施網格的約束,像一些元素如,題注,導航或者列表專案好像不能正確的對齊到預先定義的結構中。在這些例子中,需要注意的是一些妥協並不是世界末日。一些設計時,像傑出的設計時Khoi Vinh,認為基線在你內容主體的上下文才最為重要,一些次要的元素可以在不破壞佈局的情況下不遵守基線對齊。

希望能夠理解的是在此並沒有正確或者錯誤的實現基線的方法,這也會激勵你在將來能夠後在你的專案中嘗試,在此我也鼓勵任何一個喜歡排版的人貢獻這個正在進行的專案,能在未來的的網頁設計中讓垂直網格和水平網格同等重要。

好運!

資源

Ordering disorder, Khoi Vinh

Setting Type on the Web to a Baseline Grid, Wilson Miner

The relevance of the baseline grid, Elliot Jay Stocks

Baseline Formework

Technical Web Typography: Guidelines and Techniques, Harry Roberts

More Perfect Typography, Tim Brown

 

相關文章