Eingehende Analyse der Semantik von HTML und verwandten Front-End-Frameworks_HTML/Xhtml_Webseitenproduktion

Wenn der Inhalt nicht offensichtlich ist, können Ihnen die Nachrichten zum Klassennamen nichts sagen. Es gibt Ihnen keine Informationen über die Gesamtstruktur der Komponente, und sobald der Inhalt keine „Neuigkeiten“ mehr ist, erscheint es sehr unangemessen, diesen Klassennamen zu verwenden. Die Semantik der Klassennamen ist zu nah am Inhalt und die Architektur ist weder einfach zu erweitern noch für andere Entwickler einfach zu verwenden.
Inhaltsunabhängiger Klassenname

Ein besserer Ansatz ist das Extrahieren der Semantik von Klassennamen aus der Struktur und Funktionalität eines Entwurfsmusters. Komponenten, deren Klassennamen nichts mit ihrem Inhalt zu tun haben, sind leichter wiederverwendbar.

Wir sollten keine Angst davor haben, die Beziehung zwischen den einzelnen Ebenen klar und eindeutig zu gestalten (dies sollte sich auf die Strukturebene, die Inhaltsebene usw. beziehen, Anmerkung des Übersetzers), anstatt Klassennamen zu verwenden, um den klaren Inhalt strikt wiederzugeben. Dadurch werden die Klassennamen nicht „semantisch“, sondern nur gezeigt, dass ihre Semantik nicht vom Inhalt abhängt. Wir sollten auch keine Angst davor haben, zusätzliche HTML-Elemente zu verwenden, solange diese Ihnen dabei helfen, stärkere, flexiblere und wiederverwendbarere Komponenten zu erstellen. Dadurch wird der HTML-Code nicht „semantisch“, sondern es bedeutet lediglich, dass Sie den Inhalt mit mehr als der Mindestanzahl an Elementen auszeichnen.
Front-End-Architektur

Der Zweck von Komponenten, Vorlagen und objektorientierter Architektur besteht darin, eine begrenzte Anzahl wiederverwendbarer Komponenten entwickeln zu können, die unterschiedliche Inhaltstypen innerhalb eines bestimmten Bereichs enthalten können. Bei großen Anwendungen ist das Wichtigste an der Semantik von Klassennamen, dass sie ihren Hauptzweck mit Pragmatismus erfüllen – die Bereitstellung sinnvoller, flexibler und wiederverwendbarer Leistungs- oder Verhaltens-Hooks für die Entwicklung oder Verwendung.
Wiederverwendbare und zusammensetzbare Komponenten

Im Allgemeinen muss erweiterbares HTML/CSS auf Klassen in HTML angewiesen sein, um wiederverwendbare Komponenten zu erstellen. Eine flexible, wiederverwendbare Komponente, die weder auf einen bestimmten Teil des DOM-Baums angewiesen ist noch einen bestimmten Elementtyp verwendet. Es sollte an verschiedene Behälter anpassbar sein und das Thema kann leicht geändert werden. Bei Bedarf können zusätzliche HTML-Elemente (über die zum Markieren des Inhalts erforderlichen Elemente hinaus) eine Komponente robuster machen. Das Medienobjekt von Nicole Sullivan ist ein gutes Beispiel.

Das Vermeiden der Verwendung von Typselektoren zur Unterstützung von Klassen kann das Zusammenführen von Komponenten erleichtern. Im folgenden Beispiel lassen sich die BTN-Komponente und die Uilist-Komponente nicht einfach zusammenführen. Das Problem besteht darin, dass .btn eine geringere Gewichtung hat als .uilist a (dadurch werden alle gemeinsam genutzten Eigenschaften überschrieben). Und die ulist-Komponente erfordert Ankerpunkte als untergeordnete Knoten.

Eine Möglichkeit, die uilist-Komponente einfach mit anderen Komponenten zu kombinieren, besteht darin, Klassen zu verwenden, um Stile zu den untergeordneten DOM-Elementen von uilist hinzuzufügen. Obwohl dadurch das Gewicht reduziert wird, besteht der Hauptvorteil darin, dass Sie die Möglichkeit haben, jeden Strukturstil von untergeordneten Knoten zu verarbeiten.

JavaScript-spezifische Klassen

Die Verwendung irgendeiner Form von JavaScript-spezifischen Klassen kann das Risiko verringern, dass JavaScript aufgrund von Änderungen im Komponentenstil oder in der Struktur kaputt geht. Eine Methode, die meiner Meinung nach sehr gut funktioniert, besteht darin, eine bestimmte Klasse nur für JavaScript-Hooks zu verwenden – js-* – und dem Klassennamen keine Beschreibung hinzuzufügen.

Wenn Sie die Struktur oder den Stil einer Komponente ändern, kann dies unbeabsichtigt Auswirkungen auf notwendige JavaScript-Verhaltensweisen und komplexe Funktionen haben. Diese Methode kann die Möglichkeit verringern.
Komponentenmodifikator

Komponenten weisen häufig Variationen auf, die sich nur geringfügig von der Basiskomponente unterscheiden. Zum Beispiel unterschiedliche Hintergrundfarben oder Ränder. Es gibt zwei Hauptmodi zum Erstellen von Variationen dieser Komponenten. Ich nenne sie das Muster „Einzelklassenname“ und das Muster „Mehrfachklassenname“.

Einzelnes Klassennamenmuster

Mehrere Klassennamenmuster

Wenn Sie einen Präprozessor verwenden, können Sie die @extend-Funktion von Sass verwenden, um einen Teil des Wartungsaufwands zu reduzieren, der mit der Verwendung des Musters „Einzelklassenname“ verbunden ist. Selbst mit Hilfe des Präprozessors verwende ich jedoch immer noch lieber den Modus „Mehrere Klassennamen“ und ändere die Klassennamen im HTML.

Ich finde, dass dies ein besser skalierbares Muster ist. Sie möchten beispielsweise eine grundlegende BTN-Komponente implementieren und 5 Arten von Schaltflächen und 3 zusätzliche Größen hinzufügen. Wenn Sie den Modus „Mehrere Klassennamen“ verwenden, benötigen Sie nur 9 Klassen, und wenn Sie den Modus „Einzelner Klassenname“ verwenden, benötigen Sie 24 Klassen.

Es erleichtert auch die Anpassung des Kontexts an die Komponente bei Bedarf. Möglicherweise möchten Sie einige detaillierte Anpassungen an BTN vornehmen, die in anderen Komponenten angezeigt werden.

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.

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.