关于语义

语义学研究符号和符号之间的关系以及它们所代表的意义。在语言学中，它主要研究这些符号(如单词、短语或声音)在语言中的意义。在前端开发领域，语义主要指HTML元素、属性、属性值(包括像Microdata这样的扩展)的约定含义。这些规范中常用的正式契约语义可以帮助程序(以及后来参与开发的程序)更好地理解网站的各个方面。但是，即使这些元素、属性、属性值的语义是形式化的，还是要服从开发者的适应性和共同选择的结果。这使得形式约定语义在未来可能被修改(这是HTML设计的原则之一)。区分不同类型的HTML语义

遵循编译语义HTML的原则是现代专业前端开发的基础之一。大多数语义与当前或预期的内容属性(如h1元素、lang属性、类型属性的电子邮件值、Microdata)相关。

然而，并不是所有的语义都需要面向内容。类名不能“无语义”。不管叫什么名字，都要有意义和目的。类名的语义可以不同于HTML元素的语义。我们可以利用HTML元素的“全局”语义，一些HTML属性，微数据等。然后使用网站或应用程序的“本地”特定语义，这些语义通常包含在属性值中，如类属性。

虽然这种假定的“更佳实践”在HTML5规范的类属性部分被重申…

.鼓励开发人员使用类属性值来描述实际内容，而不是描述期望的内容。

.我们没有内在的理由必须这样做。事实上，当这种方法用于大型网站或应用程序时，往往会成为一种障碍。

HTML元素和其他属性已经提供了内容层的语义

对于机器或访问者来说，类名可以揭示很少或没有有用的语义信息。除非是已经同意的名字的一小部分(机器也可读)，——微格式

类名的主要目的是成为CSS和JavaScript的钩子。如果您不需要在页面中添加表达式和行为，那么您可能不需要在HTML中添加类名

类名应该向开发人员传达有用的信息。当你阅读一个DOM片段的时候，它会帮助你理解一个类名的具体作用。尤其在多人协同开发团队中，前端开发人员并不是处理HTML组件的人。

举一个非常简单的例子：

XML/HTML代码将内容复制到剪贴板

divclass='news '

h2新闻/h2

[新闻内容]

/div

内容不明显的时候，这个类名新闻也不能告诉你什么。它没有给你提供关于这个组件整体结构的信息，一旦内容不再是“新闻”，使用这个类名是非常不合适的。类名的语义太接近内容，架构既不容易扩展，也不容易被其他开发人员使用。与内容无关的类名

从设计模式的结构和功能中提取类名的语义是一种更好的方法。类名与内容无关的组件，复用性更高。

我们不应该害怕使各层之间的关系清晰明确(这里指的是结构层、内容层等。)，而不是用类名来严格反映确定的内容。这样做并没有使类名“无语义”，只是说明它们的语义不依赖于内容。我们不应该害怕使用额外的HTML元素，只要它们可以帮助您创建更强大、更灵活和更可重用的组件。这样做并不会让HTML“无语义”，只是意味着你用来标记内容的元素数量超过了最小值。前端架构

组件、模板和面向对象架构的目的是开发有限数量的可重用组件，这些组件可以在一定范围内包含不同的内容类型。在大规模应用中，类名语义最重要的是以实用主义服务于其主要目的，并提供有意义的、灵活的、可重用的钩子供开发人员使用。可重用且可组合的组件

一般来说，可扩展的HTML/CSS为了创建可重用的组件，必须依赖HTML中的类。灵活且可重用的组件不依赖于DOM树的任何部分，也不需要使用特定类型的元素。它应该能够适应不同的容器，并可以轻松改变主题。如果需要，额外的HTML元素(标签内容所必需的元素之外的元素)可以使组件更强大。妮可沙利文提到的媒体对象就是一个很好的例子。

避免用类型选择器支持类可以使组件更容易合并。在下面的例子中，btn组件和uilist组件不容易合并。问题是。btn的重量小于。uilist a(这将覆盖任何共享属性)。ulist组件需要锚点作为子节点。

XML/HTML代码将内容复制到剪贴板。BTN {/* style */}。uilist {/* style */}。uilista {/* style */}

navclass='uilist '

ahref='# '主页/a

ahref='# '关于/a

aclass=' btn 'href=' # '登录/a

/nav

将uilist组件与其他组件轻松组合的一种方法是，用类为uilist的子DOM元素添加样式。虽然这将减少重量，但它的主要优点是它为您提供了处理任何结构样式的子节点的选项。

XML/HTML代码将内容复制到剪贴板。BTN {/* style */}。uilist {/* style */}。uilist-item {/* style */}

navclass='uilist '

a lass=' uilist-item ' href=' # ' Home/a

a lass=' uilist-item ' href=' # '关于/a

spanclass='uilist-item '

aclass=' btn 'href=' # '登录/a

/span

/nav

JavaScript特殊类

使用某种形式的JavaScript特殊类，可以降低组件风格或结构变化导致JavaScript失效的风险。我找到了一个非常有效的方法，就是用一个特定的类——js-*——来做JavaScript钩子，不要在这个类名上添加任何描述。

XML/HTML代码将内容复制到剪贴板

ahref='/log in ' class=' btnbtn-primaryjs-log in '/a

当您修改组件的结构或样式时，它可能会无意中影响必要的JavaScript行为和复杂的函数。这样就可以减少这种可能性。组件修改器

组件通常有一些变化，这些变化与基本组件仅略有不同。例如，不同的背景颜色或边框。创建这些组件变体有两种主要模式。我称它们为“单类名”模式和“多类名”模式。

单类名模式

XML/HTML代码将内容复制到剪贴板。btn，BTN-主要{/*按钮模板样式*/}。BTN-主按钮{/*主按钮的特殊样式*/}

buttonclass='btn '默认/按钮

buttonclass='btn-primary '登录/按钮

多类名模式

XML/HTML代码将内容复制到剪贴板。btn{/*按钮模板样式*/}。BTN-主按钮{/*主按钮的特殊样式*/}

buttonclass='btn '默认/按钮

buttonclass='btnbtn-primary '登录/按钮

如果使用预处理器，可以使用Sass的@extend函数，减少使用“单一类名”模式时所涉及的维护工作。但是，即使有预处理器的帮助，我还是倾向于使用“多类名”模式，在HTML中修改类名。

我发现这是一个更可扩展的模型。例如，实现一个基本的btn组件，并添加五种类型的按钮和三种额外的尺寸。如果使用“多类名”模式，只需要9个类，如果使用“单类名”模式，需要24个类。

如果有必要，它还可以使上下文更容易适应组件。您可能希望对其他组件中出现的任何btn进行一些细节调整。

XML/HTML代码将内容复制到剪贴板

/*“多个类名”样式调整*/

. things . BTN {/*对应风格调整*/}

/*“单类名”样式调整*/

.东西. btn，

.东西. BTN-初级，

.东西. BTN-危险。think . BTN-etc {/*相应的样式调整*/}

“多类名”模式意味着您可以通过使用组件的单个内部选择器来更改所有类型的btn元素的样式。“单一类名”模式意味着您必须考虑所有可能的按钮类型，并在创建新的按钮变体时调整该选择器。结构化的类名

在创建组件时，——添加了“主题”——，其中一些类用于区分组件，一些类用作组件的修饰符，另一些类用于关联DOM节点，这些节点包含在一个更大的抽象组件中。

btn(组件)、btn-primary(修饰符)、brn-group(组件)、btn-group-item(组件子对象)之间的关系很难判断，因为这些名称不能清楚地表达类的用途。没有一致的模式。

在过去的一年里，我一直在尝试命名模式，其目的是帮助我快速理解DOM片段中节点外观之间的关系，而不是来回切换HTML、CSS和JS文件来拼凑网站架构。这种模式主要受BEM系统命名方式的影响，但改编成一种我觉得更容易浏览的形式。

复制代码

代码如下：

t模板名称

t-模板-名称-修饰符-名称

t-template-name _ _子对象

t-template-name _ _ sub-object-modifier-name/PP component-name

组件名修饰符名

组件名称_ _子对象

component-name _ _ sub-object-modifier-name/ppis-state-type/ppjs-action-name

js组件类型

我把一些结构当做抽象的“模板”，把其他的当做更清晰的组件(通常基于“模板”)。但这种区分并不总是必要的。

这只是我目前发现的一个有用的命名模式。命名模式可以采取任何形式。然而，这种命名模式的优点是它消除了模糊的类名，并且只依赖于(单个)连接器，或者下划线，或者驼峰格式。原始文件大小和HTTP压缩的注意事项

任何关于模块化和可扩展CSS的讨论，都是在谈论对文件大小和“扩展”的关注。妮可沙利文在发言中经常提到文件大小存储(和维护改进)，并提到像脸书这样的公司采用这种方法的经验。进一步，我想我会分享一下我对输出进行预处理时的HTTP压缩效果，以及一些关于广泛使用HTML类的事情。

Twitter Bootstrap出来的时候，我重写了编译好的CSS，更好的对比了大小和手动文件。最小化所有文件后，手动操作的CSS文件比预处理器输出的小10%。但是当所有文件都用gzip压缩时，预处理器输出的CSS文件比手工操作输出的小5%。

这就强调了HTTP压缩后比较文件大小的重要性，因为减小的文件大小并不能解释所有的问题。这意味着有经验的CSS开发人员在使用预处理器时，不需要过多关注编译好的CSS中的一定程度的重复，因为经过HTTP压缩后会变小。通过预处理器处理更容易维护的CSS代码的好处，比关注原始CSS和压缩CSS的美观或者文件大小要好。

在另一个实验中，我从互联网上剥离了一个60KB的HTML文件(由很多可重用的组件组成)，删除了每个类属性。经过此处理后，文件大小减少到25KB。原始文件和剥离文件用gzip压缩后，大小分别变成7.6KB和6KB——，相差只有1.6KB，自由使用类导致的实际文件大小的结果已经不值得再强调了。