La sémantique du HTML et ses frameworks front-end associés

À propos de la sémantique

La sémantique étudie la relation entre les signes et les symboles, et les significations qu'ils représentent. En linguistique, c'est l'étude de la signification des symboles (tels que des mots, des phrases ou des sons) dans le langage. Dans le domaine du développement front-end, la sémantique implique principalement les significations convenues des éléments HTML, des attributs et des valeurs d'attribut (y compris les extensions telles que Microdata). Ces sémantiques de conventions formelles, couramment utilisées dans les spécifications, peuvent aider les programmes (et plus tard les personnes impliquées dans le développement) à mieux comprendre tous les aspects d'un site Web. Cependant, même si la sémantique de ces éléments, attributs et valeurs d'attributs est formalisée, ils restent soumis à l'adaptation des développeurs et aux choix collectifs. Cela permet que la sémantique formelle du contrat puisse être modifiée à l'avenir (et c'est l'un des principes de conception HTML).
Distinguer les différents types de sémantique HTML

Suivre le principe d'écriture du « HTML sémantique » est l'un des fondements du développement front-end professionnel moderne. La plupart des sémantiques sont liées à la nature actuelle ou attendue du contenu (ex : élément h1, attribut lang, valeur email de l'attribut type, microdonnées).

Cependant, toutes les sémantiques ne doivent pas nécessairement être orientées vers le contenu. Les noms de classe ne peuvent pas être « sémantiques ». Quels que soient les noms, ils doivent avoir une signification et un but. La sémantique des noms de classes peut être différente de celle des éléments HTML. Nous pouvons utiliser la sémantique « globale » des éléments HTML, de certains attributs HTML, des microdonnées, etc., puis utiliser la sémantique spécifique « locale » du site Web ou de l'application pour différencier ces sémantiques spécifiques qui sont généralement incluses dans les valeurs d'attribut, telles que. attributs de classe.

Bien que cette supposée « meilleure pratique » soit réitérée dans la section des attributs de classe de la spécification HTML5...

...les développeurs sont encouragés à utiliser la valeur de l'attribut de classe pour décrire le contenu réel, plutôt que la description Ce qui devrait être affiché.

… Il n'y a aucune raison intrinsèque pour laquelle je dois faire ça. En fait, lorsque cette approche est utilisée sur des sites Web ou des applications de grande taille, elle peut souvent devenir un frein.

Les éléments HTML et autres attributs fournissent déjà une sémantique au niveau du contenu
Pour les machines ou les visiteurs, les noms de classe peuvent révéler peu ou pas d'informations sémantiques utiles. À moins qu'il ne s'agisse d'une petite partie du nom qui a été convenue (également lisible par machine) - Mircoformats
L'objectif principal du nom de classe est de devenir un hook pour CSS et JavaScript. Si vous n'avez pas besoin d'ajouter une présentation et un comportement à vos pages, vous n'avez probablement pas besoin d'ajouter des noms de classe
à votre code HTML. Les noms de classe devraient transmettre des informations utiles aux développeurs. Lorsque vous lisez un fragment DOM, cela vous aidera à comprendre le but spécifique d'un certain nom de classe. Surtout dans une équipe de développement composée de plusieurs personnes, les développeurs front-end ne sont pas les seuls à s'occuper des composants HTML.

Donnez un exemple très simple :

<p class="news">
    <h2>News</h2>
    [news content]   
</p>

Lorsque le contenu n'est pas évident, l'actualité du nom de la classe ne peut rien vous dire. Il ne vous donne aucune information sur la structure globale du composant, et une fois que le contenu n'est plus « d'actualité », il semble très inapproprié d'utiliser ce nom de classe. La sémantique des noms de classe est trop proche du contenu et l'architecture n'est ni facile à étendre ni à utiliser par d'autres développeurs.
Noms de classe indépendants du contenu

Extraire la sémantique des noms de classe de la structure et des fonctionnalités d'un modèle de conception est une meilleure approche. Les composants dont les noms de classe n'ont rien à voir avec leur contenu sont plus réutilisables.

Nous ne devons pas avoir peur de rendre la relation entre les différentes couches claire et sans ambiguïté (cela doit faire référence à la couche de structure, à la couche de contenu, etc., ndlr), plutôt que d'utiliser des noms de classe pour refléter strictement des contenu . Faire cela ne rend pas les noms de classe « sémantiques », cela montre simplement que leur sémantique ne dépend pas du contenu. Nous ne devrions pas non plus avoir peur d'utiliser des éléments HTML supplémentaires tant qu'ils vous aident à créer des composants plus solides, plus flexibles et plus réutilisables. Cela ne rend pas le HTML "sémantique", cela signifie simplement que vous balisez le contenu en utilisant plus que le nombre minimum d'éléments.
Architecture frontale

Le but des composants, des modèles et de l'architecture orientée objet est de pouvoir développer un nombre limité de composants réutilisables pouvant être inclus dans un certain portée Différents types de contenu. Dans les grandes applications, la chose la plus importante à propos de la sémantique des noms de classe est qu'ils remplissent leur objectif principal avec pragmatisme : fournir des performances significatives, flexibles et réutilisables ou des points d'ancrage comportementaux pour le développement ou l'utilisation.
Composants réutilisables et composables

En général, le HTML/CSS extensible doit s'appuyer sur des classes en HTML afin de créer des composants réutilisables. Un composant flexible et réutilisable qui ne repose ni sur une certaine partie de l'arborescence DOM ni sur un type d'élément spécifique. Il doit être adaptable à différents conteneurs et le thème peut être modifié facilement. Si nécessaire, des éléments HTML supplémentaires (au-delà de ceux nécessaires au balisage du contenu) peuvent rendre un composant plus robuste. L'objet médiatique de Nicole Sullivan en est un bon exemple.

避免用类型选择器支持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</p> <p>component-name
component-name--modifier-name
component-name__sub-object
component-name__sub-object--modifier-name</p> <p>is-state-type</p> <p>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的美观或文件大小。

Dans une autre expérience, j'ai récupéré un fichier HTML de 60 Ko sur Internet (composé de nombreux composants réutilisables) et supprimé chacun de ses attributs de classe. Après ce traitement, la taille du fichier est réduite à 25 Ko. Lorsque le fichier original et le fichier extrait sont compressés par gzip, leurs tailles deviennent respectivement 7,6 Ko et 6 Ko, soit une différence de seulement 1,6 Ko. Les conséquences réelles sur la taille des fichiers d'une utilisation libérale des classes ne valent plus la peine d'être soulignées.

Pour plus d'articles sur la sémantique du HTML et des frameworks front-end associés, veuillez faire attention au site Web PHP chinois !