采访和书评：精通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个“问题”：

1. 浏览器支持：构建任何一款需要在几种不同环境（浏览器+操作系统）中运行的应用程序都是很大的挑战。像jQuery等程序库能如此成功， 正是因为它们抽象出了这些不同点。同时我还喜欢像browserstack.com和Abobe BrowserLab这样的工具，可以用于测试多重配置。
2. 可避免的冗余和有限的功能特性：人们普遍认为HTML语法是冗余的，这也是为什么人们正在为特定的实现做其他探索（提示：markdown）。CSS语法也同样有一些限制，人们正在研究如何解决这些限制（提示2：LESS）。
3. 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

转自 InfoQ