Analyse approfondie de la sémantique du HTML et des frameworks front-end associés_HTML/Xhtml_Production de pages Web

À 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 des 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

Adhérer au 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...

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

… il n’y a aucune raison inhérente de faire cela. 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 ce que fait 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 :

Code XML/HTMLCopier le contenu dans le presse-papiers

1. <div classe="actualités" >
2.  <h2>Actualitésh2>
3. [contenu de l'actualité]
4. div>

Lorsque le contenu n'est pas évident, l'actualité du nom de 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.
Nom de classe indépendant 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 chaque couche 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 un contenu clair. 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. Faire cela ne rend pas le HTML "sémantique", cela signifie simplement que vous balisez le contenu avec 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 contenir différents types de contenu dans une certaine plage. 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 s'appuie 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.

Éviter l'utilisation de sélecteurs de type pour prendre en charge les classes peut faciliter la fusion des composants. Dans l'exemple suivant, le composant btn et le composant uilist ne sont pas faciles à fusionner. Le problème est que .btn a un poids inférieur à .uilist a (cela remplacera toutes les propriétés partagées). Et le composant ulist nécessite des points d'ancrage comme nœuds enfants.

Code XML/HTMLCopier le contenu dans le presse-papiers

1. .btn { /* styles */ }
2. .uilist { /* styles */ }
3. .uilist a { /* styles */ }
5. <nav class="uilist" >
6.  <a href="#" >Accueila>
7.  <a href="#" >À proposun>
8.  <a classe="btn" href="#">Connexion a> 
9. nav>

Une façon de combiner facilement le composant uilist avec d'autres composants consiste à utiliser des classes pour ajouter des styles aux éléments DOM enfants de uilist. Bien que cela réduise le poids, son principal avantage est qu’il vous donne la possibilité de gérer n’importe quel style structurel de nœuds enfants.

Code XML/HTMLCopier le contenu dans le presse-papiers

1. .btn { /* styles */ }
2. .uilist { /* styles */ }
3. .uilist-item { /* styles */ }
5. <nav class="uilist" >
6.  <une classe="uilist- item" href="#">Accueila> 
7.  <une classe="uilist- article" href="#">À proposa> 
8.  <span class="uilist- article"> 
9.  <a classe="btn" href="#">Connexion a> 
10.  span> 
11. nav>

Classes spécifiques à JavaScript

L'utilisation d'une certaine forme de classes spécifiques à JavaScript peut réduire le risque de rupture de JavaScript en raison de changements dans le style ou la structure des composants. Une méthode que j'ai trouvée et qui fonctionne très bien consiste à utiliser une classe spécifique uniquement pour les hooks JavaScript - js-* - et à n'ajouter aucune description au nom de la classe.

Code XML/HTMLCopier le contenu dans le presse-papiers

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

Lorsque vous modifiez la structure ou le style d'un composant, vous pouvez affecter par inadvertance les comportements JavaScript nécessaires et les fonctions complexes. Cette méthode peut réduire cette possibilité.
Modificateur de composant

Les composants présentent souvent des variations qui ne diffèrent que légèrement du composant de base. Par exemple, différentes couleurs d’arrière-plan ou bordures. Il existe deux modes principaux pour créer des variations de ces composants. Je les appelle le modèle « nom de classe unique » et le modèle « nom de classe multiple ».

Modèle de nom de classe unique

Code XML/HTMLCopier le contenu dans le presse-papiers

1. .btn, .btn-primary { /* Style de modèle de bouton */ }
2. .btn-primary { /* Style spécial du bouton principal */ }
4. <bouton classe="btn" >Par défautbouton>
5. <bouton classe="btn- primaire">Connexionbouton>

Modèles de noms de classes multiples

Code XML/HTMLCopier le contenu dans le presse-papiers

1. .btn { /* Style de modèle de bouton */ }
2. .btn-primary { /* Style spécial du bouton principal */ }
4. <bouton classe="btn" >Par défautbouton>
5. <bouton classe="btn btn -primaire">Connexionbouton>

Si vous utilisez un préprocesseur, vous pouvez utiliser la fonctionnalité @extend de Sass pour réduire une partie du travail de maintenance impliqué lors de l'utilisation du modèle « nom de classe unique ». Cependant, même avec l'aide du préprocesseur, je préfère toujours utiliser le mode "noms de classes multiples" et modifier les noms de classes dans le HTML.

Je trouve que c'est un modèle plus évolutif. Par exemple, vous souhaitez implémenter un composant btn de base et ajouter 5 types de boutons et 3 tailles supplémentaires. Si vous utilisez le mode « Nom de classe multiple », vous n'avez besoin que de 9 classes, et si vous utilisez le mode « Nom de classe unique », vous avez besoin de 24 classes.

Cela permet également d'adapter plus facilement le contexte au composant si nécessaire. Vous souhaiterez peut-être apporter des ajustements détaillés à tout bouton qui apparaît dans d'autres composants.

Code XML/HTMLCopier le contenu dans le presse-papiers

1. /* Ajustement du style "Nom de classe multiple" */
2. .thing .btn { /* Ajustement du style correspondant */ }
4. /* Ajustement du style "Nom de classe unique" */
5. .thing .btn,
6. .thing .btn-primaire,
7. .thing.btn-danger,
8. .thing .btn-etc { /* Ajustement du style correspondant */ }

Le mode "nom multi-classe" signifie que vous n'avez besoin d'utiliser qu'un seul sélecteur de composant interne pour changer le style de tous les types d'éléments btn. Le modèle « nom de classe unique » signifie que vous devez prendre en compte tous les types de boutons possibles et ajuster le sélecteur lors de la création d'une nouvelle variante de bouton.
Nom de la classe structuré

Lorsque vous créez un composant - et y ajoutez un "thème" - certaines classes sont utilisées pour distinguer chaque composant, certaines classes sont utilisées comme modificateurs du composant et d'autres classes sont utilisées pour associer des nœuds DOM ensemble. contenu dans un composant abstrait plus large.

Il est difficile de juger la relation entre btn (composant), btn-primary (modificateur), brn-group (composant) et btn-group-item (sous-objet de composant) car ces noms ne sont pas clairs. Exprimer le but de classe. Il n’y a pas de modèle cohérent.

Au cours de la dernière année, j'ai expérimenté des modèles de dénomination pour m'aider à comprendre rapidement la relation entre les représentations des nœuds dans un fragment DOM sans avoir à basculer entre les fichiers HTML, CSS et JS pour le reconstituer. La structure du site Web. Ce modèle est largement influencé par l'approche de dénomination du système BEM, mais adapté sous une forme que je pense plus facile à naviguer.

Copier le code

Le code est le suivant :

t-template-name
t -template-name--modifier-name
t-template-name__sub-object
t-template-name__sub-object--modifier-name

nom-du composant
nom-du composant--nom-du-modificateur
nom-du-composant__sub-object
nom-du-composant__sub-object--nom-du-modificateur

est-un-type-d'état

js-action-name
js-component-type

Je traite certaines structures comme des "modèles" abstraits et d'autres comme des composants plus clairs (souvent construits sur des "modèles"). Mais cette distinction n'est pas toujours nécessaire.

Ceci n'est qu'un modèle de dénomination que j'ai trouvé utile jusqu'à présent. Le modèle de dénomination peut prendre n’importe quelle forme. Mais l'avantage de ce modèle de dénomination est qu'il élimine les noms de classe ambigus et s'appuie uniquement sur des connecteurs (uniques), des traits de soulignement ou le format camelCase.
Remarques sur la taille du fichier brut et la compression HTTP

Toute discussion sur les CSS modulaires et extensibles impliquera des préoccupations concernant la taille et le « gonflement » des fichiers. Les remarques de Nicole Sullivan mentionnent fréquemment le stockage de la taille des fichiers (et les améliorations de la maintenance), citant l'expérience d'entreprises comme Facebook ayant adopté cette approche. En allant plus loin, j'ai pensé partager certains des effets de compression HTTP que j'ai eu sur la sortie de prétraitement, ainsi qu'une utilisation intensive des classes HTML.

Lorsque Twitter Bootstrap est sorti pour la première fois, j'ai réécrit le CSS compilé pour mieux comparer la taille aux fichiers manipulés manuellement. Après avoir minimisé tous les fichiers, le fichier CSS exploité manuellement était 10 % plus petit que la sortie du préprocesseur. Mais lorsque tous les fichiers sont compressés par gzip, le fichier CSS généré par le préprocesseur est 5 % plus petit que celui d'une opération manuelle.

Cela souligne l'importance de comparer les tailles de fichiers après compression HTTP, car une taille de fichier réduite ne raconte pas toute l'histoire. Cela implique que les développeurs CSS expérimentés utilisant des préprocesseurs ne devraient pas trop s'inquiéter d'un certain degré de duplication dans le CSS compilé, car celui-ci sera plus petit après la compression HTTP. Les avantages du traitement d'un code CSS plus maintenable via un préprocesseur l'emportent sur les préoccupations concernant l'esthétique ou la taille du fichier du CSS brut et du CSS de sortie réduit.

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.