经典总结！语义化HTML和前端架构

这是一篇我喜欢的思想，经验，理念，以及过去几年中我所试验的理念的集合。它覆盖了HTML语义，前端架构的组件和方法，类命名模式，和HTTP内容压缩。

我们不会停止探索
而我们一切探索的终点
将会到达我们出发的地方
于是我们第一次认识了这个地方。

T.S. Eliot — “一人”


关于语义
语义是对标记与符号之间的关系，以及它们的含义的研究。在语言学中，这主要是对语言中的符号（如单词，短语，或声音）意义的研究。在前端web开发的上下文中，语义大多是与元素，属性，和属性值（包括像Microdata之类的扩展）的一致认同意义相关。这些认同意义通常在规范中被定义概念，它们可以帮助程序员（也就是人类）更好的理解网站中信息的不同方面。但是，即使是规范化以后，元素，属性，和属性值的语义还是受制于开发者对其的适应与吸收。这可能会导致后续对正式认同语义的修改（这也是一个HTML 设计原则）。

区别不同类型的HTML语义
编写“语义HTML”原则是现代专业前端开发的基础之一。大部分语义关于存在的本质属性或是期望的内容（例如h1element,langattribute,emailvalue of thetypeattribute, Microdata）。　　

然而，不是所有的语义都要源于内容。Class名不能是“非语义”（unsemantic）的。无论使用什么名字，都要有意义、有目的。Class名的语义可以和那些HTML元素不一样。 我们可以统一利用“全局”的语义命名HTML元素、某些HTML属性、微数据等等，以免和“本地”的网站/应用专属的常常包含在属性值内的语义相混淆，比如theclassattribute。　　尽管在HTML5 specification section on classes 重复的认为“最佳的实践” 如下…

• 内容层语义已经担任HTML元素和其他属性。
• 类名很少或根本没有赋予语义有用的信息给计算机或浏览，除非它的一小部分（计算机可读）约定的名字 - 微格式的部分。
• 类名称的主要目的是为CSS和JavaScript设置钩子。 如果你不需要给你的web文档添加演示和行为，那么你可能不需要在你的HTML文件中使用classes。
• 类名应该提供有用的信息给开发商。当你读一个DOM代码段的时候，有助于了解一个特定的类的名字是要干什么，特别是在前期与多个开发团队，包括非HTML组件工作的人。

以这种非常简单的例子：

1. <div class="news">
2. <h2>News</h2>
3. [news content]
4. </div>

复制代码

从上面的例子很明显的看出，类名news并没有告诉你任何内容。它没给你组件的组织结构的任何信息，它不能用于说明内容是不是“新闻”。类名的语义与内容的性质已经减少的关联，架构功能已经变小，或者也很容易让其他开发者使用。

内容无关的类名
另一种可选的方法是在设计中从重复结构和功能模式中派生类名的语义。大多数可重用的组件都带有与内容无关的类名。　　

我们不应该害怕在清晰明确的层级间建立联系，而不是让类名严格地反映特定的内容。这样做不会让类变得“没有语义”，它仅仅意味着它们的语义不是从内容中派生出来的。如果附加的HTML元素帮助创建鲁棒性强，柔软度大，可重用的组件，我们就不要害怕把这些元素包含进来。这样做也不会让HTML变得没有语义，它仅仅意味着你使用了刚好超过标记内容最小所需的元素。

前端架构
组件/模板/面向对象架构的设计宗旨就是开发出一套包含一系列不同类型的可重用组件。在规范的应用程序中，关于类名称的语义，由实用主义者们推动并服务他们的主要目的——提供有意义的，灵活的，可重用的关联供开发者使用。

可重用及可组合的组件
可伸缩的HTML/CSS大体上必须依赖于HTML内的层级，这样就可以创造可重用的组件。一个灵活且可重用的组件既不能依赖存在于DOM 树的某个部分，也不能需要使用特定的元素类型。它应该能适用于不同的编辑器并且很容易主体化。如果必要的话，多余的HTML元素（除了那些需要标记内容的元素）可以用来让组价更强壮。Nicole Sullivan所谓的媒体对象就是很好的例子。　

组件可以很容易的组合受益于类型选择器的废止和支持class。下面的示例展示了btn组件与uilist组件的简易组合。问题是，指定.btn不如指定.uilist（这将覆盖共享属性），uilist组件需要一个锚标记作为子节点。

1. .btn { /* styles */ }
2. .uilist { /* styles */ }
3. .uilist a { /* styles */ }

复制代码

1. <nav class="uilist">
2. <a href="#">Home</a>
3. <a href="#">About</a>
4. <a class="btn" href="#">Login</a>
5. </nav>

复制代码

使用class来修饰子DOM元素是提高易用性、使用uilist来组合其他组件的一种方法。虽然这有助于减少指定规则，主要的好处是可以让你对任何类型的子节点应用结构化的样式。

1. .btn { /* styles */ }
2. .uilist { /* styles */ }
3. .uilist-item { /* styles */ }

复制代码

1. <nav class="uilist">
2. <a class="uilist-item" href="#">Home</a>
3. <a class="uilist-item" href="#">About</a>
4. <span class="uilist-item">
5. <a class="btn" href="#">Login</a>
6. </span>
7. </nav>

复制代码

JavaScript指定class
使用JavaScript指定class的形式的可以降低风险：组件的主题或结构的改变时破坏对其对应的Javascript。一种有效的方法是：Javascript钩子只使用js-*的特定class，并且一直保持。

1. <a href="/login" class="btn btn-primary js-login"></a>

复制代码

这样做，你可以减少风险：组件的结构或主题改变时会无意中影响任何必需的JavaScript行为或复杂功能。

组件编辑器
组件通常具有与基础组件有些许差别的多种不同外观，比如，一个不同颜色的背景或者边框。有两种主要的模式被用来创建这些不同的组件。我称它们为“单类”模式和“多类”模式。

“单类”模式

1. .btn, .btn-primary { /* button template styles */ }
2. .btn-primary { /* styles specific to save button */ }

复制代码

“多类”模式

1. .btn { /* button template styles */ }
2. .btn-primary { /* styles specific to primary button */ }
3. <button class="btn">Default</button>
4. <button class="btn btn-primary">Login</button>

复制代码

如果你使用了预处理器，就可以使用Sass的@extend功能，来缩减一些使用“单类”模式时所涉及的维护工作。可是，即使有预处理器的帮助，我仍然倾向于使用“多类”模式，和在HTML中增加编辑类。

我发现这是一个更具伸缩性的模式。例如，用基础的btn组件，给它增添5种类型的按钮和3种额外的尺寸。使用“多类”模式你最终将获得9种可混用匹配的类。但使用“单类”模式你将有24种类。

如果确实需要的话，它给组件做一些上下文的修改也更容易。你或许会想在另一个组件中，对任意一个btn做一些外观的细微调整。

1. /* "multi-class" adjustment */
2. .thing .btn { /* adjustments */ }
3. /* "single-class" adjustment */
4. .thing .btn,
5. .thing .btn-primary,
6. .thing .btn-danger,
7. .thing .btn-etc { /* adjustments */ }

复制代码

“多类”模式意味着在组件中，你只需一个组件内的选择器，来标示btn-样式元素的任意一种类型。而“单类”模式意味着你必须承担任何可能的按钮类型，并且在一个新按钮变量被创建的时候调整选择符。

结构化的类名
在创建组件，还有在此基础上的“主题”的时候，有些类被用作组件的边界，有些被用作组件的修饰器，有些被用来将一些DOM节点渲染到一个更大的抽象的展现组件中。

我们很难推断出btn（组件）,btn-primary（修饰器）,btn-group（组件）和btn-group-item（组件中的子对象）这些样式之间的关系，因为这些命名并没有清楚的揭示这些类的目的。没有统一的模式。　　

早在2011年，我开始使用命名模式，这让我很快的理解了DOM片段节点之间外在的关系，这比尝试通过来回移动HTML,CSS和JS文件来拼凑整个网站的结构要来得快很多。在要点中的标记的方式主要是受BEM系统的命名方式所影响，但被我改变成了我认为容易使用的方式。

自从我开始写这篇文章,其他的几支团队和框架（译者加：作者）采用了这种方法。MontageJS修改了符号变成另外一个风格,我更偏爱的并且目前正使用的是SUIT 工具包:

1. /* Utility */
2. .u-utilityName {}
3. /* State-utility */
4. .u-isStateName {}
5. /* Component */
6. .ComponentName {}
7. /* Component modifier */
8. .ComponentName--modifierName {}
9. /* Component descendant */
10. .ComponentName-descendant {}
11. /* Component descendant modifier */
12. .ComponentName-descendant--modifierName {}
13. /* Component state (scoped to component) */
14. .ComponentName.is-stateOfComponent {}
15. /* Component mixin (ancestor style dependencies) */
16. .with-ComponentName {}

复制代码

这只是我此刻发现有用的一个命名模式，它可以采取任何形式。但好处在于消除 仅仅依赖(单)连字符或下划线,或者驼峰式大小写的类名的歧义。

注意原文件大小和http压缩
凡讨论到模块化和可扩展，css成为有关文件大小和膨胀的关注性问题。Nicole Sullivan的谈话中经常提及到节省文件大小（和维护改进）。而节省文件大小是一些公司例如facebook，在采用这种模块化和可扩展方法时遇到的问题。进一步地，我想分享，在预处理器上编写且大量使用HTML元素时我对编写完的文件进行http压缩的效果。

当Twitter Bootstrap问世时，我改写了已经编译的css，使其能更好的反映出我是如何手写来进行语义化，并且比较前后文件的大小。在同时精简了这两个文件之后，手写来进行语义化的css比预处理器上写的要小大约10%。但是当两个文件都采用gzip压缩了之后，预处理器上写的比手写进行语义化的css要小大约5%。

此处凸显了在经过 HTTP 压缩之后进行文件大小对比的重要性, 因为压缩后的文件的大小并不能完全说明问题. 这也暗示了有经验的 CSS 开发者在使用预处理器的时候无需过多纠结于在编译之后的 CSS 中会出现的一定程度的重复, 因为在 HTTP 压缩之后它的尺寸会自然地变得更小. 通过预处理器处理过的更具维护性的 CSS 代码所带来的益处将会胜过对原始文件以及压缩输出的 CSS 文件的大小或美学上的考量。　

在另一次实践中, 我从一个在线网站上下载了一份有 60KB 大小的 HTML 文档, 从中删除了所有的 class 属性(它们构成了许多可重用的组件). 这样处理之后将文档的大小减小到了 25KB. 当原始文档和分离过的文档各自被 gzip 压缩过后, 它们的尺寸变成了 7.6KB 和 6KB – 仅 1.6KB 的区别. 对于那些通过自由使用 class 而实际对文件大小产生的影响真的不值得再强调和放大了。

我怎样学会停止烦恼的…
许多熟练的开发人员的经验,经过多年,已经导致了大规模网站和应用程序开发的巨大转变。尽管如此,对那些在意识形态上断奶的个体来说,“语义化HTML”是指使用内容派生类名(即使是这样,只能作为最后的手段),在你变得可以敏锐地意识到那个方法不切实际的性质之前，通常需要你完成一个大型应用程序。你必须准备放弃旧的观念,看看替代品,甚至你可以重拾之前摒弃的方法。

一旦你开始写作你和其他人不仅要维护而且要积极迭代的不平凡的网站和应用程序时,你很快就会发现,尽管你尽了最大的努力,你的代码开始变得越来越难维护。一些人提出了他们自己的方法来解决这些问题，你值得花时间去探索他们的工作:妮可的博客和面向对象的CSS项目,乔纳森斯努克的可伸缩的CSS模块化架构,和Yandex开发的块元素修改器方法。

当你选择用HTML和CSS写作,并试图减少你花在写作和编辑CSS上的时间,这涉及到必须接受如果你想改变HTML元素的风格，你必须花更多的时间修改元素的类上。这证明是相当实用的,无论对前端还是后端开发人员——任何人都可以重新排列预先构建的“乐高积木”;事实证明,没有人可以发明css炼金术。