原子CSS的製作：對Thierry Koblentz的採訪

本文訪談了Atomic CSS 的創建者Thierry Koblentz，深入了解了這款流行CSS 框架背後的歷史和背景。 Thierry 現已退休，在大型CSS 編寫方面擁有豐富的經驗，曾擔任雅虎的前端工程師。

Thierry 因其2013 年發表在Smashing Magazine 上的經典文章“挑戰CSS 最佳實踐”而被廣泛認為將Atomic CSS 的概念帶入了主流。這篇文章為多年來許多流行的CSS 庫鋪平了道路。在本訪談中，Thierry 回顧了Atomic CSS 的歷史，並反思了其持續的影響。

回到21 世紀初，您是如何進入Web 開發領域的，特別是如何以編寫CSS 為生？

Thierry Koblentz： 1997 年搬到美國後，我自學了HTML、CSS 和JavaScript 作為愛好。

當時，我使用的是FrontPage，並且嚴重依賴新聞組來尋求指導。我很快成為Macromedia 新聞組和CSS-Discuss 的常客。早期，我支持Web 標準項目理念，並對無障礙性產生了濃厚的興趣。多年來，前端對我來說只是一個愛好（我的真正工作是古董商）。我會偶爾創建一個網站，但我主要是在撰寫和發表（許多）文章，分享我學習或“發現”的技術。

這為2007 年雅虎的電話帶來了回報，詢問我是否可以幫助修復和構建Yahoo! 網站解決方案(YSS) 網站構建器模板的樣式表。職位描述：沒有HTML，沒有JavaScript，只有CSS！而且很多！

您在雅虎的日常工作是什麼樣的？

TK：多年來，我在雅虎的角色發生了很大變化。

我的第一份工作是為YSS 模板創建樣式表（類似於CSS Zen Garden）。然後，在YSS “交付”到班加羅爾（印度）之前，我重寫了YSS 網站的標記和样式——我和我的同事被派往那裡進行“知識轉移”。

順便說一句，正是更換樣式表以創建YSS 的不同設計的挑戰迫使我們找到一個輕量級（非js）的解決方案來即時調整視頻大小；這就是我提出“為視頻創建內在比例”的方式。

在YSS 之後，我有機會只參與從頭開始的項目（重寫或其他），我越來越多地參與雅虎前端工作。我編輯和創建了許多內部文檔（即CSS 編碼標準）；參與招聘流程（就像我的團隊中的其他人一樣）；領導代碼審查會議；開設CSS 課程和研討會；在FED London 發表演講；幫助其他團隊處理HTML/CSS/無障礙性問題；參與技術採用方面的決策（例如Bootstrap 或非Bootstrap）；創建庫；審查內部論文；撰寫提案；等等。

另一個補充說明，在我雅虎的八年時間裡，我可能寫不到100 行JavaScript 代碼。如果我沒有辭職或被解僱，這要感謝Lingyan Zhu 和Renato Iwashima；他們在設置我的環境或處理命令行方面不知疲倦地幫助了我（因為直到今天，我仍然很糟糕）。

當時流行的CSS 編寫實踐是什麼？

TK：在早期，既沒有庫也沒有已發布的方法；那是蠻荒的西部，一切都可以：“非語義”類、ID、CSS hack、條件註釋、框架、CSS 表達式、“JS 探測”、主要針對Internet Explorer 進行設計等等。在我的舊網站上，我甚至有這樣的評論：

<code></code>

一切都是公平競爭，一切都被濫用，因為我們只有一套非常有限的工具，卻需要做很多事情。

但是，當我加入雅虎時，情況發生了巨大的變化。來自英國的開發人員是Web 標準的堅定支持者，我感謝他們極大地影響了雅虎的HTML 和CSS 的編寫方式。語義標記是一個現實，CSS 是按照關注點分離(SoC) 原則編寫的“T”（儘管有時對我來說過於熱衷）。

YUI 有CSS 組件，但還沒有CSS 框架。有一個內部CSS 庫（稱為Lego），但我從未使用過它。 OOCSS、SMACSS、ECSS（向Ben 致敬）、BEM、Bootstrap、Pure 等方法和庫不久之後就會出現。

Atomic CSS 的想法是如何產生的？

TK:在YSS 遷移到印度之前，我的經理Michael Montesano 詢問是否有辦法讓班加羅爾的團隊避免編輯樣式表，從而降低損壞的風險。我想YSS 模板的經驗（付費客戶抱怨頁面損壞）讓他在對樣式表進行任何更改時都非常偏執。

因此，我本著我的ez-css 庫的精神創建了一個“實用程序表”——一個旨在讓開發人員實現其樣式而無需編輯或在樣式表中添加規則的表。

幾年後，時任工程總監的Michael 詢問我是否可以使用僅實用程序類重新設計雅虎的主頁，因為他知道，我們再次不會負責網站維護。我們討論了優先考慮實用程序類而不是語義類，我認為當時這種程度的事情並不存在。這是一個非常大膽的舉動。

這項大規模的練習很快成為一項概念驗證，展示了通過標記進行樣式設置帶來的許多好處。它檢查瞭如此多的框，以至於我們決定使用該“靜態”樣式表（稱為Stencil）來重新設計Yahoo! 我的主頁產品。

設計Atomic CSS (ACSS) 時遵循的指導原則是什麼？有哪些人參與其中？

TK：我們的Stencil 庫是靜態的，這是一個強制執行設計風格的絕佳工具——我們認為雅虎即將在其所有屬性中採用這種風格。我們很快意識到這不會發生。每個雅虎設計團隊對完美的字體大小、完美的邊距等都有自己的看法，我們不斷收到添加非常具體的樣式到庫中的請求。

這種情況是無法維護的，因此我們決定開發一個工具，讓開發人員能夠即時創建自己的樣式，同時尊重創作方法的原子特性。這就是Atomizer 的誕生方式。我們停止了添加樣式——CSS 聲明——而是專注於創建豐富的詞彙表，為開發人員提供廣泛的樣式，例如媒體查詢、後代選擇器和偽類等等。

使用ACSS，開發人員可以自由使用任何他們想要的東西；因此，團隊能夠在使用完全相同的庫的同時採用不同的設計樣式和样式指南。並且有一些對開發人員過去習慣的樣式編寫方式來說是新的直接好處。他們不再需要擔心他們的樣式會破壞頁面，也不需要擔心編寫選擇器來為他們的組件設置樣式。

ACSS 最初是為解決雅虎的問題並在雅虎的環境中工作而構建的。

參與Atomic CSS 的人員包括Renato Iwashima、Steve Carlson 和我自己。 Renato 和Steve 創建了Atomizer。

當人們不為大型企業編寫CSS 時，他們對CSS 有哪些誤解？

TK：當我2007 年加入雅虎時，我很快了解到代碼庫可能有多麼龐大。有跨許多地點/時區的團隊；無數的產品；數百個共享組件；第三方代碼；A/B 測試策略；作為一項要求的擴展；不同的腳本方向；本地化和國際化；各種發布週期；複雜的部署機制；大量的指標；各種遺產；嚴格的編碼標準；構建流程；政治；以及更多政治；等等。

其中大部分對我來說都是全新的，我必須學習它是否以及如何影響我編寫CSS 的方式。我開始重新審視和挑戰我所有的信念，因為許多對我來說是常用做法的技術或方法似乎不適合，或者至少對複雜的應用程序適得其反。

一項“現實檢查”與樣式抽像有關。我們都讀過文章說，將M-10 類映射到margin: 10px 不是一個好主意，因為它意味著要同時編輯HTML 和CSS才能更改樣式。不幸的是，這就是大型/複雜項目中發生的情況：

• 設計師：我想要15 像素的間隙
• 開發人員：好的，那是M-3x（5 像素增量）
• 設計師：當然，隨便！
• 開發人員：完成了！
• 設計師：實際上，15 像素有點太大，你能把它改成12 像素嗎？
• 開發人員：不，我們沒有那個，要么是10 像素，要么是15 像素。
• 設計師：對不起，這對我來說不起作用。我們可以將M-3x 更改為12 像素嗎？
• 開發人員：不行！我們不能那樣做，因為其他團隊期望M-3x 為15 像素。
• 設計師：好的，試著想辦法，因為我們希望邊距為12 像素。 15 像素太多了，10 像素太少了。
• 開發人員： （去死吧！）

為了預測這樣的問題，需要了解設計師在其請求背後的意圖：選擇的樣式是因為其抽象，例如顏色primary，還是因為其特定值，例如在我們的M-3x 案例中的15 像素邊距？如果存在樣式指南來強制執行設計原則，那麼像M-3x 這樣的類可能沒問題，但是如果設計團隊可以請求他們想要的任何樣式，那麼最好避免使用會導致模糊樣式的命名約定。根據我的經驗，任何模棱兩可的事情都會導致損壞。

依賴文檔或組件的結構來進行樣式設置——通過組合器如> 或——聽起來像是編寫樣式表的一種簡潔方法，但它忽略了一個事實，即在復雜的環境中，不能假設任何特定的標記或結構是不可變的。

你認為z-index 很複雜嗎？當你甚至不擁有你的組件所在的堆棧範圍時，再想想看。這是大型項目中需要解決的最複雜問題之一，在大型項目中，團隊負責頁面的不同部分。我曾經寫過一篇關於這方面的提案。

限定選擇器——例如input.required 與.input.required——看起來不錯且具有語義，但它會創建不必要的特異性級別——例如0.1.1 與0.2.0——並阻止標記更改；通過確保不限定選擇器，很容易避免這兩件事。

依賴通配符選擇器* 來設置全局範圍的樣式？在一個非常大的項目中，這可能意味著你正在設置其他人的組件的樣式。除非你了解他們的需求，否則不要為他人做出樣式決策。

我相信你讀過ID 不好，特異性很糟糕，但是。事實上。高特異性不如你的規則創建的特異性級別數量那麼成問題。在一個只有兩三個級別存在的環境中進行樣式設置要容易得多——例如1.1.0、0.1.0、0.2.0——而不是在一個特異性相當低但遵循“自由競爭”方法的環境中——例如0.1.0、0.1.1、0.2.0、0.2.1、0.2.2 等——這通常作為大型項目中的防禦機制出現，作為“沙盒”樣式的一種手段。

盲目遵循CSS 社區的建議可能會導致令人不快的意外。永遠不要採用尚未經過實戰檢驗的新技術。還記得will-change 嗎？並且始終了解你使用的每種樣式的作用或可能觸發的作用。例如，position 可以創建一個堆疊上下文和一個包含塊，而overflow 可以創建一個塊格式化上下文。

根據我的經驗，深入了解CSS 對於大型組織高效編寫CSS 來說還不夠。在我雅虎任職期間，我經常發現自己與幾年前曾經與我一致的人們相矛盾。環境非常殘酷，需要非常務實才能避免許多陷阱。下次你查看大型項目的源代碼並看到一些對你來說毫無意義的東西時，請記住Nicholas Zakas 的這條推文：

不要假設人們是愚蠢的、無知的、犯了錯誤，假設他們是聰明的、盡力而為的，而你缺乏背景。

— Nicholas C. Zakas (@slicknet) 2013 年2 月10 日

雅虎向Atomic CSS 的過渡在內部是如何被接受的？

TK：我們的我的主頁團隊很好地接受了ACSS，但在外部卻進展不順利。我們第一次互動是與位於聖莫尼卡的體育團隊。 Steve 和我在一次電話會議上試圖說服開發人員，不遵循關注點分離原則才是正確的做法，並且不會造成混亂。

我們向他們指出了Nicolas Gallagher 最近寫的一篇文章，認為來自“外部人士”的文章會有所幫助，但不行！事情進展不順利，摩擦很多。主要問題是該庫是由實用程序類組成的，但其語法並沒有幫助緩解對話。

我還記得與郵件團隊會面，他們並沒有反對Atomic CSS 的想法，但希望提出他們自己的JavaScript 方法來使用“普通”CSS 聲明——因為他們無法忍受ACSS 語法。無論如何，支持該庫的數據（約減少36% 的CSS 和HTML）本身就說明了一切，因此最終採用了ACSS。而今天，七年多後，雅虎主頁、雅虎體育、雅虎新聞、雅虎財經和其他雅虎產品仍在使用ACSS。

為了更好地理解像ACSS 這樣的方法如何使組件可重用性至關重要的項目受益，請從雅虎財經復制組件的標記，並將其粘貼到雅虎新聞中。該組件應該看起來像是屬於該頁面的一部分。這是因為ACSS 使這些組件與頁面無關。

圓括號作為類名的方法是如何產生的？語法是否受到函數編寫方式的啟發？

TK：我們已經通過多次迭代確定了兩組用作屬性值分隔符的“候選者”：圓括號() 和方括號[]。

Renato 回憶說，我們選擇圓括號而不是方括號是因為熟悉JavaScript 中的函數，即使是以犧牲額外的Shift 鍵擊為代價。 ACSS 語法旨在：

• 通過Atomizer 促進規則的自動生成
• 允許開發人員創建他們想要的任何任意或複雜的樣式
• 將學習曲線降到最低

它看起來像這樣：

 <code>[<context> [:<pseudo-class> ]<combinator> ][(<value> ,<value> ?,...)][][:<pseudo-class> ][::<pseudo-element> ][--<breakpoint_identifier> ]</breakpoint_identifier></pseudo-element></pseudo-class></value></value></combinator></pseudo-class></context></code>

開發人員按照上述結構構建他們的類。核心語法基於流行的工具包Emmet。我們採用了Emmet 方法來減少特性，因為核心類是顯式的屬性/值對，而不是任意字符串。

我們還創建了十幾種輔助類。這些應用多個樣式聲明，並且要么是快捷方式，例如隱藏有視力障礙的用戶的內容，要么是hack，例如使用.Cf 進行clearfix。我們還通過使用配置文件為開發人員提供了更多自由度，在配置文件中他們可以創建變量——例如.PrimaryColor——斷點等等。

從未使用過ACSS 的人會告訴你，語法太奇怪了（充其量），但熟悉它的人會告訴你它在很多方面都很巧妙。

談談您為Smashing Magazine 撰寫的“挑戰CSS 最佳實踐”文章是如何實現的？

TK：我之前在各種在線出版物上寫過很多文章，所以寫一篇關於這種“挑戰性”方法的文章是很自然的。

雅虎在2013 年10 月贊助了一場前端會議，Renato 在會上安排了一次演講來介紹我們的解決方案，我試圖在那之前發表這篇文章。我選擇不將其發佈在Yahoo! 開發者網絡上，因為該網站沒有提供評論部分。 A List Apart 無法及時發布它，但Smashing Magazine 加快了其審查流程，以便能夠在10 月底之前發布這篇文章。

我選擇一個有評論部分的出版商的做法得到了回報，因為這篇文章收到了200 多條評論，這對我來說非常耗時——而且令人沮喪——我不得不回复這些評論。

這篇文章仍然帶有關於所討論技術的免責聲明，即使它現在在業界已經很流行了，這感覺奇怪嗎？

TK：當文章發表時，我告訴Vitaly [Friedman，Smashing Magazine 聯合創始人]，那張便條聽起來像某種免責聲明；這會影響人們閱讀文章的方式。但我並沒有真正反駁，因為我理解Vitaly 的想法。我確實覺得這張便條仍然存在很有趣，現在這種方法已經成為主流了。

鑑於事後諸葛亮，您想更改Atomic CSS 的哪些方面？

TK：總有改進的空間，尤其是在你開創了這個解決方案之後。你不能去看別人做了什麼來學習他們的錯誤或缺點。你沒有改進的材料。因此，如果我們認為我們第一次就成功了，那將是自負的。

在Atomic CSS 方面，我們擁有豐富的經驗，因為我們在大型項目中使用了“靜態”樣式表一年多。但在動態方面——工具方面——我們好像找不到多少靈感。記住，其他庫花了六年時間才效仿。

用法語來說，我們說： essuyer les plâtres 。 （擦拭灰塵）

我們犯的一個錯誤是使用“Atomic CSS”作為acss.io 的標題，因為正如John Polacek 指出的那樣，這造成了一些混淆。從那時起，我們就更改了該標題。

我唯一後悔的是社區多年來是如何對待Atomic CSS/ACSS 的，這最近導致了一次奇怪的交流，有人向我解釋了“Atomic CSS”的含義：

Atomic CSS 庫[ACSS] 使用了這個名稱，但我認為這具有誤導性，因為你正在談論的功能是動態樣式生成。 “Atomic CSS”作為一個通用術語，將小的選擇器指定為原子，但它們是靜態的。

談論被抹去。 ;)

非常感謝Thierry 參加這次採訪，並允許我們將其發布給社區。

以上是原子CSS的製作：對Thierry Koblentz的採訪的詳細內容。更多資訊請關注PHP中文網其他相關文章！