Zuerst habe ich mir html5rocks.com Quellen angesehen. Sieht nach vertrauenswürdiger Seite aus. Und sie schließen Tags dort.
%Vor%Dann habe ich HTML5demos angeschaut, und das tun sie nicht
%Vor% Worauf du dich beziehst, heißt Leere Elemente In der HTML5-Spezifikation und entsprechend der Spezifikation dürfen das Zeichen / haben oder nicht, unmittelbar vor dem schließenden Zeichen > .
Siehe den Abschnitt 8.1.2.1 Start tags , item 6 von der HTML5-Spezifikation , die besagt:
Wenn das Element eines der void-Elemente ist oder wenn das Element ein fremdes Element ist, dann kann es ein einzelnes U + 002F SOLIDUS-Zeichen (/) geben. Dieses Zeichen hat keine Auswirkungen auf leere Elemente, aber bei fremden Elementen wird das Start-Tag als selbstschließend bezeichnet.
Auch wenn es optional ist, würde ich es vorziehen, / zu benutzen, es macht Code in meiner Meinung lesbarer. Ansonsten muss ich weiterlesen, um herauszufinden, ob es ein schließendes Tag für das tatsächliche Tag gibt oder nicht.
Void Elements in HTML5 kann entweder mit /> oder nur mit% geschlossen werden Code%. Foreign Elements (dh Elemente aus dem MathML-Namespace und dem SVG-Namespace), kann selbstschließend sein und tun erfordert, dass ihr öffnendes Tag mit > vervollständigt wird.
Da die HTML5-Spezifikation nicht viele Hinweise darauf gibt, welcher Weg besser wäre, müssen wir andere Aspekte berücksichtigen, wenn wir uns entscheiden, Void-Elemente mit /> oder \> zu schließen. Hier sind die folgenden Aspekte, die ich bei der Entscheidung für ein Projekt beachten möchte:
Wartbarkeit
Ich persönlich finde es viel einfacher, Fehler zu erkennen, insbesondere Fehler bei der Tag-Paarung, und verstehe die Datei im Allgemeinen, wenn sie > tag closings für Void Elements verwendet. Dies gilt umso mehr, wenn es auch Foreign Elements gibt, da diese % cop_de% tag closings verwenden müssen.
Ich habe auch festgestellt, dass viele Syntaxhervorhebungsregelsätze nicht 100% HTML5-konform sind und durch nicht mit /> -Tagabschlüssen mit Elementen, die kein separates schließendes Tag haben, verwirrt werden können . Dies variiert natürlich je nach Editor, und viele IDEs haben eine robustere Syntax, die andere einfachere Editoren hervorhebt, so dass Ihre Erfahrung unterschiedlich sein kann. Aber wenn Wartbarkeit und einfache Bearbeitung wichtig sind, ist dies ein Faktor, der oft übersehen werden kann. p>
Seitengröße
Wenn Sie eine große Anzahl von Void Elements haben und die Seitenleistung für Ihre Anwendung von entscheidender Bedeutung ist, hilft das Entfernen nicht benötigter Zeichen, die Nutzlastgröße für Ihre Seite zu reduzieren. Dies bedeutet, dass Ihre Antwort in einer kleineren Anzahl von Paketen gesendet werden kann, was bedeutet, dass weniger Roundtrips benötigt werden , was insgesamt zu einer schnelleren Reaktion führt.
Bei 99% der Anwendungen gibt es jedoch viele andere Dinge, die Sie für die Optimierung Ihrer Seite verwenden können. Dies hat einen viel größeren Einfluss auf die Seitenladezeit als das Entfernen von überflüssigen /> . Zeichen von Leere Elemente.
Maschinenlesbarkeit
Ähnlich wie Syntax-Hervorhebungsregeln nicht so flexibel sind, wie sie sein müssten, werden Sie wahrscheinlich dasselbe für HTML- und / oder XML-Verarbeitungsbibliotheken finden, die Sie möglicherweise zum Verarbeiten einer HTML-Seite verwenden möchten. Sie werden wahrscheinlich feststellen, dass eine Syntax, die näher an XML liegt, besser von Verarbeitungsbibliotheken unterstützt wird. Wenn Sie erwarten, dass andere Entwickler Ihr HTML verarbeiten, können Sie mit der am weitesten unterstützten Syntax ein breiteres Spektrum an Werkzeugen verwenden.
Fazit
Wenn Sie am Ende des Tages entscheiden, dass Sie immer noch die Reduzierung der Seitengröße benötigen, indem Sie die zusätzlichen /> -Zeichen entfernen, denke ich, dass der beste Weg wäre, all Ihren HTML-Code durch einen Filter zu leiten Das kann den HTML-Code parsen und die Zeichen für Sie automatisch entfernen, wenn die HTML5-Spezifikation dies zulässt. Dies hat den Vorteil, dass Sie die Wartbarkeit nicht opfern müssen, während Sie immer noch die Seitengröße reduzieren können. Sie können sich sogar dafür entscheiden, Ihre Ausgabe über diesen Filter zu übergeben, wenn Sie wissen, dass die Anfrage von anderem Code geparst werden soll. Dadurch können Sie auch den Aspekt der Maschinenlesbarkeit beibehalten.
Der Nachteil ist, dass Sie in Ihrer Pipeline einen zusätzlichen Verarbeitungsschritt haben, der die Komplexität erhöht und möglicherweise die Geschwindigkeit der Seitenladegeschwindigkeit nicht kompensiert.
Letztendlich sollten Sie die Geschwindigkeit und Nutzlastgröße Ihrer Seiten messen und diese Messungen mit der Priorität der oben aufgeführten Aspekte kombinieren und den Aufruf für Ihr spezifisches Projekt durchführen. Es gibt keine One Size Fits All-Antwort, aber die richtige Wahl ist wahrscheinlich eine Art Mittelweg.
Tags und Links html5