採訪和書評：精通HTML5和CSS3設計模式

來自InfoQ

編者按

今天下午，在InfoQ看到一篇精彩博文，《採訪和書評：精通HTML5和CSS3設計模式》，特轉發至此。本書版權已在圖靈，目前正在翻譯狀態。喜歡本書的讀者可持續關注圖靈社群讀書頻道。

---

每個應用程式都是獨一無二的——但構成應用程式的元件卻不盡如此。工具箱和程式庫能夠捆綁高層GUI元素和概念，但它們也因此造成了對程式庫的依賴。

一本名叫《精通HTML5和CSS3設計模式》的新書研究記錄了web應用程式的常用設計模式，並使用HTML5、CSS和JavaScript（需要的話）提供了這些設計模式的實現方案。該書的出版機構Apress向InfoQ獨家提供了該書第二章“HTML設計模式”的摘錄。

InfoQ邀約到了該書的作者之一Dionysios Synodinos，和他談論了該書背後的思想，以及HTML、CSS3和JavaScript開發技藝目前的狀況。

InfoQ: GoF設計模式一書的貢獻之一就是提供了共用的術語，簡化了溝通方式。你們的書也是這樣嗎？你們根據什麼給設計模式起名字？它們用於解決不同領域下的問題嗎？（排版、GUI工具箱…）?

設計模式已經在軟體程式設計中成功運用。它們提高了web應用程式設計和開發的生產率、創造性以及有效性，同時減少了程式碼量和複雜度。在CSS(3)和 HTML(5)的情況下，設計模式是一組常用功能特性的集合，工作於各種各樣的瀏覽器和螢幕閱讀器中。它們不需要依賴於hacks和filters技術， 同時不降低設計價值和可訪問性。但到目前為止，這些設計模式還沒被系統地運用於web設計和開發。

一旦一個設計模式浮出水面，就將極大地提高創造力和生產力。它能夠單獨使用以快速得到結果，它還能和別的設計模式聯合使用以建立更加複雜的結果。設計模式 簡化並增強創造過程，它們使得創造本身就像搭積木或者樂高組合玩具一樣容易。你只要選擇預先設計好的模式，然後做適當的調整，就可以對它們進行組合以創造 你想要的結果。設計模式不會限制創造性——事實上它們解除了對創造性的約束。

你提及的GoF設計模式一書寫到：設計模式由4個元素組成：模式名稱、問題、解決方案和折衷。我們的書也遵循了這種方式。

InfoQ: 這本書涉及到跨瀏覽器程式設計和設計嗎？

本書會涉及跨瀏覽器開發。這是一本與實戰相關的書，它直接關注於被設計成具體模式、所有瀏覽器都支援的CSS和HTML。每個模式都在所有主流瀏覽器中測試通過，同時本書在很多情況下都特別提及了對過時瀏覽器的相容問題。

讓我們以“Center Aligned（居中對齊）”模式為例，該模式用於以下情形：你想要讓一個元素及其內容水平居中於它的父元素或最近的定位祖先元素。現在想想，這應該是很 容易實現的任務，但可惜的是，事實上會有一些陷阱。就像我們在書中提到的，IE6不能讓絕對定位元素居中，版本7能夠讓伸展的絕對定位元素居中，但不能讓 設定了寬高的絕對定位元素居中，版本8及以上能夠讓設定了寬高的絕對定位元素居中。而我們提供的模式能夠相容所有瀏覽器！

需要說明的是，有些模式只能應用於支援HTML5的瀏覽器，比如“HTML5 Form Validation（HTML5表單驗證）”等等。

InfoQ: 你們是怎樣選擇框架的？你建議選擇覆蓋所有方面的大框架，還是根據特定任務精挑細選合適的小框架？

我個人喜歡組合小框架和程式庫，而不是使用試圖應付一切的大框架。無論前端程式設計還是後端程式設計都是如此。從小程式庫中精挑細選，能夠讓我更加自由而準確地以我想要的方式達到想要的結果。這同時能幫助我為專案選擇合適的工具，以及在抽象有瑕疵時把握分寸。

HTML5平臺的優勢就是它比我能想到的其它平臺更加適合於整合程式庫，這可能是其最大的優勢！

有幾個JavaScript和CSS程式庫能讓程式設計師的工作更加輕鬆，比如jQuery、jQueryUI、Underscore.js、 Yahoo UI、HTML5 Boilerplate、Modernizr、960 Grid System、Twitter的Bootstrap等等。

InfoQ: 最令你頭疼的三個HTML問題是什麼？或者說哪些HTML概念最讓你抓狂？

我認為HTML平臺主要存在3個“問題”：

瀏覽器支援：構建任何一款需要在幾種不同環境（瀏覽器+作業系統）中執行的應用程式都是很大的挑戰。像jQuery等程式庫能如此成功， 正是因為它們抽象出了這些不同點。同時我還喜歡像browserstack.com和Abobe BrowserLab這樣的工具，可以用於測試多重配置。

可避免的冗餘和有限的功能特性：人們普遍認為HTML語法是冗餘的，這也是為什麼人們正在為特定的實現做其他探索（提示：markdown）。CSS語法也同樣有一些限制，人們正在研究如何解決這些限制（提示2：LESS）。

HTML特定問題：存在這樣的情況：有些HTML5 API特效能按照文件規範運作，但它們是違背直觀的，經常會導致誤會。這些特性很誘人，但同時會輸出讓人意想不到的結果。一個很好的例子就是Application Cache（應用程式快取），以及它到底如何更新。

InfoQ: 你們書中討論了CSS，而我們看到CSS的超集，比如LESS、SASS、Closure Stylesheets正在引起人們的關注。對這些你有什麼想法麼？在什麼時候使用這些技術比較合適呢？

它們絕對是可以用的。像變數（variables）、混入（mixins）和巢狀規則（nested rules）等技術能使設計者的工作變得更加容易！

每個曾經試圖在CSS檔案中處理顏色的程式設計師都願意使用下面的例子：

    // This is less (note the single line comment format)
    @color: #4D926F;

    #header {
       color: @color;
    }
    h2 {
       color: @color;
    }

話雖這麼說，但必須強調的是，你可別指望在沒有搞懂CSS的情況下能會使用像LESS這樣的技術。LESS/SASS用於幫助你寫好CSS，而不是 取代CSS。同時想要指出的是，儘管人們認為CSS有不合理的地方，但說應該用其他方式來渲染GUI樣式是駭人聽聞的。在任何時候我都傾向於選擇並不完美 的CSS，而不是使用XML或者物件導向的類來新增樣式！

InfoQ: 至於文件格式，說來也怪，瀏覽器中HTML對富文字編輯的支援很糟糕。HTML已經新增了contentEditable屬性，但目前很多專案都已停止使用該屬性。比如Google Docs，以及原始碼編輯器CodeMirror 2和Cloud9 ACE從不使用contentEditable屬性。如果你現在需要構建一個富文字編輯器，那麼會使用什麼技術來完成呢？

這要取決於你想要編輯器做什麼，以及你能等待多久。例如，如果你想要格式化文件，你也許會對Kylix這類技術感興趣。事實上Google已經放棄使用contentEditable，轉而使用Kylix。

至於程式碼，Mozilla的成員正在開發一款基於Firefox開發人員工具的 程式碼編輯器。聽說他們計劃使用Eclipse的Orion，因為這能滿足他們的i18n和a10y需求。同時他們還會從Ace和Skywalker中借用 許多好的做法。兩種途徑都需要付出相當大的努力，即便只是實現最基本的編輯功能。Ace和Skywalker本身也同樣如此。

所以，瀏覽器中的富文字編輯體驗不如桌面程式中的，我知道已經有許多聰明人正在做出努力，也相信差距會迅速縮小，特別是考慮到web平臺的其他方面具有很多優勢。

InfoQ: ACE編輯器的格式化文字編輯模式令人印象深刻，它為每次螢幕更新重新建立HTML——這確實可行，因為現今HTML元件的速度快得令人難以置信。你知道其他類似的例子嗎？

Google Docs編輯器Kylix的樣式引擎就是個很好的例子：當你在鍵盤上敲字母‘a’時，編輯器知道你按了‘a’鍵並作出響應，以離屏的方式畫了一個‘a’。 接著它測量‘a’的寬和高，將寬高和滑鼠位置的x、y座標組合，然後將‘a’放置在螢幕的正確位置上。如果你處於單詞的中間，它會將字母推到游標的後面。 如果你處於一行的最後，編輯器會將單詞移到下一行，並將任何溢位內容順推到更後的行。

類似的，Google Docs中的游標事實上是一個“手動”放置在螢幕上的只有2個畫素寬的div元素。當你單擊螢幕上的某個點時，編輯器計算出該點的x和y座標，然後在該座標點畫出游標。

InfoQ: 該書提供了許多實現GUI工具箱基本特性（alert、layout等）的解決方案。應用程式應該努力模擬內建GUI工具箱及其行為（比如在移動平臺），還是隻將這些特性託付給web形式的跨平臺樣式？

人們普遍認為對於桌面系統，應用程式應該遵循你所說的“web形式的跨平臺樣式”。這也是我們的書所關注的。

另一方面，在移動領域，人們在模擬內建外觀和體驗時碰到很大問題。一個很好的例子就是jQTouch，它不僅提供了蘋果式的主題，同時還提供了具有內建應用感官的動畫，等等。

InfoQ: 你對Markdown、HAML或者其它可用來編寫HTML的技術是怎麼看的？

在降低HTML的冗餘度以及讓內容更加容易為人所閱讀和編輯方面，Markdown做得非常成功。因此對於網頁編輯，比如CMS，使用 Markdown要比使用純HTML好！另一方面，很多時候當我碰到需要使用Markdown的地方時，我總在想，要是有一個所見即所得的編輯器就好了。 類似的，HAML試圖降低冗餘，不過是從開發人員的角度出發。它有助於你更快地編寫HTML模板，同時使得這些模板更加容易維護。

例如:

    #profile
       .left.column
         #date= print_date
         #address= current_user.address
       .right.column
         #email= current_user.email
         #bio= current_user.bio

    比下面的好多了：

    <div id="profile">
       <div>
         <div id="date"><%= print_date %></div>
         <div id="address"><%= current_user.address %></div>

       </div>
       <div>
         <div id="email"><%= current_user.email %></div>
         <div id="bio"><%= current_user.bio %></div>
       </div>

    </div>

假設有體面的平臺支援的話，這裡“體面”是指模板引擎中的直接支援，我傾向於在每個可能的專案中使用HAML。作為丈夫和父親，我可沒有多少空閒時間在每次發生變化時將HAML檔案手動轉換成內建模板:)

關於書的作者

Dionysios Synodinos 是C4Media研發平臺團隊的領隊，同時也是一名自由顧問，專注於富英特網應用、web應用、安全、移動網際網路和web服務。Dionysios Synodinos還是InfoQ的HTML5和JavaScript主編，同時，他還為InfoQ撰寫JVM平臺的文章。Dionysios Synodinos在服務端程式設計和客戶端GUI設計兩個方向上有超過十年的經驗，參與過多種軟體專案，為多個技術出版機構做過貢獻。

檢視英文原文：Interview and Book Review: Pro HTML5 and CSS3 Design Patterns