CSS 魔法：學海無涯，而吾生有涯

非商業轉載請註明做譯者、出處，並保留本文的原始連接：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 框架，並提供文檔，提高業務開發效率

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

• 制定各種開發規範，並經過工具來確保規範的執行

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

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

• ……

看來「魔法哥」要全面把握開發流程，規劃框架，制定規範。那平時還須要寫代碼嗎？

其實，終年重構代碼也都是分內事，偶爾還須要投身業務開發。畢竟架構層做爲業務層的堅實後盾，鬆懈不得啊！

您以爲哪些 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 的基礎知識以後，我驚訝地發現，原先那些看似神奇、背都背不下來的外星咒語，早已融入個人血液，成爲信手拈來的本能。

如今的孩子們是幸福的，大家生活在一個信息通暢、資源富足的時代。所以不須要眼巴巴地乞求 「大神們」 施捨隻言片語的祕技，只要多讀幾頁書，你也能夠成爲別人眼中的大神！

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

我也很高興今天跟你們聊了這麼多，咱們下次再見!

---

更多精彩，加入圖靈訪談微信！