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

Über Semantik

Semantik untersucht die Beziehung zwischen Zeichen und Symbolen und die Bedeutungen, die sie darstellen. In der Linguistik geht es um die Untersuchung der Bedeutung von Symbolen (wie Wörtern, Phrasen oder Lauten) in der Sprache. Im Bereich der Front-End-Entwicklung umfasst die Semantik hauptsächlich die vereinbarte Bedeutung von HTML-Elementen, Attributen und Attributwerten (einschließlich Erweiterungen wie Mikrodaten). Diese formale Konventionssemantik, die häufig in Spezifikationen verwendet wird, kann Programmen (und später an der Entwicklung beteiligten Personen) helfen, alle Aspekte einer Website besser zu verstehen. Selbst wenn die Semantik dieser Elemente, Attribute und Attributwerte formalisiert ist, unterliegen sie dennoch der Anpassung durch Entwickler und kollektiven Entscheidungen. Dadurch ist es möglich, dass die formale Vertragssemantik in Zukunft geändert wird (und dies ist eines der HTML-Designprinzipien).
Unterscheiden Sie verschiedene Arten der HTML-Semantik

Die Einhaltung des Prinzips des Schreibens von „semantischem HTML“ ist eine der Grundlagen der modernen professionellen Frontend-Entwicklung. Die meisten Semantiken beziehen sich auf die aktuelle oder erwartete Art des Inhalts (z. B. h1-Element, lang-Attribut, E-Mail-Wert des Typattributs, Mikrodaten).

Allerdings muss nicht jede Semantik inhaltsorientiert sein. Klassennamen dürfen nicht „semantisch“ sein. Egal wie die Namen lauten, sie müssen eine Bedeutung und einen Zweck haben. Die Semantik von Klassennamen kann sich von der Semantik von HTML-Elementen unterscheiden. Wir können die „globale“ Semantik von HTML-Elementen, bestimmten HTML-Attributen, Mikrodaten usw. verwenden und dann die „lokale“ spezifische Semantik der Website oder Anwendung zur Unterscheidung verwenden. Diese spezifischen Semantiken sind normalerweise in Attributwerten enthalten, z Klassenattribute.

Obwohl diese vermeintliche „Best Practice“ im Klassenattributabschnitt der HTML5-Spezifikation...

wiederholt wird

…ermutigen Sie Entwickler, den Klassenattributwert zur Beschreibung des tatsächlichen Inhalts zu verwenden, anstatt den Inhalt zu beschreiben, der voraussichtlich angezeigt wird.

…es gibt keinen inhärenten Grund dafür. Tatsächlich kann dieser Ansatz bei großen Websites oder Anwendungen oft zu einem Hindernis werden.

HTML-Elemente und andere Attribute stellen bereits Semantik auf Inhaltsebene bereit.
Für Maschinen oder Besucher können Klassennamen nur wenige oder keine nützlichen semantischen Informationen preisgeben. Sofern es sich nicht um einen kleinen Teil des Namens handelt, der vereinbart wurde (auch maschinenlesbar) – Mikroformate
Der Hauptzweck des Klassennamens besteht darin, ein Hook für CSS und JavaScript zu werden. Wenn Sie Ihren Seiten keine Präsentation und kein Verhalten hinzufügen müssen, müssen Sie Ihrem HTML wahrscheinlich keine Klassennamen hinzufügen. Klassennamen sollten Entwicklern nützliche Informationen vermitteln. Wenn Sie ein DOM-Fragment lesen, hilft es zu verstehen, was ein bestimmter Klassenname bewirkt. Gerade in einem mehrköpfigen Entwicklungsteam sind nicht nur Frontend-Entwickler mit HTML-Komponenten beschäftigt.

Geben Sie ein sehr einfaches Beispiel:

XML/HTML-CodeInhalt in die Zwischenablage kopieren

1. <div Klasse="news" >
2.  <h2>Neuigkeitenh2>
3. [Nachrichteninhalt]
4. div>

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.

XML/HTML-CodeInhalt in die Zwischenablage kopieren

1. .btn { /* Styles */ }
2. .uilist { /* Styles */ }
3. .uilist a { /* Styles */ }
5. <nav class="uilist" >
6.  <a href="#" >Homea>
7.  <a href="#" >Übera>
8.  <a Klasse="btn" href="#">Anmelden a> 
9. nav>

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.

XML/HTML-CodeInhalt in die Zwischenablage kopieren

1. .btn { /* Styles */ }
2. .uilist { /* Styles */ }
3. .uilist-item { /* Styles */ }
5. <nav class="uilist" >
6.  <a Klasse="uilist- item" href="#">Homea> 
7.  <a Klasse="uilist- item" href="#">Abouta> 
8.  <span class="uilist- Artikel"> 
9.  <a Klasse="btn" href="#">Anmelden a> 
10.  span> 
11. nav>

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.

XML/HTML-CodeInhalt in die Zwischenablage kopieren

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

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

XML/HTML-CodeInhalt in die Zwischenablage kopieren

1. .btn, .btn-primary { /* Schaltflächenvorlagenstil */ }
2. .btn-primary { /* Spezieller Stil der primären Schaltfläche */ }
4. <Schaltfläche Klasse="btn" >StandardSchaltfläche>
5. <Schaltfläche Klasse="btn- primär">AnmeldenSchaltfläche>

Mehrere Klassennamenmuster

XML/HTML-CodeInhalt in die Zwischenablage kopieren

1. .btn { /* Schaltflächenvorlagenstil */ }
2. .btn-primary { /* Spezieller Stil der primären Schaltfläche */ }
4. <Schaltfläche Klasse="btn" >StandardSchaltfläche>
5. <Schaltfläche Klasse="btn btn -primär">AnmeldenSchaltfläche>

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.

XML/HTML-CodeInhalt in die Zwischenablage kopieren

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.