《CSS揭祕》筆記（一）

時間 2019-11-09

標籤 CSS揭祕筆記欄目 CSS 简体版

原文原文鏈接

前言

咱們在現代 CSS 中所面臨的挑戰已經不在於如何繞過這些轉瞬即逝的瀏覽器 bug。現在的挑戰是，在保證 DRY ① 、可維護、靈活性、輕量級而且儘量符合標準的前提下，把咱們手中的這些CSS特性轉化爲網頁中的各類創意。這正是這本書將要呈現的內容。——引用自前言css

①DRY 是 Don’t Repeat Yourself 的首字母縮寫，意思是不該該重複你已經作過的事。它是一種廣爲流傳的編程理念，旨在提高代碼某方面的可維護性：在改變某個參數時，作到只改儘可能少的地方，最好是一處。強調 CSS 代碼的 DRY 原則是一個貫穿本書的主題。DRY 的反面是 WET，它的意思是 We Enjoy Typing（咱們喜歡敲鍵盤）或 Write Everything Twice（一樣的代碼寫兩次）。html

全書都是之前言這段話爲基礎，根據不一樣場景下的各類問題給出更有創意的實現方案，一共包含了47篇攻略，按主題分爲 7 章，每篇攻略至少會附上一個在線示例，在線示例必定不能錯過，對案例的理解有很大幫助。web

雖然建議是做爲進階閱讀，可是每篇攻略都貼心的提供了背景知識提示，無論可否徹底看懂，仍然能夠開闊思路。編程

ps：有興趣想看這本書的能夠聯繫我分享pdf電子版（僅供學習使用，仍是呼籲你們支持正版書籍），筆記基本就是摘要==鞏固知識，閱讀完整書籍才能達到更好的學習效果。瀏覽器

第一章引言

Web 標準：是敵仍是友

標準的制定過程

編輯草案（ED）
首個公開工做草案（FPWD）
工做草案（WD）
候選推薦規範（CR
提名推薦規範（PR）
正式推薦規範（REC）ide

瀏覽器兼容性

推薦如下網站查證瀏覽器對CSS屬性的支持狀況：函數

瀏覽器前綴

經過在名稱前面加上瀏覽器特有的前綴，就能夠自由地嘗試使用不一樣瀏覽器實現的一些實驗性的（甚至是私有的、非標準的）特性，工做組會將收到的反饋吸取到規範之中，而且逐漸完善該項特性的設計。然而這種方式產生了不少弊端，例如隨着規範的修改要來回打補丁修改，代碼冗餘不利於維護等。工具

最近，瀏覽器廠商已經不多之前綴的方式來實驗性地實現新特性了。取而代之的是，這些實驗性特性須要經過配置開關來啓用，這能夠有效防止開發者在生產環境中使用它們，由於你不能要求用戶爲了正確地瀏覽你的網站而去修改瀏覽器設置。固然，這會致使一個後果：嘗試這些實驗性特性的開發者會減小；但咱們仍然會獲得足夠多的反饋，甚至是更高質量的反饋（你可能會質疑），同時還避免了瀏覽器前綴的全部缺點。不過咱們還須要很長的時間，才能從瀏覽器前綴所引起的漣漪效應中解脫出來。佈局

CSS 編碼技巧

儘可能減小代碼重複

代碼可維護性的最大要素是儘可能減小改動時要編輯的地方，當某些值相互依賴時，應該把它們的相互關係用代碼表達出來。例：line-height: 1.5;。post

代碼易維護 vs. 代碼量少。

currentColor：它是從SVG 那裏借鑑來的一個特殊的顏色關鍵字。它沒有綁定到一個固定的顏色值，而是一直被解析爲 color，這個特性讓它成爲了 CSS 中有史以來的第一個變量。

inherit （繼承）：很容易被遺忘，能夠用在任何 CSS 屬性中，並且它老是綁定到父元素的計算值（對僞元素來講，則會取生成該僞元素的宿主元素）。

tips：推薦使用 HSLA 而不是 RGBA 產生半透明的白色，由於它的字符長度更短，敲起來也更快，這歸功於它的重複度更低。

相信你的眼睛，而不是數字

人的眼睛並非一臺完美的輸入設備，有時候精準的尺度看起來並不精準，而咱們的設計須要順應這種誤差。

在視覺設計領域廣爲人知的例子：咱們的眼睛在看到一個完美垂直居中的物體時，會感受它並不居中，實際上，咱們應該把這個物體從幾何學的中心點再稍微向上挪一點，才能取得理想的視覺效果。

關於響應式網頁設計

每一個媒體查詢都會增長成本，用對了它就是利器。

咱們的思路是盡最大努力實現彈性可伸縮的佈局，並在媒體查詢的各個斷點區間內指定相應的尺寸。當網頁自己的設計足夠靈活時，讓它變成響應式應該只須要用到一些簡短的媒體查詢代碼。

若是你發現本身須要一大堆媒體查詢才能讓設計適應大大小小的屏幕，那麼不妨後退一步，從新審視你的代碼結構。由於在全部的狀況下，響應式都不是惟一須要考慮的問題。

如下建議可能會幫你避免沒必要要的媒體查詢：

使用百分比長度來取代固定長度。若是實在作不到這一點，也應該嘗試使用與視口相關的單位（ vw 、 vh 、 vmin 和 vmax ），它們的值解析爲視口寬度或高度的百分比。

em：相對於當前對象內文本的字體大小。
rem：r是"root"的縮寫，意思是 1rem 等於根元素的字體大小；大部分狀況下，根元素就是<html>元素。rem 也能夠用基於 html 根元素字體大小的 rem 做爲整個網格佈局或者UI庫的大小單位.container { width: 70rem; // 70 * 14px = 980px}。
vw：1vw 等於 1/100 的視口寬度。
vh：1vh 等於 1/100 的視口高度。
vmin 和 vmax：是 vw 和 vh（視口高度和寬度）二者的最小或者最大值。
ch：單位一般被定義爲數字 0 的寬度。
ex：定義爲當前字體的小寫x字母的高度或者 1/2 的 1em。不少時候，它是字體的中間標誌。
pc：1pc 等於 12 點。
pt：1pt 等於 1/72 英寸。

當你須要在較大分辨率下獲得固定寬度時，使用 max-width 而不是 width，由於它能夠適應較小的分辨率，而無需使用媒體查詢。
不要忘記爲替換元素（好比 img 、 object 、 video 、 iframe 等）設置一個 max-width，值爲 100%。
假如背景圖片須要完整地鋪滿一個容器，無論容器的尺寸如何變化，background-size: cover 這個屬性均可以作到。可是，咱們也要時刻牢記——帶寬並非無限的，所以在移動網頁中經過 CSS 把一張大圖縮小顯示每每是不太明智的。
當圖片（或其餘元素）以行列式進行佈局時，讓視口的寬度來決定列的數量。彈性盒佈局（即 Flexbox）或者 display: inline-block 加上常規的文本折行行爲，均可以實現這一點。
在使用多列文本時，指定 column-width （列寬）而不是指定 column-count（列數），這樣它就能夠在較小的屏幕上自動顯示爲單列布局。

合理使用簡寫

合理使用簡寫是一種良好的防衛性編碼方式，能夠抵禦將來的風險。

當咱們要明確地去覆蓋某個具體的展開式屬性並保留其餘相關樣式，那就須要用展開式屬性。

展開式屬性與簡寫屬性的配合使用，可讓代碼更加 DRY。

我應該使用預處理器嗎

預處理器爲 CSS 的編寫提供了一些便利，好比變量、mixin、函數、規則嵌套、顏色處理等。若是使用得當，它們在大型項目中可讓代碼更加靈活，而 CSS 自身在這方面確實有很大侷限。只要咱們在代碼健壯性、靈活性和 DRY 方面有追求，就會感覺到 CSS 在這方面的侷限。不過，預處理器也不是天衣無縫：

CSS 的文件體積和複雜度可能會失控。即便是簡潔明瞭的源代碼，編譯後也可能會變成一頭巨獸。
調試難度會增長，由於你在開發工具中看到的 CSS 代碼並非你寫的源代碼。不過這個問題已經大大好轉了，由於已經有愈來愈多的調試工具開始支持 SourceMap。
預處理器在開發過程當中引入了必定程度的延時。儘管它們一般很快，但仍然須要差很少一秒鐘的時間來把你的源代碼編譯成 CSS，而你不得不等待這段時間才能預覽到代碼的效果。
每次抽象都必然會帶來更高的學習成本，每當有新人加入到咱們的代碼庫中，這個問題都會重演。
抽象泄漏法則：「全部重大的抽象機制在某種程度上都存在泄漏的狀況。」預處理器是由人類寫出來的，就像全部由人類寫出來的大型程序同樣，它們有它們本身的 bug。這些 bug 可能會潛伏好久，由於咱們不多會懷疑預處理器的某個 bug 纔是咱們 CSS 出錯的幕後元兇。
還可能致使不自覺地「依賴」和「濫用」。在某些時候，預處理器並沒必要要，好比在小型項目中；或者在將來，說不定預處理器最受歡迎的那些特性都被加入了原生 CSS 中。爲了不可能發生的「依賴」或「濫用」，在引入預處理器的問題上須要冷靜決策，不該該在每一個項目一開始時就不動腦筋順着慣性來。

已經有不少受預處理器啓發的特性都已經以各類方式融入到原生 CSS 中了，原生特性一般比預處理器提供的版本要強大得多，例如：calc() 函數和 color() 函數。

掘金：《CSS揭祕》筆記（一）

博客園：《CSS揭祕》筆記（一）