Es gibt eine Vielzahl von HTML, die man einfach aus dem Quell-HTML *weglassen* kann und es ist immer noch gültiger Markup.
Sieht das nicht seltsam aus?
<p>Paragraph one.
<p>Paragraph two.
<p>Paragraph three.Das tut es bei mir, aber die schließenden </p>-Tags sind optional. Der Browser erkennt, dass er sie benötigt, und stellt sie trotzdem korrekt im DOM dar.
Das passiert wahrscheinlich auch mit HTML, das Sie schreiben, und Sie wissen es gar nicht. Zum Beispiel...
<table>
<tr>
<td></td>
</tr>
</table>Das sieht für mich perfekt aus, aber der Browser fügt ein <tbody> drumherum um dieses <tr> ein. Optional in HTML, aber das DOM fügt es trotzdem ein.
Sogar ein <body> ist in gleicher Weise nicht wirklich nötig! Jens Oliver Meiert teilt mehr mit
<link rel=stylesheet href=default.css>Einige Attribute sind ebenfalls „optional“ in dem Sinne, dass sie Standardwerte haben, die man weglassen kann. Zum Beispiel ist ein <button> automatisch ein <button type="submit">.
Jens argumentiert weiter, dass dies fast als Optimierungen betrachtet wird, da es die Dateigröße und somit die Netzwerkgeschwindigkeit reduziert.
Ich persönlich mag HTML, das so aussieht, nicht. Das macht mir Sorgen, da es tatsächliche Situationen gibt, die schiefgehen, wenn man es nicht richtig macht. Nicht alle Dateinamen können ohne Anführungszeichen bleiben. Manchmal bedeutet das Weglassen von schließenden Tags, dass ein Geschwisterelement auf eine Weise umschlossen wird, die man nicht erwartet hat. Ich würde sogar einen winzigen Hauch von Leistung für eine widerstandsfähigere Website opfern. Ähnlich wie ich weiß, dass * {} kein besonders effizienter Selektor ist, aber sich Sorgen um die Leistung von CSS-Selektoren zu machen, ist in den meisten Fällen eine fehlgeleitete Sorge (der Geschwindigkeitsunterschied ist vernachlässigbar).
Ich mag JSX eigentlich sehr, da es Sie zwingt, „HTML“ streng zu schreiben. Diese Strenge hilft auch bei der Codeformatierung (z. B. Prettier) als Bonus.
Aber hey, ein Performance-Gewinn ist ein Performance-Gewinn, daher würde ich nichts dagegen sagen, wenn Tooling diese Dinge automatisch in kompilierte Ausgaben einfügt. Das kann anscheinend HTMLminifier.
Ich entwickle ein Mega-Menü-WordPress-Plugin für einen Kunden. Es beinhaltet einige eingefügte
und ich bemerkte, dass in Chrome (wahrscheinlich auch in anderen Browsern) automatisch die schließenden
in das Menü eingefügt wurden, obwohl der Quellcode sie nicht enthielt... das gefiel mir offensichtlich nicht, also habe ich mich bemüht, den Fehler zu finden, der die fehlenden schließenden Tags verursachte. Wenn ich nicht daran gedacht hätte, danach zu suchen, hätte ich es wahrscheinlich übersehen. Dieses Verhalten macht die Diagnose solcher Dinge umständlicher.
Sieht aus, als hätte es die div-Tags in meiner Antwort entfernt. Ups.
Wenn ich mich recht erinnere, erlaubte XHTML den Autoren nicht mehr, „optionale“ schließende Tags wegzulassen, d.h. wenn man es tat, war das XHTML nicht gültig. HTML und Webbrowser lassen Autoren vielleicht viele schlechte Gewohnheiten durchgehen, aber es ist einfach kein guter Stil und ist bei vernachlässigbaren Leistungssteigerungen nicht von Wert, würde ich sagen. Denken Sie an andere, die Ihren hässlichen Code pflegen müssen, nachdem Sie diesen Job verlassen haben usw. Durch das Weglassen von schließenden Tags können Sie auch „Pretty-Print“-Tools verwirren, wenn Sie jemals eines verwenden müssen. Schreiben Sie schönen Code.
Ich stimme Chris vollkommen zu. Ich schlage meinen Kollegen auch vor, immer das
type-Attribut in jedem Button anzugeben, auch wenn es ein Submit-Button ist, weil es ihn expliziter macht. Das Entfernen unnötiger Tags und Attribute ist eine Aufgabe für einen Minifier, und ich lasse ihn das gerne für mich tun :)Ich erinnere mich an eine Zeit, als wir
<option>zum Beispiel nicht schlossen.Ich glaube, das war vor der Einführung von XHTML. XHTML zwang uns, unsere Tags zu schließen (
<img />,<br />usw.). Ich denke, es ist jetzt sauberer und lässt weniger Raum für Interpretation.Das Entfernen von schließenden Tags könnte den Bandbreitenverbrauch reduzieren, aber
1) Ich wette, das ist nach GZIP-Komprimierung nicht viel. All diese schließenden LIs werden über das Netz nicht jeweils 5 Bytes wiegen.
2) Was macht das mit der Seiten-Parser-Zeit? Ich vermute, es verlangsamt den Seiten-Parser erheblich.
Außerdem hat Colin Recht – Lesbarkeit ist auch ein wichtiges Argument.
Die seltsamen Inkonsistenzen in HTML ergeben viel mehr Sinn, wenn man sie im Kontext der Evolution betrachtet. Da sich die Anforderungen an das Markup ändern, agieren wir sowohl als Einflussfaktoren als auch als Akteure des Wandels... Wir entwickeln HTML gerade so weit, dass es sich an unsere neuen Bedürfnisse anpasst, aber nicht so sehr, dass es etwas völlig Neues wird.
Wie bei jeder biologischen Evolution entstehen dabei Reste… rudimentäre Dinge. Im Gegensatz zu diesem Vergleich können wir jedoch die Browserunterstützung für diese nunmehr veralteten Funktionen einfach einstellen, damit wir nicht hier sitzen und uns fragen, wozu dieser spezielle Kram gut ist.
Diese Bereinigung lässt jedoch viel Raum für Inkonsistenzen… wie die Tatsache, dass einige Elemente ihren Abschluss **benötigen**, einige Abschlüsse optional sind, einige Elemente gar keinen haben und einige (optional) selbstschließende Schrägstriche haben.
Ich glaube, das Beispiel mit dem Absatz funktioniert, weil verschachtelte Absatz-Elemente kein gültiges HTML sind, also würde der Browser das wissen und das Element schließen, bevor er ein neues für Sie beginnt.
Keine Quellen dafür, das ist einfach, wie ich darüber denke
Das lässt mich auch fragen, ob irgendein HTML-Minifier diese Tricks verwendet!
Schließende Listen-Element-Tags () sind ebenfalls optional
Remy Sharp, erklärt, warum die p-Tags so sind:
Ich wünschte, wir könnten es für Debugging-Zwecke deaktivieren.
Bei der Arbeit am Frontend sehen wir manchmal seltsames Verhalten bei verschiedenen Browsern.
In den meisten Fällen hat der Entwickler einen kleinen Fehler gemacht (schließender Tag auf falscher Schleifenebene usw.) und die Browser neigen dazu, ihn unterschiedlich zu „fixen“.
Es kann manchmal mühsam sein, zu beweisen, dass es sich nicht um ein CSS-Problem handelt, da man den Originalcode nicht immer sehen kann.
Wenn Sie einen guten Validator wie CSS HTML Validator verwenden, können Sie eine Option einstellen, die die optionalen End-Tags erzwingt.
Aus irgendeinem Grund wurde auf der Homepage das erste Beispiel normalisiert, um die fehlenden Tags einzuschließen.
Frage: Einige HTML-Minifier entfernen standardmäßig nicht
</p>oder</li>. Was könnte passieren, wenn sie diese standardmäßig entfernen würden?Rückblickend auf die Entwicklung von Markup-Sprachen gaben SGML und DTDs HTML und seiner DTD Leben. Als HTML 5 aufkam, wurde die DTD nicht mehr als praktikabel angesehen.
Die Fähigkeit, eine DTD zu lesen, um abzuleiten, wie das Markup angewendet werden soll, wurde im Browser vergraben.
!–=================== Absätze =======================================–>
!ELEMENT P – O (%inline;)* — paragraph –>
!ATTLIST P
%attrs; — %coreattrs, %i18n, %events —
>
“-” Start-Tag erforderlich
O End-Tag optional
https://www.w3.org/TR/html4/struct/text.html#edef-P