摘要：我們都知道您是國內知名的專家，是什么樣的情結使得您愿意將魔法作為自己的別名大家好，很榮幸接受圖靈的專訪。在這一堆書里，有一套上下冊教程叫作談是由圖靈引進的哦。從偶像那里得來一個名字，很榮幸而且這其中也有圖靈的功勞，也是緣份。

非商業轉載請注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/article/216538

圖靈訪談非常有幸能邀請到“魔法哥”，進行一期專訪。我們都知道您是國內知名的 CSS 專家，是什么樣的 “CSS情結” 使得您愿意將 “CSS魔法” 作為自己的別名？

大家好，很榮幸接受圖靈的專訪。我叫 “CSS魔法”，熟悉我的朋友都叫我 “魔法哥”。 這個問題問得好，瞬間把我的思緒拉回八年之前——那時我剛開始系統地學習前端知識。當時為了找一份前端工作，我把市面上所有的 CSS 書籍全部買來，全部啃光，迅速且系統地掌握了 CSS 的基礎知識。

在這一堆書里，有一套上下冊教程叫作《Eric Meyer談CSS》（是由圖靈引進的哦）。我記得很清楚，書里有這么一段話：“在準備好語義化的結構之后，我們再給它施加一點兒 CSS 魔法……” 我當時感覺這句話正好契合 CSS 帶給我的體驗！

我很喜歡 CSS 這門技術，它優雅、神奇、充滿魔力，短短幾行代碼就可以讓我們的網頁脫胎換骨、煥然一新。于是從那時起，我就開始使用 “CSS魔法” 這個網名了。以這個名字注冊了微博，后來還創建了 “CSS魔法” 微信公眾號，分享自己在前端領域的學習經驗；在為圖靈翻譯《CSS揭秘》一書時，也很自然地以此為筆名了。

說到 Eric Meyer，他還是《CSS權威指南》的作者，也是我的偶像。從偶像那里得來一個名字，很榮幸；而且這其中也有圖靈的功勞，也是緣份。 請簡單介紹一下您在百姓網的工作內容吧！

我目前在百姓網擔任手機站的前端架構師。比較尷尬的是，“前端架構師” 這個頭銜經常遭遇質疑：“前端居然也需要架構？” 所以我也趁這個機會闡述一下，我理解中的前端架構到是什么。

其實不管是前端還是后端，任何一項嚴肅的、長期的、大規模的工程，都是需要有人來設計架構的。

百姓網的前端架構目標很明確：隨著業務規模的擴張和團隊的壯大，整個網站系統的復雜度也隨之迅速上升；如何化繁為簡、幫助業務工程師高效高質完成開發任務，這正是前端架構師的職責和挑戰所在。

因此，簡單概括一下，我在百姓網所做前端架構工作包括：

編寫工具庫和 UI 框架，并提供文檔，提升業務開發效率

優化開發流程，提升業務工程師的開發體驗

制定各類開發規范，并通過工具來確保規范的執行

調研新技術、新工具，并適時應用推廣

組織定期的技術交流會和不定期的技術分享

……

看來“魔法哥”要全面把握開發流程，規劃框架，制定規范。那平時還需要寫代碼嗎？

其實，長年重構代碼也都是份內事，偶爾還需要投身業務開發。畢竟架構層作為業務層的堅實后盾，松懈不得?。?/p>

您覺得哪些 CSS 知識是必須掌握的？

對一個專業的 CSS 開發者來說，首先，CSS2 的核心知識必須完全掌握。以《CSS權威指南》（第三版）為例，除了 “聲音樣式” 之外，這本書的所有內容都是應該透徹理解的。即使記不住某些冷僻屬性的名稱與行為，也需要知道在哪里可以快速查閱。

接下來，關于 CSS3，很多同學都問過我這樣一個問題：“魔法哥，現在瀏覽器都支持 CSS3 了，我跳過 CSS2 直接學 CSS3 可以嗎？”

在回答這個問題之前，我們需要先搞清楚 “CSS3” 到底是什么。讀過《CSS揭秘》這本書的同學應該都很清楚了，“CSS3” 是一個俗稱，并不是 W3C 的官方術語。基本上它是CSS2 之后更新或新增的 CSS 規范模塊的合稱。

實際上，CSS3 相對于 CSS2 并不是類似軟件版本更替那樣的升級。CSS2 的全稱是 “CSS Level 2”，后續的 CSS 規范并不是完全以替代品的形態出現的，某些 Level3 的 CSS 規范模塊（或新增的規范模塊）往往是基于 CSS2 來擴展的。

因此，對于 CSS 學習者來說，如果買了一本只講 CSS3 新增內容的教程或參考書，那還需要搭配 CSS2 的書來看。事實上，由于篇幅所限，市面上絕大部分以 “CSS3” 為賣點的圖書確實都不會重復講解 CSS2 的內容?？吹竭@里，相信上面的問題在大家心中已經得出答案了吧。

我自己的學習路徑是這樣的：通過《CSS權威指南》和《精通CSS》等 CSS2 時代的經典教程來打好 CSS2 的基礎（因為 CSS2 已經完全穩定了）；對后續新技術和新規范的了解和掌握，通常求助于 MDN 等在線資源（因為變化相當快）。如果新入門的同學面對龐雜的 CSS 體系感覺無從下手，不妨參考這條路徑。

有圖靈社區網友提問：您在工作中常用的 CSS 實用技巧有哪些？

首先，我會毫不猶豫地推薦大家使用 CSS 預處理器。由于 CSS 并不是編程語言，并不具備抽象能力，當網站的規模發展到一定程度之后，原生 CSS 很難解決抽象與復用的問題。而預處理器則正好彌補了 CSS 在這方面的不足。

即使你不打算學習預處理器的特有語法，甚至還有些排斥，那也不妨嘗試利用它的模塊機制來拆分和組織代碼。由于預處理器大多兼容 CSS 原生語法，因此你可以保持原來寫代碼的習慣，僅利用預處理器在模塊化方面的功能。

對于多人合作的團隊來說，通過模塊來拆分代碼尤為重要。雖然引入預處理器會要求你在工作流中加入構建環節，但我認為這個成本是完全值得的。

接下來，想跟大家分享的經驗就是：做好 CSS 代碼的 “分層”。我設計的 CSS 架構通常都會由 “Normalize + Reset → 通用基礎樣式 → UI 組件 → 頁面通用的布局框架 → 單個頁面的布局和樣式” 這幾個層級構成，越往左越靠近架構，越往右越靠近業務。

劃好層級并把代碼寫到正確的層級去，可以帶來很多好處：在團隊分工上，可以把不同層級的代碼交給不同的人來開發和維護，相當于關注點分離；從架構角度來看，也可以實現 “控制復雜度” 這一重要目的。

還有就是善用工具。比如通過 Lint 程序來保障代碼規范的執行，通過構建工具來讓重復勞動盡可能自動化，通過 Autoprefixer 這樣的工具來加工或生成代碼，等等。俗話說，磨刀不誤砍柴工，多看多聽多試，用開放的心態去了解和嘗試新工具，往往會有不錯的收獲。

如果這位網友想問的是 “有哪些實用的 CSS 特性”，那我覺得至少要提一下 Flexbox。它是 CSS3 引入的更強大、更易用的布局方式，而且我們在移動端已經可以安全地使用 Flexbox 的基礎特性了。其它的特性，比如高級選擇符、漸變、動畫等高級特性，也非常有價值，我在編寫 UI 框架時都有實際應用。

此外，大家可能還想了解在編寫 CSS 時需要掌握的原則和思路。這里我會推薦《CSS揭秘》這本書中的“CSS 編碼技巧”一節。我一直想寫篇文章來講述自己多年積累的 CSS 經驗，但一直苦于找不到合適的切入點，總怕掛一漏萬。而當我讀到這一節時終于釋然——原來已經有人幫我做了這件事情！隨后我也將它親手翻譯了出來，也算了卻了一樁心事。

前端領域的技術更新非?？?，常常是一門技術還沒學明白，另一門技術又火了，你是如何取舍的呢？

確實，近些年前端領域的新技術、新工具、以及新的實踐方式都層出不窮，稍不留神就會有落伍的感覺。而每個人精力都是有限的，面對這樣的局面，難免會有一種疲于奔命的壓迫感。

我自己的應對方式是抓住核心，放棄自己很難精通的、一時用不到的、或者對當下想做的事情價值不大的技術方向。比如一路以來，我放棄了富媒體方向的 Flash，放棄了圖形與游戲方向的 Canvas 和 WebGL，放棄了單頁應用方向的 MV*，放棄了語言方向的 FP ，等等。

當然這些 “放棄” 都是戰略性的，而不是永久性的。畢竟精力有限，不可能面面俱到。不過，一旦某個方向變成自己必須攻克的戰略要地，那我也必然會義無反顧躍入新坑。

除了在技術范疇內作取舍，我還會把一部分精力放在 “人” 身上——就是寫代碼的這群人。個人英雄的時代一去不復返了，單打獨斗能力再強，也難成氣候。因此，幫助身邊的小伙伴快速成長，打造一支梯隊完備、技能互補的前端開發團隊，往往更具現實意義。有些時候，這也可以成為一種 “突破瓶頸” 的解決方案——每當團隊里的小伙伴攻克了某項新技術時，我都可以寬慰自己：我不會，沒關系，有小伙伴可以頂上！

有圖靈社區網友提問：CSS 與它的小伙伴兒 JavaScript 的關系是怎樣的？有什么共同點和差異？

哇噢，這個問題完全是面試題的既視感啊！好的，我來好好回答一下，重溫被面試的感覺。

根據 Web 標準的 “分離” 原則，網頁界面由三層構成：結構層、表現層、行為層。這三者在技術上分別由 HTML、CSS、JS 來實現。大家都知道有句話叫 “術業有專攻”，在網頁上也是一樣，不同的層應該由不同的技術來實現。

在近些年，CSS 的能力得到了不少提升，比如 :hover 偽類的增強以及 :checked、:target 等新偽類的出現，令原本只能由 JS 實現的交互功能也可以用 CSS 來實現了。這意味著，在某些場景下，這兩者的功能有重疊的地方。

不過從原理上來說，CSS 只具備修改渲染樹的能力，無法修改 DOM 結構（“渲染樹” 是指 DOM 樹在應用樣式之后產生的、用于渲染網頁界面的數據模型）。CSS 可以通過 display、visibility、opacity 等屬性來控制元素的顯隱，但無法把元素從 DOM 樹上刪除或移動，也無法創建新的 DOM 元素。這是 CSS 的能力邊界。

雖然這兩者的功能有一些重疊，但它們并不是互斥的。JS 和 CSS 是可以合作的，而且我們應該擅用這種合作關系，發揮各自所長。舉例來說，CSS 的聲明式特性比較簡單易懂，在管理樣式方面更加易于書寫和維護。因此，在實現某些動態效果的時候，我們可以把不同狀態的樣式以類的形式寫在 CSS 中，然后讓 JS 通過切換元素的類來實現樣式的變化。

有圖靈社區網友提問：鑒于 CSS 擅長處理復雜布局和絢麗的視覺效果，眼下 Web 開發者可以跳過 JavaScript，走 “UI + 后端” 的路線么？

簡單地說：不可能。

首先說一下 “UI” 這個概念。UI 并不是靜態的布局和樣式，不是設計師發給我們的 PSD 圖像。UI 是用戶界面，它的核心是交互，而交互需要由 JS 來實現。交互以及交互傳達出的用戶體驗，才是眼下前端的核心價值。

接下來，我們回到實際的開發場景中來看待這個問題。如果是團隊作戰，那么團隊中的個體當然可以有所側重和取舍。在整個技術棧中，自己放下的某個環節只要有小伙伴可以頂上，那就沒啥大問題。不過如果是打算通吃前后端的全棧工程師給自己做職業規劃，那么 JS 是繞不開的。

其實在圖靈社區里，我跟這位提問的網友已經有過交流。他回避 JS 的原因主要在于入門時被網上的低劣教程所誤導，對 JS 留下了錯誤的第一印象，進而心生抵觸。

這位網友的經歷讓我十分惋惜，同時也不由地深深感嘆：我們在學習一門技術時，選擇規范、系統的學習途徑是多么重要??！所以這里要再一次鄭重推薦圖靈的程序設計叢書，魔法哥信賴之選！

有圖靈社區網友提問：您是否贊同將前人留下的技巧直接運用到自己的項目中？是否需要 “知其然、知其所以然” 的研究精神？

這要看你給自己的定位是什么。我認為技術工作者大致可以分為兩類。第一類人單純被技術本身所吸引——相信我們都有感觸，技術本身就有一種迷人的美！而第二類人把技術作為手段，他們學習技術的最終目的是通過技術來推動一些事。這兩種技術人都有各自合理的出發點，并沒有孰對孰錯之分。

那么，如果你是第一類人，那你對自己的規劃和定位必然是某個領域的技術專家。所有有價值的技術都應該被你吃透，而且相信你自己也會有源源不斷的強烈興趣，去把這些技術掰開了、揉碎了研究到極致。

而如果你是第二類人，那么 “知其所以然” 就不是必須的了。尤其是在團隊中，你可以把 “知其所以然” 的任務交給技術專家，把有限的精力投入到更適合自己的地方去。

回想自己一路以來的經歷，能否給前端初學者分享一些學習經驗？

我這些年寫博客始終以初中級開發者作為主要受眾，創建的“CSS魔法” 微信公眾號也仍然關注前端初學者群體。因此可以聊的經驗有很多，最重要的應該是——“系統學習、打好基礎”，因為真正基礎的東西是不會過時的。

我也曾模仿別人網站的代碼，或是在網上收集別人發表的各種技巧，然后把找來的一句句代碼拼湊在一起。雖然這種方法通常也可以生效，但我完全不知其所以然，那些代碼片斷對我來說無異于外星人的咒語。由于無人指導，無法系統地學習知識，當時的狀態就像是在黑暗的迷宮中摸索一樣。

當時在書店里能找到的相關書籍也無非是一些迎合國人 “短平快” 心理的快餐書，什么“現學現用”“代碼速查 300 例” 之類。我是一個喜歡打破沙鍋問到底的人，這些沒頭沒尾的所謂技巧顯然無法滿足我的好奇心，失望而歸。

幾年之后，以圖靈為代表的科技圖書公司開始引進國外的經典教程和參考書。當《精通CSS》《JavaScript 高級程序設計》這些著作捧到我手上時，你可以想像我當時有多么欣喜若狂。

在瘋狂求知的過程中，我發現，前些年我在網上費盡辛苦收集到的珍稀黑魔法，其實在書里都有著更加全面和系統的講解。當我穩固地掌握了 HTML、CSS、JS 的基礎知識之后，我驚訝地發現，原先那些看似神奇、背都背不下來的外星咒語，早已融入我的血液，成為信手拈來的本能。

現在的孩子們是幸福的，你們生活在一個信息通暢、資源富足的時代。因此不需要眼巴巴地乞求 “大神們” 施舍只言片語的秘技，只要多讀幾頁書，你也可以成為別人眼中的大神！

十分感謝魔法哥花費寶貴的時間接受圖靈的專訪，深入淺出，鞭辟入里！

我也很高興今天跟大家聊了這么多，我們下次再見!