CSS 之於前端有些像廈門之於 IT 界：耳熟能詳卻又略顯小眾。那麼在廈門召開的第四屆 CSS 大會是否能結合碰撞出新的火花呢？跟隨著本兼職攝影師來看看吧~
週六上午的巨幕影廳裡，本屆 CSS 大會正式拉開帷幕。在現在的前端圈技能樹越點越多的大潮下，單單會寫程式碼的前端或許已經不能算是優秀的前端了。比如我司優秀的前端小姐姐，是自帶開場前唱歌暖場技能的?
趁開場前觀察了一下會場，妹子還真不少?
進入正題。我們迎來了第一個分享，來自新加坡同學的《Responsive Components》。
這個演講的內容圍繞著如何構建編寫可擴充套件的 CSS 而展開。說實話，這恐怕已經不算是一個新穎的議題了。不過由於是全場第一場演講的緣故，到場的同學們聽得都很認真，甚至還有記筆記的：
而至於具體內容呢，給我個人留下印象最深刻的一點是——Demo 的排版相當精緻呢……內容的畫風大概是這樣的：
如果你已經熟悉了當前前端生態下 CSS 的一套工具鏈，你可能會覺得這套東西是已經得到過充分討論，甚至不甚必要的：在今天給一個 button 定義可組合的 small 和 large 之類的類名，我想應該是前端同學的基本技能了吧？另外，也許是受到 「CSS」大會的名稱所限，講師對 Components 的探討似乎也只是聚焦在 CSS 的層面，這確實很切題，可惜多少會有種一桌佳餚少了點葷菜的遺憾感。可能是時間所限，這個分享跳過了提問環節，我們直接進入了下一位嘉賓勾股所帶來的話題。
勾股老師帶來的話題是《CSS Houdini 初探》，這是一套正在到來的底層 CSS API。如果說第一個分享像是不痛不癢的前戲，這個分享裡資訊量的尺度就大了非常多，說重新整理了我個人對 Render 這個詞的認識也不為過。這裡結合個人理解做個簡單的二次傳（an）播（li），理解不當之處請多多指正。
傳統意義上 JS 和 DOM 的繫結是如此緊密，以至於我們可能認為只要掌握了對 DOM 的控制，再配合獨立的 CSS，表達力就足夠強大了。
一見 JavaScript，立刻想到瀏覽器，立刻想到 DOM，立刻想到 DOM 操作，立刻想到副作用，立刻想到骯髒。
前端程式設計師的想象惟在這一層能如此躍進。
——魯迅
但 DOM 對渲染的控制並非萬能。除了 Canvas 外，前端同學在 JS 中幾乎沒有對渲染內容的畫素級控制：譬如，你能夠用 JS 存取頁面任意 (x, y) 座標的畫素顏色嗎？相信每個想要自動化測試 UI 渲染結果或者實現截圖需求的同學，都會明白這個痛點所在。
要想在 JS 中實現對渲染過程更細粒度的控制，除了 getComputedStyle 和 el.style.width = xxx 這種通過 DOM 隔靴搔癢的操作以外，還有什麼更直接的機制呢？
就在去年，主流瀏覽器已經普遍提供了對 CSS 變數的支援，它允許你在 CSS 中宣告形如 --foo 和 --bar 的自定義屬性，而後通過 var() 函式對變數求值。你可以把這個機制理解成原生的簡化版 Less / Sass 變數，但它並不能通過上面的 DOM API 存取。並且，由於 CSS 規則的靈活性，在動畫中實時解析它的值是非常困難的。
CSS Houdini 中 Paint API 與 Animation Worklet 的到來，則大大增強了前端對 CSS 動效的控制力：如果你的 CSS 變數是供 background 等支援圖片的屬性使用的，那麼你可以在 JS 中將 Canvas 作為這個 CSS 屬性的值，且相應的 Transition 過程由瀏覽器自動更新！
在現場演示了基於這個 API 所實現的類 Material Design 水波按鍵效果，結合了 Canvas 與 CSS 的實現程式碼非常簡潔。程式碼的畫風大概這樣：
CSS Houdini 其實是一整套豐富的 API，除了上面提到的 Paint 和 Web Animation 以外，還有更多的能力。例如如果要實現一個「標題先自適應放大，再粘性吸頂，最後隨滾動消失」的滾動效果，傳統上需要使用 JS 實現很細粒度的控制，並且容易帶來效能問題。而 CSS Houdini 中提供了一些新的概念，組合起來的強大威力能讓我們輕鬆解決這個問題：
Animations 是已經成熟的動畫系統，Timeline 可以指定「第幾秒做什麼」，Keyframe Effects 能夠指定「在哪些幀加什麼特技」。將它們結合，我們就能得到一個直接與滾動進度相關的動畫 API 了。這些特性還沒有完全落地，為什麼這裡還要特地提及呢？
實際上我個人在近期正在折騰一個 Web 的視訊編輯器，這時如何處理「會隨時間不停改變，且隨時可互動」的 UI 就成了一個不大不小的問題。讓我感到最有趣也最慚愧的地方是，我已經實現的 API 和今天才發現的 Timeline + Keyframe 的一套非常接近，目標都是最後能夠通過形如 play(0.5) 或 stop(0.2) 的方式支援從 Timeline 的任意進度啟停互動。這雖然驗證了目前實現的方向基本靠譜，但慚愧的是今天才知道又雙叒叕重複發明輪子了……
最後展望未來，三駕馬車的進化：
- HTML → Web Components
- JS → Web Assembly
- CSS → CSS Houdini
值得一提的是，最後的最後有個挺有趣的 One More Thing，希望下次 CSS Conf 能見到實體?（下圖中還出現了賀老，這個也算 One More Thing 嗎）
在勾股之後是顧軼靈男神的分享《可複用元件的 CSS 介面設計》，
這個話題從上古時期樣式的規範說起，重溫了一遍 CSS 的演化歷程。例如下面這個 Netscape 最終胎死腹中的提案，是不是有種 React 穿越 20 年的感覺：
接下來的內容則主要圍繞著元件庫設計時在樣式方案上的取捨展開了。和 Vue 裡端起一把梭就是 scope 比起來，React 的樣式方案確實算是百花齊放。但不論具體的選型有何考量，這個原則是相通的：
通過區分內部和外部 API，達到對擴充套件開放，對修改封閉的狀態的理念，確實是工程上可行且可靠的實踐。但對於 CSS 這個連作用域都沒有的語言來說，要區分 public 和 private 總是存在不容易的。從這個角度來考量的話，CSS-in-JS 是一個能夠讓 CSS 具備更多現代語言特性的好方案，值得投資。而（一直爭議很大的）BEM 相比起這些更現代化的方案，則更像是彙編與早期 C 語言中的匈牙利命名法，相當於只有在完全沒有作用域機制保護時才需要引入的約定，而鬆散的約定總是很難被遵守的。
男神講著講著就介紹到了自有的元件庫設計了，這裡提到了一個挺漂亮的手法，即通過形如下面所示的資料結構，把元件的公有 API 狀態數量限制住。這裡插播個廣告，要想再執行時校驗這樣的資料結構的資料又嫌棄 JSON Schema 笨重，不妨瞭解下我維護過的 Superstruct 哈?
上午的三個正式分享結束後，是一個簡短的「閃電分享」，分享嘉賓是一位來自頭條的大佬。
可惜我由於短暫地離開了現場，回來的時候已經不知道他在講什麼了……問了周圍的幾個同學也是一臉懵逼?大致是通過修改瀏覽器原始碼的方式實現了比 PWA 更好的 Web 應用支援，還是蠻神奇的。雖然沒有太多有印象的內容，不過 PPT 的畫風倒是拍下了，大家可以自己體會。（感覺風格也是蠻頭條的哈哈）
早上的分享就這樣結束了，散場時間蹭了賀老一張合照?
下午的第一個分享是張鑫旭老師的《Leader，我不想寫 CSS》，內容非常清奇，是圍繞著「怎麼樣讓 CSS 寫起來更爽」而展開的：
內容相當簡短，除了安利了一波編輯器外掛和 snippet 以外，還提到了一個作者自己重新發明的超簡潔版 Qcss 語法。它有個騷操作是通過 Service Worker 在瀏覽器端 parse 樣式，從而達到近 50% 樣式表體積的縮減。這個挺有意思，就是當時太急了有兩個槽想吐……
- 如果一個頁面減少 50% 的 CSS 體積對效能有影響，那麼以這個頁面佈局的複雜度之高，估計在靜態資源和業務邏輯上還會有更大的效能瓶頸可以優化吧?
- 為什麼對推薦 Less over Sass 的理由是「Less 的語法可以少寫小括號」呀……我大 Stylus 瘋起來連花括號、分號和冒號都可以不寫呢?
請不要在意我的吐槽，畢竟大佬的分享氣氛還是非常活躍的，全程其實都是這個其樂融融的畫風：
接下來是大漠老師的分享《探索動效開發模式》了。提到動效雖然大家首先想到的是 CSS 的實現方式，但大漠老師分享的格局顯然不僅限於此，比想象的高屋建瓴得多：
分享中非常強調動效開發的設計工具支援、素材管理、資料驅動等概念，最後的效果是讓前端同學無需編碼或僅僅編碼業務邏輯（而非動效本身），就能實現設計同學的想法。這背後的工具鏈相當長：
首先需要支援 AE 和 Dragon Bone 等上游編輯工具的格式，這方面雖然 Airbnb 的 Bodymovin 相當給力，但仍然有不少自己填坑的地方。而前端的渲染部分坑也比我想象的大不少：
看到圖以後有些慶幸自己沒真正開始填一個從 Shader 開始往上寫的 Renderer 坑，果然還是太年輕啊。
接下來到了茶歇時間，提問大漠老師邊上的粉絲貌似也是最多的：
我也剛好趁這個時候蹭了一波熱度，請教了大佬關於 CSS 作用域支援的一些問題。剛好這個問題和 Web Component 和 Vue 都有些淵源，遲了一波大佬們熱情的解（an）答（li）。好吧我只是來順便蹭圖的（
蹭完圖以後發現作為前端會議，主辦方非常政治正確啊：
- 掛綠色（Vue）的帶子是講師。
- 掛藍色（React）的帶子是我等吃瓜群眾。
- 掛紅色（Angular）的帶子是低調的工作人員。
hmmmm……
扯完回到會場，發現我好像錯過了鵝廠小哥的 CSS 黑科技分享……補個圖大家感受下吧。現場 coding 用一個 div 畫出的水波紋特效還是挺有趣的?
然後是一絲姐姐，欸沒看到女裝生氣不聽了（其實氣氛特別活躍，提問的同學特別多）。可惜是我自己對移動端了解比較淺，提不出什麼有意義的問題……
最後的分享是來自我司（歡樂逛）城管大隊長的 CSS 黑魔法分享?
其實我的 CSS 水平基本只有 flex 搭積木的程度而已，城管丟擲來的一個個「奇技淫巧」我很多基本沒有聽說過，一系列的黑魔法讓我充分認識到我在團隊裡的菜雞水平 XD
和之前講解 CSS 特效偏向 Demo 化分享思路不同，城管的介紹更側重在實際專案裡使用 CSS 技巧所解決的問題。畢竟要有了實際的案例背書，我們才會更「安心」地把這些技巧落地到專案中去。這個編輯器專案本身已經產品化了，大家可以戳這裡感受一下。
另一個很有意思的地方是這張 CSS Zen Garden 的圖。
CSS Zen Garden 應當是更符合 Web 承載文件的初心的。在現在這個 Web 應用興起的時代，Zen Garden 似乎已經逐漸被遺忘了啊……懷念大學圖書館上印刷精美的《CSS Zen Garden》，也算是我前端的啟蒙讀物之一吧。
對了，城管還是帶家室參會的，可以說非常人生贏家了…
到這裡為止 CSS 大會的分享就告一段落了。作為一個小小的總結，我個人的感想是 CSS 確實已經相當成熟了，而且純 CSS 領域的圈子並不大，以至於許多演講者所分享的技巧都會出現或多或少的重疊。並且，CSS 的初心應當是一門用於排版的 DSL，只是它的功能歷經多年的演化已經非常繁多，這才出現了各種令人眼花繚亂的黑魔法。但由於它一開始的設計目標所限，找出某個冷門屬性 hack 出一個神奇效果固然很爽，但你並不能保證下次還能找到類似的神奇屬性來滿足無盡的互動需求：這多少讓前端缺乏了一點安全感啊。
好在我們在這屆大會上看到了 CSS Houdini 一類這樣在傳統的宣告式樣式之外，為渲染過程引入更多定製性的努力。以前尋找黑魔法屬性的過程，有些像尋找微分方程的特解，而更強的表達力與更完善的工具鏈則像是尋找出具有普適性的通解。如果我們能為各種複雜的特效找到通用的開發模式，相信 Web 上能承載的內容還能更加驚豔?
最後是我司（歡樂逛）的小夥伴合影，數數有幾個前面出現過的身影呢?
One More Thing，其實你或許已經發現了，前端圈的技術會議大概已經不是過來單純聽人講 PPT 的了，溝（shang）通（ye）交（hu）流（chui）才是正經事：
「我是用著你的 font-spider 長大的啊」
「我是看著你的部落格長大的啊」
?