原文：About HTML semantics and front-end architecture
作者：Nicolas Gallagher
翻译：Mark Qin
本文收集了一些我喜欢的想法、经验、理念，以及在过去一年中所尝试的创意。它涵盖了HTML语义、组件、前端架构的方法、class命名模式，以及HTTP压缩等内容。
我们永远都不该停止探索
而我们一切探索的终点
将是回到我们启程的地方
并且是平生第一次了解这个地方
托·斯·艾略特 —— “小吉丁”
关于语义
语义研究的是标志与符号之间的关系，以及它们所代表的意义。在语言学中，它主要是研究这些标志（如单词，短语，或者声音）在语言中的意义。而在前端开发领域，语义主要涉及的是HTML元素、属性和属性值（包括像Microdata这样的扩展）所约定的意义。这些在规范中常用的正式约定语义，可以帮助程序（以及后来参与开发的人）更好地理解一个网站各方面的信息。然而，即使这些元素、属性和属性值的语义是正式化的，它们依然得服从于开发者的适应程度以及共同选择的结果。这使得正式的约定语义也可能会在今后被修改（而这正是HTML设计原则之一）。
区分不同类型的HTML语义
遵守编写“语义化的HTML”这个原则，是现代专业前端开发的基础之一。绝大多数的语义都与当前或预期的内容性质有关（如：h1元素，lang属性，type属性的email值，Microdata）。
然而，并非所有的语义都需要以内容为导向。类名不能“无语义”。不管是用什么名字命名，它们都必须要有意义与目的。类名的语义可以和那些HTML元素不同。我们可以借助HTML元素、某些HTML属性、Microdata等所具有的“全局性”语义，然后利用网站或应用的“局部性”特定语义加以区分，这些特定语义通常包含在属性值中，比如class属性。
尽管在HTML5规范的class属性这一章节中重申了这个假定的“最佳实践”…
…鼓励开发者使用class属性值描述实际内容，而不是描述期望展现的内容。
…并没有什么内在的原因非这样做不可。事实上，当这种方法在大型网站或者应用中运用时，它往往会成为一种障碍。
- HTML元素和其它属性已经提供了内容层的语义
- 对于机器或访问者来说，类名所能透露的有用的语义信息非常少，甚至没有。除非它是已经约定的那一小部分名称（机器同样可读） —— Mircoformats
- 类名的主要用途是成为CSS和JavaScript的钩子。如果你不需要为你的页面添加表现和行为，那么你或许不必在你的HTML里添加类名
- 类名应该为开发者传达有用的信息。当你阅读一个DOM片段时，它将有助于理解某个类名的具体作用。尤其是在多人协作的开发团队里，与HTML组件打交道的可不光只有前端开发者。
举一个非常简单的例子：
<div class="news">
<h2>News</h2>
[news content]
</div>
当内容还不明显的时候，这个类名news不能告诉你任何事情。它没有向你提供关于这个组件整体结构的信息，而且一旦内容不再是“新闻”时，使用这个类名就显得非常不妥。类名的语义过分贴近内容，架构既不容易扩展，也不容易为其他开发人员所用。
与内容无关的类名
从某个设计模式的结构与功能中提取类名的语义是一种更好的方法。那些类名与内容无关的组件可重用性更高。
我们不应该害怕让各层之间的关系变得清晰而明确（这里应该是指结构层、内容层等，译者注），而不是用类名严格地反应明确的内容。这样做不会使类名“无语义”，这只是表明它们的语义并不取决于内容。我们也不应该害怕使用额外的HTML元素，只要它们能帮助你创建更强壮、更灵活且更具重用性的组件。这样做不会使HTML变得“无语义”，这仅仅意味着你标记内容所使用的元素数量超过了最小值而已。
前端架构
组件、模板、面向对象的体系结构的目的是能够开发出一种数量有限的可重复使用的组件，它可以在一定范围内包含不同的内容类型。在大型的应用程序中，对类名语义来说最重要的事情是，能够用实用主义服务于它们的主要目的 —— 提供有意义的、灵活的、可重复使用的表现或行为的钩子供开发者使用。
可重用且可组合的组件
总的来说，可扩展的HTML/CSS必须依赖HTML中的class，以便创建可重用的组件。一个灵活的、可重用的组件，既不依赖DOM树中的某一部分，也不需要使用特定类型的元素。它应该能适应不同的容器，并且可以很容易地更换主题。如果有必要，额外的HTML元素（超出标记内容所必须的元素之外的元素）可以让组件更加强壮。Nicole Sullivan所说的media object就是一个很好的例子。
避免用类型选择器支持class，可以让组件更容易合并。下面这个例子中，btn组件与uilist组件不易于合并。问题在于.btn的权重比.uilist a要小（这将覆盖任何共享属性）。而且ulist组件需要锚点作为子节点。
.btn { /* styles */ }
.uilist { /* styles */ }
.uilist a { /* styles */ }
<nav class="uilist">
<a href="#">Home</a>
<a href="#">About</a>
<a class="btn" href="#">Login</a>
</nav>
一种让uilist组件与其它组件轻松组合的方法是，uilist的子级DOM元素用class来添加样式。尽管这会降低权重，但是它的主要好处在于，它为你提供了处理子节点的任何结构样式的选择权。
.btn { /* styles */ }
.uilist { /* styles */ }
.uilist-item { /* styles */ }
<nav class="uilist">
<a class="uilist-item" href="#">Home</a>
<a class="uilist-item" href="#">About</a>
<span class="uilist-item">
<a class="btn" href="#">Login</a>
</span>
</nav>
JavaScript专用类
使用某种形式的JavaScript专用类，可以降低因组件样式或结构的改变导致JavaScript失效的风险。我已经找到了一种非常有效的方法，那就是专为JavaScript的钩子使用一种特定的类——js-*——不要在这个类名上添加任何描述。
<a href="/login" class="btn btn-primary js-login"></a>
在你修改组件的结构或样式的时候，可能会不经意间对那些必要的JavaScript行为和复杂的功能造成影响，用这种方法的话，可以降低这种可能性。
组件修改器
组件常常会有一些变体，它们与基本组件只有细微的差别。比如，不同的背景色或者边框。主要有两种创建这些组件变体的模式。我将它们称为“单类名”模式和“多类名”模式。
单类名模式
.btn, .btn-primary { /* 按钮模板样式 */ }
.btn-primary { /* 主按钮的特殊样式 */ }
<button class="btn">Default</button> <button class="btn-primary">Login</button>
多类名模式
.btn { /* 按钮模板样式 */ }
.btn-primary { /* 主按钮的特殊样式 */ }
<button class="btn">Default</button> <button class="btn btn-primary">Login</button>
如果你使用预处理程序，你可以用Sass的@extend功能，以减少一些在使用“单类名”模式时所涉及的维护工作。然而，即使有预处理程序的帮忙，我依然倾向于使用“多类名”模式，并在HTML中修改类名。
我发现这是一种更具扩展性的模式。比如，要实现一个基本的btn组件，并增加5种类型的按钮与3种额外的尺寸。用“多类名”模式的话只要9个class就可以搞定，用“单类名”模式则需要24个class。
如果需要的话，它也更容易让上下文环境适应组件。你可能想对出现在其它组件中的任一btn做一些细节调整。
/* “多类名”样式调整 */
.thing .btn { /* 相应的样式调整 */ }
/* “单类名”样式调整 */
.thing .btn,
.thing .btn-primary,
.thing .btn-danger,
.thing .btn-etc { /* 相应的样式调整 */ }
“多类名”模式意味着，你只需要用一个单独的组件内部选择器，便可以改变所有类型的btn元素的样式。“单类名”模式意味着，你必须顾及所有可能的按钮类型，并在创造一个新的按钮变体时调整这个选择器。
结构化的类名
当创建一个组件时——并为之添加了“主题”——其中一些class被用来区分各个组件，一些class被当做组件的修改器，其它的class则被用来关联DOM节点，它们一起被包含在一个较大的抽象组件中。
很难去判断btn（组件）、btn-primary（修改器）、brn-group（组件）和btn-group-item（组件子对象）之间的关系，这是因为这些名字不能清晰地表现class的目的。没有一致的模式。
在过去的一年中，我一直在尝试命名模式，目的是能帮助我快速理解在一个DOM片段中节点的表象之间的关系，而不用为此来回切换HTML、CSS与JS文件拼凑网站的架构。这种模式主要受到BEM系统的命名方法的影响，但被改编成一种我认为更容易浏览的形式。
t-template-name t-template-name--modifier-name t-template-name__sub-object t-template-name__sub-object--modifier-name component-name component-name--modifier-name component-name__sub-object component-name__sub-object--modifier-name is-state-type js-action-name js-component-type
我将一些结构当做抽象的“模板”来处理，其它的则视为更清晰的组件（通常建立在“模板”上）。但是这种区分并非总是必要的。
这仅仅是我目前发现的一种有用的命名模式。命名模式可以采用任何形式。但这种命名模式的好处在于消除了模糊的类名，只依赖（单）连接符，或者下划线，或者是驼峰格式。
原始文件大小和HTTP压缩的注意事项
任何关于模块化与可扩展的CSS的讨论都会谈及对文件大小与“膨胀”的担心。Nicole Sullivan的言论中经常会提到文件大小的存储（以及维护改进），并提到了像Facebook这样的公司采用这种方法的经历。进一步的，我想我会分享我在预处理输出时的HTTP压缩效果，以及大量使用HTML类的一些事情。
当Twitter Bootstrap刚刚问世的时候，我重写了已编译的CSS，以便更好地与手动操作的文件比较大小。在最小化所有的文件之后，手动操作的CSS文件比预处理程序输出的小10%。但是当所有的文件都通过gzip压缩后，预处理程序输出的CSS文件比手动操作的小了5%。
这强调了比较HTTP压缩后文件大小的重要性，因为减少的文件大小并不能说明全部问题。它暗示了有经验的CSS开发者在用预处理程序时不必太过关注编译后的CSS中一定程度的重复，因为它将在HTTP压缩后变得更小。通过预处理程序处理更易于维护的CSS代码所带来的好处，要胜过关注原始CSS和压缩后输出的CSS的美观或文件大小。
在另一个实验中，我从线上扒了一个60KB的HTML文件（由很多可重用的组件组成），并删除了它的每一个class属性。这样处理之后，文件大小减小到25KB。当原始文件与扒下来的文件都通过gzip压缩后，它们的大小分别变为7.6KB和6KB——只相差1.6KB。自由使用class所导致的实际文件大小的结果已经不值得再去强调了。
我是如何学会停止担忧的…
多年来，许多技术熟练的开发人员的经验，已经改变了大型网站和应用程序的开发方式。尽管如此，对于个人来说，放弃“语义化的HTML”的观念，意味着将由内容来决定类名（即使非要这么做，也只能作为最后的手段来使用），这通常需要你开发完一个大型的应用程序后，才能够强烈地意识到这种做法不靠谱的一面。你必须准备好抛弃老观念，寻找替代方案，甚至重新审视以前已被你摒弃的方法。
一旦你开始写大型的网站和应用，你和其他人不仅必须去维护它，而且还得积极地迭代改进。你很快会发现，尽管你尽了最大的努力，你的代码仍然开始变得越来越难以维护。已经有一些人提出了他们自己的方法来解决这些问题：Nicole的博客和面向对象的CSS项目，Jonathan Snook的可扩展的模块化结构CSS，以及Yandex（俄罗斯最大的搜索引擎，译者注）开发的块级元素修改器。这些方法值得我们花时间去探索。
当你选择了以减少编写和编辑CSS的时间为目的的方式来编写HTML和CSS时，那么如果你想改变它们的样式，你就必须接受花更多的时间去改变HTML元素的class。无论是前端还是后端开发者 —— 任何人都可以重新排列预建的“乐高积木”，这将是相当实用的；事实证明，没有人会CSS魔法。
