論 CSS 中的邏輯

PiscesYE 發布于2019-08-28 18:11 / 3624人閱讀

摘要：天生缺乏邏輯性的問題導致了預處理器的出現。這會導致圈復雜度問題。圈復雜度對于來說可能是一種比較高階的原則，但如果我們通過它來考量那些蘊含在我們寫的選擇器中的邏輯性，那我們也許就能寫出更加優秀的代碼。

本文在征得原作者 @csswizardry 同意的情況下，翻譯自他博客中的文章：Cyclomatic Complexity: Logic in CSS。最初發布于我的個人博客：咀嚼之味
另外呢，@hax前輩對本文的原作者的理論嗤之以鼻。所以加一句：盡信書，則不如無書。各位看官自己掂量著吧~

在過去的很長一段時間中，我們都說 CSS 是不帶有任何邏輯的，意思是在 CSS 中沒有控制流，也沒有某種類似于其他編程語言的方式來組織 CSS。CSS 天生缺乏邏輯性的問題導致了預處理器的出現。然而業界卻對 CSS 預處理器褒貶不一，支持預處理器的人認為這彌補了 CSS 缺失的特性；而反對預處理器的人則認為 CSS 的設計初衷就不應該帶有邏輯性，他們認為根本不應該引入預處理器這個概念。

然而，一種獨特的思考方法最近突然蹦入了我的腦袋。它讓我感到 CSS 確實擁有邏輯性！很少有人真正那么想過，這大概也是我們一直認為 CSS 的邏輯性匱乏的最大原因吧。

我發現我們可以將復合選擇器理解為：主體部分 + 條件部分。首先來看一個例子：

div.sidebar .login-box a.btn span {
    /*...*/
}

在這個復合選擇器由主體部分是 span，而條件部分是 IF (inside .btn) AND IF (on a) AND IF (inside .login-box) AND IF (inside .sidebar) AND IF (on div)。

也就是說，一個選擇器的每一部分都是一個 if 語句，需要在解析選擇器時被滿足（或者不滿足）。有了這種微妙的而又全新的認識，如今我們回頭再看看自己曾經寫出的 CSS 代碼，我們將會意識到選擇器寫的好或者壞，會對效率產生直接的影響。我們真的會寫出下面這段邏輯嗎？（偽代碼）：

@if exists(span) {
  @if is-inside(.btn) {
    @if is-on(a) {
      @if is-inside(.login-box) {
        @if is-inside(.sidebar) {
          @if is-on(div) {
            # Do this.
          }
        }
      }
    }
  }
}

也許不會。這看上去太不直接，也太啰嗦了。我們也許只需要這么寫：

@if exists(.btn-text) {

  # Do this.

}

每當為選擇器添加一層限制，其實我們也就是添加了額外的一個 if 語句。這會導致圈復雜度問題（Cyclomatic Complexity)。

圈復雜度

在軟件工程中，圈復雜度是一種程序復雜性的一種度量標準，它一般計算程序中的控制流的數量（如 if, else, while 等）。程序中存在越多的控制流，則圈復雜度就越高。我們自然想要保證圈復雜度能夠盡量地低，因為圈復雜度越高：

代碼就越難推導

更多潛藏著的、可能會導致失敗的問題

代碼更難以修改、維護以及復用

你需要考慮更多代碼執行的結果與其副作用

編寫測試代碼的難度也會更高

從圈復雜度的角度來思考 CSS 的解析過程，我們可以看到瀏覽器在渲染樣式之前需要做許多的決定。我們寫的選擇器中的 if 語句越多，這個選擇器的圈復雜度就越高，這也意味著我們寫的選擇器越糟糕，為了使得這一條選擇器規則滿足，就有需要匹配更多的條件。同時，我們寫的選擇器也會缺乏清晰度和復用性，因為引入了過多不必要的 if 語句會導致不準確的匹配(false positive)。

相比于將 span 嵌套于 .btn 內部并寫一大堆限制條件，更好地做法應該是創建一個新的類 .btn-text 來描述這個 span。這樣做更加直截了當，同時也更為簡潔和健壯（越多的 @if 語句導致選擇器規則越不容易被滿足）。

值得注意的是瀏覽器解析你寫的選擇器的方式：從右向左。如果你在寫你的選擇器時，第一個想到的問題是：“這是一個 span 元素嗎？” 那你通常就會把選擇器寫的過于冗繁。你應該從另一個角度思考，寫出清晰準確的選擇器規則，徹底摒棄那些冗余的條件語句。

請不要寫過于寬泛的規則，導致你寫的選擇器在匹配開始時就選中大量的 DOM 元素——然后不得不逐步通過更多的條件語句來刪減匹配的對象。從選擇器的規則解析的一開始就匹配盡量少的元素才是一種更棒的方法。

圈復雜度對于 CSS 來說可能是一種比較高階的原則，但如果我們通過它來考量那些蘊含在我們寫的選擇器中的邏輯性，那我們也許就能寫出更加優秀的代碼。

一些易于遵守的小規則，

讓你的選擇器最簡化：每一次你想要為選擇器添加規則時，你都在添加額外的 if 語句。將這些 if 語句大聲地讀出來，仔細考慮它們是否有添加的必要。你需要時刻保持你寫的選擇器足夠合理與簡潔。

保證圈復雜度最小化: 使用像 Parker 這樣的工具來測試你寫的選擇器的圈復雜度（參考文檔：Identifiers Per Selector）

如果你不需要這個檢驗條件，那就不要把它放進選擇器: 有時在 CSS 中使用嵌套結構是有必要的，可在大多數時候并不是，你甚至不能完全相信Inception Rule。

從右邊考慮選擇器如何編寫: 從需要匹配的那類元素開始，寫盡量少的額外的 CSS 代碼來完成一次正確的匹配。

寫選擇器時擁有明確的目的性: 確保你寫的選擇器確實是你想要的，而不是那些碰巧能使得頁面正常顯示的代碼。

你的選擇器是你的 CSS 結構最基本的組成部分，一定要確保你寫的代碼足夠合理而簡練。

云服務器 GPU云服務器數據倉庫中的邏輯結構排隊論圖論算法論金融監管

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/111074.html

鳥瞰前端 , 再論性能優化

摘要：前端性能優化的涉及點從服務器到協議再到宿主環境本身都要有比較深刻的認識，業界目前主要還是以雅虎總結出來條前端性能優化的黃金軍規為參考。歡迎大家前往騰訊云技術社區，獲取更多騰訊海量技術實踐干貨哦~ 導語 : 從事前端有6年+的時間了，從最開始的美工到重構再到偏向js邏輯開發的前端開發，一直在前端這個行業里面摸索和學習，我現在將自己這些年的一個心得體會來個系統性的梳理寫成一篇關于性能優化...

voidking 2019-08-29 13:47 評論0 收藏0
JS函數式編程 - 函子和范疇論

摘要：而且我們不需要了解的特別深，函數式編程很多概念是從范疇論映射過來的。了解范疇論相關概念有助于我們理解函數式編程。函子函子是用來將兩個范疇關聯起來的。在前面幾篇介紹了函數式比較重要的一些概念和如何用函數組合去解決相對復雜的邏輯。是時候開始介紹如何控制副作用了。數據類型我們來看看上一篇最后例子： const split = curry((tag, xs) => xs.split(ta...

JouyPub 2019-08-23 12:35 評論0 收藏0
webpack多頁應用架構系列（十五）：論前端如何在后端渲染開發模式下夾縫生存

摘要：回到純靜態頁面開發階段，讓頁面不需要后端渲染也能跑起來。改造開始本文著重介紹如何將靜態頁面改造成后端渲染需要的模板。總結在后端渲染的項目里使用多頁應用架構是絕對可行的，可不要給老頑固們嚇唬得又回到傳統前端架構了。本文首發于Array_Huang的技術博客——實用至上，非經作者同意，請勿轉載。原文地址：https://segmentfault.com/a/119000000820338...

dinfer 2019-07-01 12:21 評論0 收藏0
webpack多頁應用架構系列（十五）：論前端如何在后端渲染開發模式下夾縫生存

摘要：回到純靜態頁面開發階段，讓頁面不需要后端渲染也能跑起來。改造開始本文著重介紹如何將靜態頁面改造成后端渲染需要的模板。總結在后端渲染的項目里使用多頁應用架構是絕對可行的，可不要給老頑固們嚇唬得又回到傳統前端架構了。本文首發于Array_Huang的技術博客——實用至上，非經作者同意，請勿轉載。原文地址：https://segmentfault.com/a/119000000820338...

dingda 2019-08-20 13:57 評論0 收藏0