Detaillierte Analyse der HTML-Semantik und der zugehörigen Front-End-Frameworks

Über Semantik

Die Semantik ist die Lehre von der Beziehung zwischen Zeichen und Symbolen und den Bedeutungen, die sie repräsentieren. In der Linguistik befasst sie sich mit der Bedeutung dieser Zeichen (wie etwa Wörter, Ausdrücke oder Laute) in der Sprache. Im Bereich der Front-End-Entwicklung bezieht sich Semantik hauptsächlich auf die vereinbarten Bedeutungen von HTML-Elementen, Attributen und Attributwerten (einschließlich Erweiterungen wie Mikrodaten). Diese formal vereinbarte Semantik, die häufig in Spezifikationen verwendet wird, kann Programmierern (und später Entwicklern) helfen, verschiedene Aspekte einer Website besser zu verstehen. Auch wenn die Semantik dieser Elemente, Attribute und Attributwerte formalisiert ist, unterliegt sie dennoch der Bequemlichkeit und kollektiven Wahl des Entwicklers. Dadurch ist es möglich, dass die formal vereinbarte Semantik in der Zukunft geändert werden kann (was eines der Designprinzipien von HTML ist).
Unterscheiden Sie zwischen verschiedenen Arten von HTML-Semantik

Das Einhalten des Prinzips des Schreibens von „semantischem HTML“ ist eine der Grundlagen der modernen professionellen Front-End-Entwicklung. Die meisten Semantiken beziehen sich auf die Art des aktuellen oder erwarteten Inhalts (z. B. h1-Element, Lang-Attribut, E-Mail-Wert des Typattributs, Mikrodaten).

Allerdings muss nicht jede Semantik inhaltsorientiert sein. Klassennamen können nicht „semantikfrei“ sein. Wie auch immer sie genannt werden, 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 verwenden, um sie zu unterscheiden. Diese spezifische Semantik ist normalerweise im Attributwert enthalten, z. B. im Klassenattribut.

Obwohl diese angebliche „Best Practice“ im Abschnitt zum Klassenattribut der HTML5-Spezifikation wiederholt wird …

…ermutigt Entwickler, Klassenattributwerte zu verwenden, um den tatsächlichen Inhalt und nicht den gewünschten Inhalt zu beschreiben.

…es gibt keinen grundsätzlichen Grund dafür. Tatsächlich wird dieser Ansatz bei großen Websites oder Anwendungen oft zu einem Hindernis.

HTML-Elemente und andere Attribute sorgen bereits auf Inhaltsebene für Semantik
Klassennamen geben für einen maschinellen oder menschlichen Besucher kaum oder keine nützlichen semantischen Informationen preis. Sofern es sich nicht um einen der wenigen Namen handelt, auf die man sich geeinigt hat (und die auch maschinenlesbar sind) - Mikroformate
Klassennamen werden hauptsächlich als Hooks für CSS und JavaScript verwendet. Wenn Sie Ihrer Seite weder eine Präsentation noch ein Verhalten hinzufügen müssen, müssen Sie Ihrem HTML wahrscheinlich keine Klassen hinzufügen.
Klassennamen sollten Entwicklern nützliche Informationen übermitteln. Wenn Sie einen DOM-Ausschnitt lesen, ist es hilfreich zu verstehen, was ein bestimmter Klassenname macht. Gerade in einem mehrköpfigen Entwicklungsteam beschäftigen sich nicht nur die Frontend-Entwickler mit HTML-Komponenten.

Nehmen wir ein sehr einfaches Beispiel:

Wenn der Inhalt nicht offensichtlich ist, sagen Ihnen die Neuigkeiten zum Klassennamen nichts. Es sagt nichts über die Gesamtstruktur der Komponente aus und sobald der Inhalt nichts „Neues“ mehr ist, ist die Verwendung dieser Klasse keine gute Wahl. Die Semantik der Klassennamen ist zu nah am Inhalt und die Architektur lässt sich weder leicht erweitern noch von anderen Entwicklern leicht verwenden.
Klassennamen, die für den Inhalt nicht relevant sind

Ein besserer Ansatz besteht darin, die Semantik von Klassennamen aus der Struktur und Funktionalität eines Entwurfsmusters zu extrahieren. Komponenten, deren Klassennamen nichts mit dem Inhalt zu tun haben, sind besser wiederverwendbar.

Wir sollten keine Angst davor haben, die Beziehungen zwischen den Ebenen klar und deutlich zu machen, anstatt Klassennamen zu verwenden, um spezifische Inhalte strikt widerzuspiegeln. Dadurch werden die Klassennamen nicht „semantikfrei“, es bedeutet nur, 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, leistungsfähigere, flexiblere und wiederverwendbare Komponenten zu erstellen. Dadurch wird Ihr HTML nicht „unsemantisch“, es bedeutet nur, dass Sie mehr als die Mindestanzahl an Elementen zum Markieren Ihres Inhalts verwenden.
Front-End-Architektur

Der Zweck von Komponenten, Vorlagen und objektorientierter Architektur besteht darin, eine begrenzte Anzahl wiederverwendbarer Komponenten entwickeln zu können, die eine Reihe verschiedener Inhaltstypen enthalten können. Bei großen Anwendungen besteht das Wichtigste an der Semantik von Klassennamen darin, dass sie pragmatisch verwendet werden können, um ihren Hauptzweck zu erfüllen – nämlich Entwicklern aussagekräftige, flexible und wiederverwendbare Hooks für die Präsentation oder das Verhalten bereitzustellen.
Wiederverwendbare und zusammensetzbare Komponenten

Im Allgemeinen muss erweiterbares HTML/CSS auf Klassen in HTML basieren, um wiederverwendbare Komponenten zu erstellen. Eine flexible, wiederverwendbare Komponente, die nicht von einem bestimmten Teil des DOM-Baums abhängig ist oder die Verwendung eines bestimmten Elementtyps erfordert. Es sollte sich an verschiedene Container anpassen und leicht mit einem neuen Design versehen werden können. Bei Bedarf können zusätzliche HTML-Elemente (über das zur Auszeichnung des Inhalts erforderliche Maß hinaus) die Robustheit der Komponente steigern. Ein gutes Beispiel ist das Medienobjekt von Nicole Sullivan.

Durch die Vermeidung von Typselektoren zugunsten von Klassen lassen sich Komponenten einfacher zusammenführen. Im folgenden Beispiel lassen sich die Btn-Komponente und die Uilist-Komponente nicht einfach zusammenführen. Das Problem besteht darin, dass die .btn-Datei ein geringeres Gewicht hat als die .uilist-Datei (die alle gemeinsamen Eigenschaften überschreibt). Und die Ulist-Komponente benötigt einen Anker als untergeordneten Knoten.

Eine Möglichkeit, die UILIST-Komponente einfach mit anderen Komponenten zu kombinieren, besteht darin, Klassen zu verwenden, um den untergeordneten DOM-Elementen der UILIST Stile hinzuzufügen. Dadurch wird zwar das Gewicht reduziert, der Hauptvorteil liegt jedoch darin, dass Sie die Möglichkeit haben, jeden beliebigen Strukturstil der untergeordneten Knoten zu handhaben.

JavaScript-spezifische Klassen

Die Verwendung einer Form von JavaScript-spezifischen Klassen kann das Risiko verringern, dass JavaScript aufgrund von Änderungen im Komponentenstil oder in der Struktur nicht mehr funktioniert. Eine Methode, die sich meiner Erfahrung nach bewährt hat, besteht darin, eine bestimmte Klasse nur für JavaScript-Hooks – js-* – zu verwenden und dem Klassennamen keine Beschreibung hinzuzufügen.

Dieser Ansatz verringert die Wahrscheinlichkeit, dass Sie beim Ändern der Struktur oder der Stile einer Komponente versehentlich erforderliches JavaScript-Verhalten und komplexe Funktionen beschädigen.
Komponentenmodifikator

Komponenten haben oft Varianten, die sich nur geringfügig von der Basiskomponente unterscheiden. Beispielsweise eine andere Hintergrundfarbe oder ein anderer Rahmen. Es gibt zwei Hauptmodi zum Erstellen von Variationen dieser Komponenten. Ich nenne sie das Muster „einzelner Klassenname“ und das Muster „mehrere Klassennamen“.

Einzelklassennamenmodus

Muster für mehrere Klassennamen

Wenn Sie einen Präprozessor verwenden, können Sie mithilfe der @extend-Funktionalität von Sass einen Teil des Wartungsaufwands reduzieren, der bei Verwendung des Musters „einzelner Klassenname“ anfällt. Allerdings bevorzuge ich auch mit Hilfe eines Präprozessors weiterhin die Verwendung des Musters „mehrere Klassennamen“ und die Änderung der Klassennamen im HTML.

Ich finde, dass dies ein skalierbareres Muster ist. Beispielsweise um eine grundlegende Btn-Komponente zu implementieren und 5 Arten von Schaltflächen und 3 zusätzliche Größen hinzuzufügen. Wenn Sie den Modus „mehrere Klassennamen“ verwenden, benötigen Sie hierfür nur 9 Klassen, während Sie im Modus „einzelner Klassenname“ 24 Klassen benötigen.

Außerdem lässt sich der Kontext bei Bedarf leichter an die Komponente anpassen. Möglicherweise möchten Sie einige detaillierte Anpassungen an jedem BNT vornehmen, das in anderen Komponenten erscheint.

Das Muster „mehrere Klassennamen“ bedeutet, dass Sie den Stil aller Arten von BTN-Elementen mit nur einem einzigen internen Komponentenselektor ändern können. Das Muster „einzelner Klassenname“ bedeutet, dass Sie alle möglichen Schaltflächentypen berücksichtigen und den Selektor anpassen müssen, wenn Sie eine neue Schaltflächenvariante erstellen.
Strukturelle Klassennamen

Beim Erstellen einer Komponente – und beim Hinzufügen eines „Themas“ – werden einige Klassen verwendet, um zwischen Komponenten zu unterscheiden, einige Klassen werden als Modifikatoren von Komponenten verwendet und andere Klassen werden verwendet, um DOM-Knoten zu verknüpfen, die alle zusammen in einer größeren abstrakten Komponente enthalten sind.

Es ist schwierig, die Beziehung zwischen btn (Komponente), btn-primary (Modifikator), brn-group (Komponente) und btn-group-item (Komponenten-Kind) zu bestimmen, da diese Namen den Zweck der Klasse nicht klar zum Ausdruck bringen. Es gibt kein einheitliches Muster.

Im letzten Jahr habe ich mit Benennungsmustern experimentiert, die mir helfen, die Beziehungen zwischen den Darstellungen von Knoten in einem DOM-Fragment schnell zu verstehen, ohne zwischen HTML-, CSS- und JS-Dateien hin- und herwechseln zu müssen, um die Architektur der Site zusammenzusetzen. Dieses Muster wurde stark vom Benennungsansatz des BEM-Systems beeinflusst, aber in eine Form angepasst, die meiner Meinung nach einfacher zu navigieren ist.

Ich behandle einige Strukturen als abstrakte „Vorlagen“ und andere als klarere Komponenten (die normalerweise auf den „Vorlagen“ aufbauen). Aber diese Unterscheidung ist nicht immer notwendig.

Dies ist nur ein Benennungsmuster, das ich bisher als nützlich empfunden habe. Das Benennungsmuster kann jede beliebige Form haben. Der Vorteil dieses Benennungsmusters besteht jedoch darin, dass es mehrdeutige Klassennamen eliminiert und nur auf (einzelnen) Bindestrichen, Unterstrichen oder CamelCase basiert.
Hinweise zur ursprünglichen Dateigröße und HTTP-Komprimierung

Jede Diskussion über modulares und skalierbares CSS bringt unweigerlich Bedenken hinsichtlich der Dateigröße und der „Aufblähung“ auf. Nicole Sullivan erwähnte in ihren Ausführungen häufig die Verbesserungen bei der Speicherung von Dateigrößen (und der Wartung) und berichtete von den Erfahrungen von Unternehmen wie Facebook, die diesen Ansatz verfolgen. Ich möchte noch einen Schritt weitergehen und einige der Dinge teilen, die ich mit der HTTP-Komprimierung mache, wenn ich die Ausgabe vorverarbeite, und einige Dinge, bei denen die HTML-Klasse in großem Umfang genutzt wird.

Als Twitter Bootstrap zum ersten Mal herauskam, habe ich das kompilierte CSS neu geschrieben, um die Dateigröße besser mit dem vergleichen zu können, was ich manuell tun könnte. Nach dem Minimieren aller Dateien ist die manuell bearbeitete CSS-Datei 10 % kleiner als die Ausgabe des Präprozessors. Aber nachdem alle Dateien gzippt wurden, war die CSS-Ausgabedatei des Präprozessors 5 % kleiner als beim manuellen Prozess.

Dies unterstreicht, wie wichtig es ist, die Dateigrößen nach der HTTP-Komprimierung zu vergleichen, da die reduzierte Dateigröße nicht die ganze Geschichte erzählt. Das bedeutet, dass erfahrene CSS-Entwickler sich bei der Verwendung von Präprozessoren keine allzu großen Sorgen über einen gewissen Grad an Duplizierung im kompilierten CSS machen müssen, weil dieser nach der HTTP-Komprimierung geringer ausfällt. Die Vorteile eines besser wartbaren CSS-Codes durch einen Präprozessor überwiegen die Bedenken hinsichtlich der Ästhetik oder Dateigröße des ursprünglichen CSS und der minimierten Ausgabe.

In einem anderen Experiment habe ich eine 60 KB große HTML-Datei (bestehend aus vielen wiederverwendbaren Komponenten) aus dem Internet gekratzt und sämtliche Klassenattribute daraus entfernt. Nach dieser Verarbeitung wird die Dateigröße auf 25 KB reduziert. Wenn sowohl die Originaldatei als auch die gerippte Datei mit gzip komprimiert werden, beträgt ihre Größe 7,6 KB bzw. 6 KB – ein Unterschied von nur 1,6 KB. Die tatsächlichen Auswirkungen auf die Dateigröße, die sich aus der großzügigen Verwendung von Klassen ergeben, sind nicht mehr der Rede wert.