2018 CSS 大會多圖見聞錄

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 長大的啊」

「我是看着你的博客長大的啊」

😅