20年前的今天（10月10日），Opera CTO Håkon Wium Lie釋出Cascading HTML style sheets – aproposal。假如Paul McCartney是一名Web開發者，並在今天寫下《Sergeant Pepper's Lonely Hearts Club Band》，那他一定會這樣寫：
It was twenty years ago today不過，當我們找到Paul家，請他為我們唱這首歌的時候，他卻拒絕了，而且放出了他的看門狗FontTag和Bgcolor。那還是算了，為紀念這個好日子，Bruce面對面向Håkon提了一些問題，關於CSS的過去、現在和未來。
That Håkon wrote a doc to say
That if the Web's gonna last a while
Then we need a way to define style.
So may I introduce to you
a way to add visual treats:
It's Sergeant Håkon's Cascading Style Sheets!
CSS的構想誕生於20年前。你對自己這個寶貝、孩子、小青年的成長感到滿意嗎？
當然，我對CSS的發展非常滿意。CSS是Web規範的一塊基石，有了CSS網頁漂亮多了。HTML依舊生機勃勃就是CSS成功的明證。不過就像一個年青人一樣，它還是有很大的上升空間。
你說過自己建議CSS是“要拯救HTML”，為什麼這麼說？
如果沒有CSS，那麼HTML恐怕會與今天大不相同。有桌面出版背景的作者認為它沒有<color>和<font>標籤，很不習慣。當然也包括我自己。我自己釋出的第一個網頁就使用了帶有文字內容的圖片， 歷史存檔在這裡。 如果按照這個思路繼續發展下去，Web就會變成一臺巨型傳真機，文字圖片可以傳來傳去。但對視障使用者或者搜尋引擎而言，這就很討厭了。我建議CSS就是想阻止這種發展勢頭，同時為作者提供一種表達自己設計意圖又不必增加新HTML標籤的方式。
在第一稿建議中，有一個影響百分比說明符，像h1.font.size = 24pt 100%，就是這樣描述的：
該行末尾的百分比表示要求的影響程度（這裡是100%）。如果它在一個初始樣式表（如使用者控制的樣式表）裡面，則這個要求可以滿足，比如用Helvetica來顯示所有標題元素。如果這個語句來自後來的樣式表，則保證滿足未宣告影響的樣式。為什麼又拋棄了？
這種辦法是想把作者和使用者的要求與偏好組合到一起，是受了 MIT Media Lab的一個思路的啟發，他們認為未來電視可能不會提供亮度和色彩的控制，而是會控制色情和暴力，或者左派、右派之類的。我的CSS建議是想著有一把滑尺，作者對滑尺的一端有完全控制力，而使用者則對另一端有完全控制力。在滑尺中間，瀏覽器又可以混入一些要求，從而讓所有人都能接受。這個辦法對有的屬性管用（如font-size），但對另一些屬性（如font-family）則不行。Bert在對第一稿的回覆中 批評了這個思路：
我覺得把兩種設計方案折中成一箇中性樣式表的思路是錯誤的。如果我要求藍黃，而別人要求黃藍，那怎麼辦？結果難道是綠綠嗎？誰希望看到標題很新潮，而正文卻使用Helvetica？我回複道：
有些屬性可以混合，有些不行。“加權平均數”的典型應用是弱化作者的個性化傾向，比如建議的字號大小，而使用者仍然可以對此有所控制。當然不一定非要使用這個功能，儘管“100%”等於二進位制的“1”，但在二進位制裡反過來則不行。我認為計算機介面的二進位制有點過。當然，Bert是對的（通常他都是對的），那樣的話不僅不解決問題還會製造新問題，所以我就拋棄了混合的思路。
上面使用的是JS風格的點語法。後來為什麼又改了？
你管它叫JS風格的語法，這很有意思。我在提出CSS建議的時候，JavaScript還不存在呢，所以我不可能借鑑它的語法。實際上這個寫法借鑑了 X11 Window System中的 X資源，那是MIT的又一個令人激動的專案。
之所以CSS語法由font.size改成font-size，有兩個想法。首先，連字元讓屬性更像書面英語，讓人覺得親切易懂。其次， DSSSL和 DSSSL-Lite就使用這種連字元屬性名。編寫過DSSSL-Lite第一稿的James Clark參加了 W3C關於樣式表的第一次研討會，Bert和我就從DSSSL中借鑑了連字元。說到不方便，就是連字元在數學裡表示減號，有時候會給解析器製造點麻煩。
Bert Bos是怎麼參與進來的，你們倆怎麼分工？
Bert Bos審閱了我的建議初稿。他的背景和興趣跟我有點不一樣，但在他寫完了 他的建議後，我們很快意識到我倆的建議可以整合成一個。那時候，CERN不再支援Web專案，而W3C成立了。於是我就在 INRIA組建了W3C的歐洲分支，立刻聘用了Bert。
CSS1的大部分內容都是1995年7月我們在索菲亞安替城（Sophia-Antipolis ）用白板討論出來的。Bert直到現在還在索菲亞安替城的W3C上班。每當我遇到棘手的技術難題，都會想起Bert和那塊白板。
說到對CSS做出過貢獻的人，我不能不提Thomas Reardon和Chris Wilson，他們都是微軟的。Thomas是IE（Internet Explorer）的專案經理，他很早就想到了為Web引入樣式表。Chris Wilson是負責把CSS加入IE3的程式設計師。IE3的實現很不標準，但別忘了它是在CSS1制定完成前釋出的。Simon Daniels（也是微軟的）用IE3寫了一些叫人過目不忘的演示。他們的工作表明瞭一家大軟體公司在支援剛剛誕生的標準。
有其他競爭性的建議嗎？為什麼你們的比別的好？
樣式表語言的建議大概有十來個吧。不過，這些建議並不都適合Web。比如，瀏覽器會漸進地渲染並顯示文件，那就必須處理找不到樣式表的情況。能上網的裝置也不少，需要能夠為不同的裝置編寫樣式表。因此，樣式表語言必須能表達可伸縮且適應性強的設計。這是一個令人神往的研究領域，我為此還寫過 一篇博士論文，其中比較了不同的樣式表建議的手段。
當然，你的第二個小問題，我肯定就比較主觀了。但我相信CSS確實具有幾個顯著的特性，特別適合在Web上使用：層疊、偽類和偽元素、向前相容的解析規則、支援不同的媒體型別、重點突出選擇符，還有特別棒的em單位。
你（和Bert）犯過最大的錯誤是什麼？
我的博士論文專有一章說明CSS的問題。確實有問題，甚至有些都是自找的。但CSS1遇到過的最大的問題並非其設計（設計還是相當好的，我覺得），而是最初的實現。Jeffrey Zeldman曾提到這個情況：
如果Netscape 3忽略應用到<body>元素的CSS規則，並隨意為頁面中的每個結構化元素都新增一些空白，如果IE4能正確處理<body>但填充卻很拙劣，那怎麼寫CSS才能放心？有些開發者為此根本就不會寫CSS。有人寫了一個樣式表來補償IE4的缺陷，寫了另一個樣式表糾正Netscape 4的錯誤。微軟和網景（Netscape ）在這個問題上都有責任，而我們——我、Bert、W3C——如果能依照CSS1規範拿出一套測試也可以避免很多問題。第一個真正的CSS測試是1998年10月份才出現的，那就是Todd Fahrner釋出的 Acid測試。那個測試很有創意、一目瞭然，讓開發者馬上就知道自己是否通過了測試。一開始，沒有一款瀏覽器能通過測試。但自從有了這個測試，加上CSS社群的強力推動，事情開始有了轉機。 WaSP在推動標準化的程式中扮演了重要角色。Opera瀏覽器也起到了重要作用，它向世人展示CSS實際上是可以正確實現的。在瞭解到Opera的CSS實現非常徹底（比微軟和網景都強太多）之後，我加入了Opera。
我在加入之前，Opera就以其瀏覽器能裝進一張軟盤（1.44 MB）而著稱。“裝進一張軟盤”在當時是個很厲害的標誌。新增對CSS的支援之後，瀏覽器有點“發福”，Opera不能再那麼宣傳了。“幾乎可以裝進一張軟盤”聽起來可沒原來那麼牛。
最初的Acid測試之後又出現了 Acid2和Acid3，背後的邏輯都一樣：一個視覺化的高要求的網頁，用於測試各種CSS特性。Acid2的推出是受到 比爾·蓋茨一封公開信的激發，那封信讚美了互操作性。讓IE7遵循CSS標準看起來就是自然而然的了，隨後微軟就受到了Acid2的挑戰。公平地講，其他瀏覽器也有問題，Acid2讓它們暴露了很多bug。微軟的IE7對Acid2視而不見，但隨後的IE8卻完美地通過了測試，挺神奇的。現在的瀏覽器也都能了。
為什麼你決定在盒模型中使用外邊距、內邊距、邊框宣告寬度，而沒有使用IE5的box-sizing: border-box盒模型？
這兩種盒模型都有相應的用武之地。如果你想拉伸一張圖片以填充整個內容盒子，那麼就要使用最初CSS的盒模型。如果你認為內邊距和邊框不應該擴充套件到某個區域之外，那IE5的盒模型更合適。個人認為，CSS盒模型的用途更廣一些，可一些我很敬重人都不這麼認為。這個衝突現在已經通過增加對box-sizing屬性的支援得到了很好的解決。
我一直非常不喜歡絕對定位。是我的問題嗎？規範中怎麼會加入這個特性呢？
你這個問題讓我想起了1996年的一些激烈的爭論。簡單地說，就是微軟在一個叫做 CSS Regions: Absolute Positioning and Z-Ordering的草案中提出了絕對定位這個特性（沒記錯的話，當時的討論僅限於W3C成員的郵件列表；最接近的公開文件是 WD-positioning）。有些新成立的CSS工作組成員持保留意見，Bert和我寫了 一個簡單的反對案。我們提議刪掉position屬性（用display代替），只描述相對定位（從而有時間好好討論絕對定位）。但微軟已經實現了自己的建議，不情願刪掉這個功能。最終，唯一重要的變化就是新增了right和bottom屬性（平衡left和top），以及position: fixed。這就在後來的CSS2中體現了出來。
跟你一樣，我也一直不怎麼喜歡絕對定位。有人說，絕對定位在Web上已經有了它的位置，而我時不時會用它實現一些編碼不太可能實現的效果。
我曾聽人說過不應該使用浮動來佈局，因為這不是浮動特性“設計的初衷”，浮動最初只是為了實現圖文繞排的。這樣用有問題嗎？
圖文繞排是一個基本的佈局技術。因此毫無疑問，浮動應該可以用於佈局。我希望CSS能進入 螢幕分頁展示這個領域。在分頁內容時，浮動會更重要，因為你可以把元素浮動到螢幕的上頭和下頭。
如果你能施展魔法，那你最希望當前CSS中的哪些東西從這個世界上銷聲匿跡，又希望新增並讓哪些東西瞬間無所不在？
我希望清除特定於瀏覽器版本的程式碼，比如<!--[if lt IE 7 ]>。雖然從技術上說這不屬性CSS，但這種“註釋”不應該成為必要的東西，它們敗壞了Web標準的名譽。
你提的後一個問題更有意思。如果是在2006年，我想說 Web字型。如果是在2007年，我想說<video>元素（誤入HTML領地有年頭了）。這兩者現在所有瀏覽器都支援了。
2011年，看到那麼多應用使用頁面（不帶滾動條）建立令人眩目的幻燈片，我開始想讓網頁變成真正的頁面。思路就是樣式表可以觸發分頁模式，把內容分配到多個頁面中。使用者可以通過手勢或者PageUp和PageDown切換頁面。我希望這樣一來在瀏覽器中建立電子書不僅成為可能，甚至更容易。為此，有點魔法會更好。你可以幫我在所有瀏覽器提供商的額頭上撒些仙塵嗎？
為什麼我們還不能通過CSS實現分頁佈局，又不是什麼尖端技術？（Flexbox，注意啦……）
佈局很複雜，在Web上實現佈局更復雜，因為頁面要在很多不同裝置中顯示。CSS有幾種排布內容的機制，包括絕對定位元素、浮動、多欄佈局和CSS表格。這些特性綜合運用起來非常複雜，但我也不認為這是什麼尖端技術。不過我承認沒有怎麼用過Flexbox。
你怎麼看SASS和LESS這些前處理器？CSS可以從這些技術上借鑑什麼？
當然，前處理器很有用。我想可能可以從前處理器的功能裡選擇5個左右最流行的，內建到CSS裡。我個人比較喜歡巢狀選擇符、單行註釋（以//開頭）。等CSS 50歲的時候，我會告訴你為什麼CSS一開始並沒有考慮這些。
你是WHATWG的成員，怎麼會出現這個組織？
WHATWG成立於W3C想要放棄HTML，並把工作重心轉移到基於XHTML、XForms、SMIL和SVG構建 混合文件上的時候。對瀏覽器製造商而言，HTML太重要了，怎麼能放棄呢！因此，當時還在我的Opera團隊的Ian Hickson成立了WHATWG，繼續開發新的Web標準。同時，我們也關注微軟的XAML，它在專有應用語言上面加入了一層簡單的XML。因此WHATWG的目標就是應用，而不是文件。Ian作為編輯還在繼續開發HTML標準， 碩果累累。
你是CSS之父，但你最近卻在WHATWG而非W3C的CSS工作組名義下發布了一些規範。為什麼？
事實上， CSS Figures和 CSS Books是WHATWG的工作專案。以WHATWG的名義釋出這些規範有重大的意義。這個“活標準”模型可以低成本快速更新，這與過去釋出W3C Working Drafts的困難程度形成了鮮明的對比。WHATWG 保持規範適度超前於實現而不致使實現放棄的目標，我非常認同。
最後一個問題，CSS還能勝任自己的角色嗎？或者說，我們是不是應該換一個新模型，比如網格樣式表（Grid Style Sheets）？
1999年，Ethan Munson和Philip M Marden就提到“對樣式表語言的研究嚴重不足”。這個結論到今天依然不過時，任何研究和改進樣式表的努力都必須鼓勵。
GSS是個有意思的例子，它在樣式表機制中新增了“Cassowary”約束求解器。在1995年最初的CSS實現中，我使用的是“SkyBlue”約束求解器來解決樣式表語句的衝突。（順便說一下，這兩種約束求解器都是華盛頓大學開發的。）通過約束求解器可以表達任意兩個元素之間的關係，並能自動解決衝突。可是，隨著舊元素的消失和新元素的加入（比如通過DOM操作），問題會變複雜。此外還要恰當地處理好迴圈依賴。考慮到這些問題，我很早就打消了通過CSS表達任意元素間佈局約束的念頭。
過去，要支援新規範必須說服所有瀏覽器製造商，要他們拿出寶貴的開發時間。這就提高了門檻，可能還高得離譜。而現在，已經可能像通過庫擴充套件JavaScript一樣擴充套件瀏覽器了，試驗和研究樣式表容易多了。
回到你的問題上：CSS還勝任它的角色嗎？我認為勝任。我還沒看到有可能取代它的新模型出現。新想法一定會有，但應該會擴充套件而非替代CSS。我相信我們今天寫的CSS程式碼，500年後的計算機仍然能看懂。
謝謝你接受採訪，祝CSS生日快樂！
英文來自： Dev.Opera
譯文出自：圖靈社群
來自：CSDN
相關閱讀
評論(1)