《CSS揭祕》筆記（一）

easyblue發表於2018-03-26
CSS筆記

前言

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

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

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

雖然建議是作為進階閱讀，但是每篇攻略都貼心的提供了背景知識提示，不管能否完全看懂，仍然可以開闊思路。

ps：有興趣想看這本書的可以聯絡我分享pdf電子版（僅供學習使用，還是呼籲大家支援正版書籍），筆記基本就是摘要==鞏固知識，閱讀完整書籍才能達到更好的學習效果。

第一章 引言

Web 標準：是敵還是友

標準的制定過程

  1. 編輯草案（ED）
  2. 首個公開工作草案（FPWD）
  3. 工作草案（WD）
  4. 候選推薦規範（CR
  5. 提名推薦規範（PR）
  6. 正式推薦規範（REC）

瀏覽器相容性

推薦以下網站查證瀏覽器對CSS屬性的支援情況：

瀏覽器字首

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

最近，瀏覽器廠商已經很少以字首的方式來實驗性地實現新特性了。取而代之的是，這些實驗性特性需要通過配置開關來啟用，這可以有效防止開發者在生產環境中使用它們，因為你不能要求使用者為了正確地瀏覽你的網站而去修改瀏覽器設定。當然，這會導致一個後果：嘗試這些實驗性特性的開發者會減少；但我們仍然會得到足夠多的反饋，甚至是更高質量的反饋（你可能會質疑），同時還避免了瀏覽器字首的所有缺點。不過我們還需要很長的時間，才能從瀏覽器字首所引發的漣漪效應中解脫出來。

CSS 編碼技巧

儘量減少程式碼重複

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

程式碼易維護 vs. 程式碼量少。

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

inherit （繼承）：很容易被遺忘，可以用在任何 CSS 屬性中，而且它總是繫結到父元素的計算值（對偽元素來說，則會取生成該偽元素的宿主元素）。

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

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

人的眼睛並不是一臺完美的輸入裝置，有時候精準的尺度看起來並不精準，而我們的設計需要順應這種偏差。

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

關於響應式網頁設計

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

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

如果你發現自己需要一大堆媒體查詢才能讓設計適應大大小小的螢幕，那麼不妨後退一步，重新審視你的程式碼結構。因為在所有的情況下，響應式都不是唯一需要考慮的問題。

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

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

  1. em：相對於當前物件內文字的字型大小。

  2. rem：r是"root"的縮寫，意思是 1rem 等於根元素的字型大小；大部分情況下，根元素就是<html>元素。rem 也可以用基於 html 根元素字型大小的 rem 作為整個網格佈局或者UI庫的大小單位.container { width: 70rem; // 70 * 14px = 980px}。

  3. vw：1vw 等於 1/100 的視口寬度。

  4. vh：1vh 等於 1/100 的視口高度。

  5. vmin 和 vmax：是 vw 和 vh（視口高度和寬度）兩者的最小或者最大值。

  6. ch：單位通常被定義為數字 0 的寬度。

  7. ex：定義為當前字型的小寫x字母的高度或者 1/2 的 1em。 很多時候，它是字型的中間標誌。

  8. pc：1pc 等於 12 點。

  9. 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揭祕》筆記（一）

相關文章