《CSS 揭祕》作者Lea Verou：我喜歡分享開源的行業文化（圖靈訪談）

Lea Verou
W3C CSS工作組特邀專家，設計CSS語言的委員之一，此前曾在W3C擔任開發者代言人。目前，她在麻省理工學院從事人機互動領域的研究。她還是一位部落格作家，並經常在國際性的技術會議上擔任講師；她建立的多個開源專案廣受開發者歡迎。

-圖說-
來自CSS一姐的個人網站（http://lea.verou.me），也多用於各種公眾場合，例如本書的作者介紹部分。

-圖說-
Lea的運動照，愛游泳。

-圖說-
Lea自己設計的圖示，常見各種公眾場合，包括本書的封面。

訪談內容：

英文版

非常榮幸能夠邀請到暢銷書《CSS 揭祕》的作者Lea Verou，進行一期圖靈專訪。請問Lea寫這本書的初衷是什麼？讀者應該怎樣閱讀本書？

市面上有很多CSS的書，有全面講解CSS各方面知識的，也有專注介紹某一方面的。但是，沒有一本書教會讀者怎樣運用CSS創造性地思考、解決問題，也沒有一本書可以跳過最開始的簡介部分。

概括來講，這似乎是學習新知識時的一個普遍問題：大多數圖書只會提供陳腐、老掉牙的解決方案，卻不會嘗試向讀者介紹如何獲得自己的解決方法。說到CSS方面的書，作者們總是想當然地認為讀者都是些“技術小白”，也就想當然地架構起內容。《CSS 揭祕》這本書呢，尊重語言和讀者，沒有簡化內容。CSS高階開發人員以及真正理解CSS是如何工作卻想進一步提高知識的人，會從本書中獲益最多。

《CSS揭祕》封面的右下角有一個類似海盜標誌的Logo，而這個標誌同樣也出現在你的個人網站上。這個標誌的背後含義是什麼？對我自己而言，你好像挺欣賞海盜元素的，透過批判性思維能從“醜陋”當中發現“美善”？

這是我個人的Logo，已經用了好多年了。它本身並沒有什麼特殊的含義，不用太認真對待。括號（{ }）表示程式碼，作為語法元素經常出現在CSS和JavaScript裡。兩把交叉刀代表海盜、編碼界的海盜。在西方文化當中，海盜並不一定表示壞的意思，他們也可以表示某方面的“大牛”。這也是我想要傳達的意思。

我們一般認為，男權社會中男性的地位要高於女性。作為女性，你又來自網際網路技術不太發達的希臘。是什麼原因讓你成為一位世界範圍內廣泛知曉的開發人員？一個人的出身是否可以決定她/他的成就？

值得慶幸的是，網路的普及，讓出身和人們所能達到的高度之間不存在必然聯絡。我見過有的人把自己封閉在某個網路的小角落裡，只跟自己國家的人交流、工作，但這是他們的選擇。只要把英語說好，沒有人能限制他們成就的廣度和深度。我希望任何想在國際舞臺上做出一些事情的人要專注於提高自己的英語水平，而不僅僅是他們的HTML、CSS和JavaScript。不管你的技術知識有多好，如果不能很好地表達自己，沒有人會知道。

講一個我自己的有趣故事，開始建立個人部落格lea.verou.me之前，我曾用希臘語建立過一個部落格，很遺憾完全地、徹底地失敗了。在希臘，很少有人會對前沿的css技術感興趣，這也就可以解釋為什麼希臘的開發人員掙得那麼少，還常常被他們的客戶刁難。我很慶幸自己沒有放棄，開始建立用英語編寫的國際部落格，不然我的生活肯定是另一番樣態。

希臘目前可能還存在一些針對女性的性別歧視，但並不明顯，不然我可能會被影響到。實際上，有時候希臘在性別平等方面比其他西方國家更進步。我最近在個人部落格上寫了一篇博文（http://lea.verou.me/2015/12/my-positive-experience-as-a-woman-in-tech/ ），文章裡講到在我的職業生涯裡，我個人還沒有真正經歷過任何的性別歧視。所以，我喜歡做這一行：）

除了寫書分享知識以外，你還分享了好多的開源專案。但是，據我所知，有些人是不願意分享程式碼示例的。他們認可展示出來設計良好的作品，卻不願意分享設計藍圖。你怎麼看待？

程式碼共享是一種回饋社會的行為。無論從事什麼行業，我們都離不開開源專案的幫助。想象一下，如果每個人的邏輯都一模一樣，我們的專業會千篇一律。使用了別人分享的成果卻不願意分享自己的程式碼，在我看來，有點“小自私”。的確，其他行業的文化可能有所不同，從業人員不願意分享工作。

我很喜歡技術行業的開放分享文化，欣賞開發人員之間分享知識、互相幫助的活動。他們熱衷於分享程式碼或者回答Stack Overflow技術問答網站上的問題。換做是我，我一樣會這麼做。另外，當我的工作可以幫助到別人、被他人使用時，我非常高興。這就是為什麼我選擇這個領域的原因。

開原始碼也意味著其他人可以參與進來，為專案做貢獻，最終專案的質量也更高。比如說，我釋出Bliss的時候，還沒有測試，現在它有一整套testsuite幫助除錯bug。還有許多專案，比如PrismJS是由社群共同維護的。我自己沒有時間維護它們，如果不是開源，專案只會爛尾。

演講時，現場展示程式碼編寫過程應該算是開源的最高形式。難道你沒有想過程式碼漏洞或者拖延會影響公共演講嗎？通常你怎麼為會議演講做準備？

現場展示程式碼編寫之前，我會一遍一遍地演示程式碼，這一點非常重要。程式碼要儘可能短，儘量減少犯錯的機會，而且一般情況下，觀眾也無法消化一張幻燈片上好多行的程式碼量。我見過有人曾用100行的程式碼啟動IDE ，在開始演示程式碼編寫之前，很多觀眾早已失去了興趣。

儘管你竭盡可能避免犯錯，現場展示程式碼編寫總避免不了失誤的發生。出發前，我還在飛機上除錯漏洞，除非能立即修復，不然我只能暫且放下問題。沒有人希望在現場展示時跟程式碼漏洞較勁。我個人經歷中，只要演講者能很快除錯好程式碼，聽眾大都很理解。

下面我們來聊聊CSS。和CSS相比，JavaScript的新增特性從生成到廣泛應用歷時幾天，而CSS的新增特性要經歷長達幾年的週期。所以，有人建議多增加一些CSS polyfill。你怎麼看待這個問題？

這樣做肯定會縮短新特性的週期。按照這種思路，PostCSS 運用CSSNext大大縮短了CSS新增特徵的週期，但並不是所有的新特性都可以提前處理。對於更多的動態特性，比如自定義屬性的新unit，目前polyfill就無法進行填充或轉譯，但大多數的JS API卻可以很容易地被轉譯。Houdini API能夠很好地解決這個難題，讓我們像編寫JS polyfill 一樣輕鬆編寫CSS polyfills。

Houdini 是W3C的一個新增工作組，他們的最終目標是讓瀏覽器支援CSS特性。如果真能成功的話，這無疑是CSS發展史上最令人興奮的時刻。你認為Houdini 的目標可行嗎？

Houdini肯定會讓CSS polyfill成為可能，這的確令人興奮，我也很期待。不過我擔心開發人員把Houdini 當作柺杖，不讓瀏覽器實現某些功能。他們認為開發人員通過Houdini API總能編寫出應對問題的庫。我不希望CSS因為Houdini 的工作就停止進一步發展，我也不願意看到CSS成為一個依賴大量庫解決基本問題的“地獄”。

運用JavaScript程式碼編寫HTML解決了很多問題，所以一些React.JS開發人員嘗試把CSS和JavaScript兩種語言結合起來，解決CSS存在的問題。你怎麼看待JavaScript程式碼編寫CSS的現象。

我認為，這主要是那些並不真正瞭解CSS，只想用JS程式碼解決一切問題的JavaScript開發人員的想法。“如果你只有一把錘子，看什麼都是釘子。”這樣做，只能讓他們喪失掉大部分的潛在合作伙伴：有一半的HTML 和CSS 開發人員對JS不感冒。

不過，CSS工作組的成員也認識到CSS在範疇和封裝方面的問題，正在積極討論解決方案。

CSS已經從網頁設計延伸到了出版行業，例如O’Reilly 已經開始嘗試把CSS運用到出版流程。你認為CSS能勝任出版行業的要求麼？基於出版行業的要求，W3C之後會對CSS做出相應的規範麼？

CSS從一開始就是要設計成一門文件樣式語言的，把CSS運用到出版行業也是必然的。實際上，CSS 之父 Bert Bos和Hakon Wium Lie，在11年前也就是2005年的時候，就運用CSS排版了《CSS：網頁設計》這本書（http://alistapart.com/article/boom）

當然， CSS要想和現有工具InDesign一樣靈活，還需要很多工作要準備。在過去的幾年裡，我們已經取得了很大的進步。不過，網頁比出版社的資源廣，所以他們的聲音更容易被CSS工作組瞭解到。出版行業是一個嚴肅的行業，我們會認真考慮新增的每一個新功能。

---

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