HTML: Optionale schließende Tags einschließen oder ausschließen?

149

Einige HTML ^1- Abschluss-Tags sind optional , z.

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

Hinweis: Nicht zu verwechseln mit schließenden Tags, deren Aufnahme verboten ist, dh:

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Hinweis: xhtml unterscheidet sich von HTML. xhtml ist eine Form von xml, für die jedes Element ein schließendes Tag haben muss. Ein End - Tag kann verboten in html, noch zwingend in xhtml.

Sind die optionalen schließenden Tags

idealerweise enthalten , aber wir akzeptieren sie, wenn Sie sie vergessen haben, oder
Idealerweise nicht enthalten, aber wir akzeptieren sie, wenn Sie sie eingeben

Mit anderen Worten, sollte ich sie einschließen oder sollte ich sie nicht einschließen?

In der HTML 4.01-Spezifikation wird davon gesprochen, dass das Schließen von Element-Tags optional ist , es wird jedoch nicht angegeben, ob es vorzuziehen ist, sie einzuschließen, oder ob es vorzuziehen ist, sie nicht einzuschließen.

Andererseits sagt ein zufälliger Artikel über DevGuru :

Das Ending-Tag ist optional. Es wird jedoch empfohlen, dass es enthalten ist.

Der Grund, den ich frage, ist, dass Sie nur wissen, dass es aus Kompatibilitätsgründen optional ist. und sie hätten sie gemacht ( obligatorisch | verboten ), wenn sie hätten können.

Anders ausgedrückt: Was hat HTML 1, 2, 3 in Bezug auf diese jetzt optionalen, schließenden Tags getan? Was macht HTML 5? Und was soll ich tun?

Hinweis

Einige Elemente in HTML dürfen keine schließenden Tags haben. Sie können damit nicht einverstanden sein, aber das ist die Spezifikation, und es steht nicht zur Debatte. Ich frage nach optionalen schließenden Tags und was die Absicht war.

Fußnoten

¹ HTML 4.01

html html4

— Ian Boyd
quelle

4

Schwierige Frage ... einige der w3c-Empfehlungen enthalten sogar Beispiele, die beides können: w3.org/TR/html401/struct/global.html#id-and-class Das erste Beispiel enthält schließende </p>Tags und das zweite lässt sie weg !

— Richard JP Le Guen

Nur zur Verdeutlichung: Bei verbotenen Tags in HTML5 besteht die "explizite" / XML-gültige Lösung darin, sie mit einem zu schließen />, z. B. <meta charset="utf-8" />obwohl <meta charset="utf-8">HTML5 gültig ist.

— Cboettig

@cboettig Ja. <meta charset="utf-8" />ist ungültig HTML, muss es sein <meta charset="utf-8">. Auf der anderen Seite <meta charset="tuf-8">ist xhtml ungültig , es muss sein<meta charset="utf-8" />

— Ian Boyd

@ IanBoyd wirklich? in HTML5? Das Entwurf des W3C-Handbuchs für polyglot html / xhtml besagt, dass es <meta charset="UTF-8"/>mit dem schließenden Tag verwendet werden soll. Wie könnten sonst Polyglot oder XHTML jemals als HTML5 und XML validiert werden?

— Cboettig

@cboettig Du hast recht. Polyglot Markup (dh HTML-kompatible XHTML-Dokumente ) kann kein gültiges HTML 4.01 sein. HTML5 (noch in Arbeit) hat den Begriff Void- Elemente - Elemente, die kein End-Tag haben können . Vermutlich sind die meisten Browser sanft und verzeihen Ihre Markup-Fehler.

— Ian Boyd

49

Die optionalen sind alle diejenigen, die semantisch klar sein sollten, wo sie enden, ohne das End-Tag zu benötigen. EG <li>impliziert jeweils ein, </li>wenn es kein direkt davor gibt.

Allen verbotenen End-Tags würde sofort das End-Tag folgen, so dass es überflüssig wäre, <img src="blah" alt="blah"></img>jedes Mal etwas eingeben zu müssen .

Ich verwende fast immer die optionalen Tags (es sei denn, ich habe einen sehr guten Grund, dies nicht zu tun), da sie zu besser lesbarem und aktualisierbarem Code führen.

— ein Slum
quelle

18

Ich sehe es jetzt. <LI>ist wie eine Kugel. Niemand würde einen ganzen Punkt mit Aufzählungszeichen einpacken wollen <LI>...</LI>. Auf diese Weise LIstimmt das überein, was die Leute natürlich während des Markups schreiben würden. Sames gilt für eine Absatzmarke ( <P>), in der Textverarbeitung Sie hinzufügen Absatzmarke am Anfang eines Absatzes; und nicht am Ende eines jeden auch. In dieser Interpretation sind die schließenden Tags optional, da keine normale Person daran denken würde, sie zu haben. Außerdem hat das Element selbst keinen Inhalt - das Element ist der Inhalt.

— Ian Boyd

8

Was meinst du ich fast immer verwenden die optionalen Tags - meinen Sie , dass Sie umfassen die End - Tag, oder dass Sie es auslassen ? (Ich hatte den Eindruck, dass Sie es einschließen , als ich Ihre Antwort las - aber der Kommentar oben von Ian Boyd gibt mir den Eindruck, dass Sie es ausschließen .)

— KajMagnus

3

@ IanBoyd Und für den letzten Absatz?

— Pacerier

22

@ Pacerier Seit Hunderten von Jahren schreiben Menschen Textabschnitte. Niemand war jemals verwirrt, wenn ein Absatz endet.

— Ian Boyd

4

Relevanter Link für HTML5, für diejenigen, die diese Antwort gefunden haben, als sie versucht haben, die eigentliche Referenzdokumentation zu finden: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

Es gibt Fälle, in denen explizite Tags helfen, aber manchmal ist es unnötige Pedanterie.

Beachten Sie, dass die HTML-Spezifikation klar angibt, wann das Auslassen von Tags gültig ist, sodass dies nicht immer ein Fehler ist.

Zum Beispiel brauchen Sie nie </body></html>. Niemand erinnert sich jemals daran, dies <tbody>explizit auszudrücken (bis zu dem Punkt, dass XHTML Ausnahmen dafür gemacht hat).

Sie brauchen es nicht, es </head><body>sei denn, Sie haben DOM-manipulierende Skripte, die tatsächlich suchen <head>(dann ist es besser, sie explizit zu schließen, da Regeln für das implizite Ende von <head>Sie überraschen könnten).

Verschachtelte Listen sind eigentlich besser ohne </li>, weil es dann schwieriger ist, einen fehlerhaften ul > ulBaum zu erstellen .

Gültig:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Ungültig:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

Beachten Sie auch, dass End-Tags impliziert sind, unabhängig davon, ob Sie versuchen, alle Elemente zu schließen oder nicht. Durch das Setzen von End-Tags wird das Parsen nicht automatisch robuster:

<p>foo <p>bar</p> baz</p>

wird analysiert als:

<p>foo</p><p>bar</p> baz

Dies kann nur hilfreich sein, wenn Sie Dokumente validieren.

— Kornel
quelle

4

Warten Sie, warum wird <p>foo <p>bar</p> baz</p>nicht als zwei verschachtelte pTags analysiert ?

— Eric

19

Weil ein <P>Element keine Elemente auf Blockebene enthalten kann und <P>ein Element auf Blockebene ist. From ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "Das P-Element stellt einen Absatz dar. Es darf keine Elemente auf Blockebene enthalten (einschließlich P selbst)."

— Ian Boyd

1

@IanBoyd Meinst du, kann unabhängig von den CSS-Regeln keine Elemente auf Blockebene enthalten?

— Pacerier

6

@ Pacerier CSS kann DOM in keiner Weise beeinflussen. DOM wird zuerst analysiert und dann von CSS angezeigt. Die CSS- blockAnzeige unterscheidet sich grundlegend vom HTML-Inhalt auf Blockebene (es kommt nur vor, dass die meisten HTML-Elemente auf Blockebene standardmäßig als CSS-Blöcke angezeigt werden).

— Kornel

2

@ anton1980 Nein, das ist nicht dasselbe. Die Behandlung ausgelassener optionaler schließender Tags ist klar spezifiziert und funktioniert in allen kompatiblen Browsern zuverlässig. OTOH ein Make-up <t>wird nicht so funktionieren <title>.

— Kornel

18

Ich füge hier einige Links hinzu, um Ihnen bei der Geschichte von HTML zu helfen und die verschiedenen Widersprüche zu verstehen. Dies ist nicht die Antwort auf Ihre Frage, aber Sie werden mehr wissen, nachdem Sie diese verschiedenen Zusammenfassungen gelesen haben.

Einige Auszüge aus Dive Into HTML5 :

[D] Die Tatsache, dass "kaputtes" HTML-Markup in Webbrowsern immer noch funktionierte, führte dazu, dass Autoren kaputte HTML-Seiten erstellten. Viele kaputte Seiten. Schätzungen zufolge weisen heute über 99% der HTML-Seiten im Web mindestens einen Fehler auf. Da diese Fehler jedoch nicht dazu führen, dass Browser sichtbare Fehlermeldungen anzeigen, werden sie von niemandem behoben.

Das W3C sah dies als ein grundlegendes Problem mit dem Web an und machte sich daran, es zu korrigieren. XML, das 1997 veröffentlicht wurde, brach von der Tradition der Kundenvergebung ab und forderte, dass alle Programme, die XML konsumierten, sogenannte „Wohlgeformtheitsfehler“ als schwerwiegend behandeln müssen. Dieses Konzept des Versagens des ersten Fehlers wurde nach dem griechischen Führer Draco, der die Todesstrafe für relativ geringfügige Verstöße gegen seine Gesetze einführte , als „drakonische Fehlerbehandlung“ bekannt . Als das W3C HTML als XML-Vokabular umformulierte, forderten sie, dass alle Dokumente mit dem neuen bereitgestellt werdenapplication/xhtml+xml MIME-Typ bereitgestellt werden, einer drakonischen Fehlerbehandlung unterliegen. Wenn es auf Ihrer XHTML-Seite […] nur einen einzigen Fehler in Bezug auf die Formgebung gäbe, hätten Webbrowser keine andere Wahl, als die Verarbeitung zu beenden und dem Endbenutzer eine Fehlermeldung anzuzeigen.

Diese Idee war nicht allgemein beliebt. Mit einer geschätzten Fehlerrate von 99% auf vorhandenen Seiten, der allgegenwärtigen Möglichkeit, Fehler für den Endbenutzer anzuzeigen, und dem Mangel an neuen Funktionen in XHTML 1.0 und 1.1, um die Kosten zu rechtfertigen, wurden Webautoren grundsätzlich ignoriert application/xhtml+xml. Das heißt aber nicht, dass sie XHTML völlig ignoriert haben. Oh, definitiv nicht. Anhang C der XHTML 1.0-Spezifikation gab den Webautoren der Welt eine Lücke: „Verwenden Sie etwas, das der XHTML-Syntax ähnelt, aber bedienen Sie es weiterhin mit dertext/html MIME-Typ.“ Und genau das haben Tausende von Webentwicklern getan: Sie haben ein Upgrade auf die XHTML-Syntax durchgeführt, diese aber weiterhin mit einem Text / HTML-MIME-Typ bereitgestellt.

Noch heute behaupten Millionen von Webseiten, XHTML zu sein. Sie beginnen mit dem XHTML-Doctype in der ersten Zeile, verwenden Tag-Namen in Kleinbuchstaben, verwenden Anführungszeichen um Attributwerte und fügen nach leeren Elementen wie <br />und einen abschließenden Schrägstrich hinzu <hr />. Aber nur ein winziger Bruchteil dieser Seiten wird mit dem application/xhtml+xmlMIME-Typ bereitgestellt, der die drakonische Fehlerbehandlung von XML auslösen würde. Jede Seite, die mit einem MIME-Typ von bedient wirdtext/html - unabhängig von Doctype, Syntax oder Codierungsstil - wird mithilfe eines „verzeihenden“ HTML-Parsers analysiert, wobei Markup-Fehler stillschweigend ignoriert werden und Endbenutzer (oder andere Personen) niemals benachrichtigt werden, selbst wenn die Seiten sind technisch kaputt.

XHTML 1.0 enthielt diese Lücke, XHTML 1.1 schloss sie jedoch, und das nie abgeschlossene XHTML 2.0 setzte die Tradition fort, eine drakonische Fehlerbehandlung zu fordern. Und deshalb gibt es Milliarden von Seiten, die behaupten, XHTML 1.0 zu sein, und nur eine Handvoll, die behaupten, XHTML 1.1 (oder XHTML 2.0) zu sein. Verwenden Sie also wirklich XHTML? Überprüfen Sie Ihren MIME-Typ. (Wenn Sie nicht wissen, welchen MIME-Typ Sie verwenden, kann ich Ihnen so ziemlich garantieren, dass Sie ihn noch verwenden text/html.) Wenn Sie Ihre Seiten nicht mit einem MIME-Typ versorgen application/xhtml+xml, Ihrem sogenannten "XHTML" ist nur XML im Namen.

[D] Die Leute, die vorgeschlagen hatten, HTML und HTML-Formulare weiterzuentwickeln, standen vor zwei Möglichkeiten: aufgeben oder ihre Arbeit außerhalb des W3C fortsetzen. Sie entschieden sich für Letzteres, registrierten die whatwg.orgDomain und im Juni 2004 wurde die WHAT-Arbeitsgruppe gegründet .

[D] Die WAS-Arbeitsgruppe arbeitete auch leise an ein paar anderen Dingen. Eine davon war eine Spezifikation, die ursprünglich als Web Forms 2.0 bezeichnet wurde und HTML-Formularen neue Arten von Steuerelementen hinzufügte. (Weitere Informationen zu Webformularen finden Sie in A Form of Madness .) Ein weiterer Entwurf war eine Spezifikation mit dem Namen „Web Applications 1.0“, die wichtige neue Funktionen wie eine Zeichenfläche im Direktmodus enthielt und native Unterstützung für Audio und Video ohne Plugins .

Im Oktober 2009 wurde das W3C die XHTML 2-Arbeitsgruppe und gab diese Erklärung ab, um ihre Entscheidung zu erläutern :

Als W3C im März 2007 die Arbeitsgruppen HTML und XHTML 2 ankündigte, gaben wir an, dass wir den Markt für XHTML 2 weiterhin überwachen werden. W3C erkennt die Bedeutung eines klaren Signals für die Community über die Zukunft von HTML an.

Obwohl wir den Wert der Beiträge der XHTML 2-Arbeitsgruppe im Laufe der Jahre anerkennen, hat das W3C-Management nach Diskussion mit den Teilnehmern beschlossen, die Charta der Arbeitsgruppe Ende 2009 auslaufen zu lassen und nicht zu verlängern.

Diejenigen, die gewinnen, sind diejenigen, die versenden.

— Srikar Doddi
quelle

12

Der Grund, den ich frage, ist, dass Sie nur wissen, dass es aus Kompatibilitätsgründen optional ist. und sie hätten sie gemacht (obligatorisch | verboten), wenn sie hätten können.

Das ist eine interessante Schlussfolgerung. Ich habe gelesen, dass fast immer, wenn ein Tag zuverlässig abgeleitet werden kann, das Tag optional ist. Das Design legt nahe, dass die Absicht darin bestand, das Schreiben schnell und einfach zu gestalten.

Was hat HTML 1, 2, 3 in Bezug auf diese jetzt optionalen, schließenden Tags getan?

Die DTD für HTML 2 ist in den RFC eingebettet , der zusammen mit der ursprünglichen HTML-DTD überall optionale Start- und End-Tags enthält.

HTML 3 wurde aufgegeben (dank der Browserkriege) und durch HTML 3.2 ersetzt (das den damaligen aktuellen Status des Webs beschreiben sollte).

Was macht HTML 5?

HTML 5 war von Anfang an darauf ausgerichtet, "die Kuhpfade zu ebnen".

Und was soll ich machen?

Ah, das ist subjektiv und argumentativ :)

Einige Leute denken, dass explizite Tags für die Lesbarkeit und Wartbarkeit besser sind, da sie vor den Augen des Lesers stehen.

Einige Leute denken, dass abgeleitete Tags für die Lesbarkeit und Wartbarkeit besser sind, da sie den Editor nicht überladen.

— QUentin
quelle

1

+1 Ich hatte nicht an den Begriff "zuverlässig abgeleitet" gedacht. Das spricht also für die Idee, dass es auf die eine oder andere Weise keine wirkliche Absicht gab. Ich nahm an, dass die Spezifikation versuchte, so gut wie möglich mit vorhandenen HTML-Inhalten und HTML-Spezifikationen kompatibel zu sein.

— Ian Boyd

Entschuldigung, Dave, ich habe es Aslum gegeben. Er braucht den Repräsentanten :) Aber Sie haben die gleiche Idee, mit mehr verlinkten und zitierten Inhalten. Aber schöne Antwort.

— Ian Boyd

8

Was macht HTML 5?

Die Antwort auf diese Frage finden Sie im W3C-Arbeitsentwurf: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

Und was soll ich machen?

Es ist eine Frage des Stils. Ich versuche, End-Tags niemals wegzulassen, weil es mir hilft, streng zu sein und keine notwendigen Tags wegzulassen.

— Ghoppe
quelle

+1 für den Link zum Entwurf der HTML 5-Spezifikation und den entsprechenden Abschnitt. Aber HTML 5 sagt nicht so oder so.

— Ian Boyd

6

Wenn es überflüssig ist, lassen Sie es weg.

Wenn es einem Zweck dient (sogar einem scheinbar trivialen Zweck, wie dem Beruhigen Ihrer IDE oder dem Beruhigen Ihrer Augen), lassen Sie es in.

In einer genau definierten Spezifikation werden selten optionale Elemente angezeigt, die das Verhalten nicht beeinflussen. Mit Ausnahme von "Kommentaren" natürlich. Die HTML-Spezifikation ist jedoch weniger eine Entwurfsspezifikation als vielmehr ein Dokument über den Stand der aktuellen Hauptimplementierungen. Wenn ein Element in HTML optional ist und keinen Zweck zu erfüllen scheint, können wir davon ausgehen, dass die optionale Natur lediglich die Dokumentation einer Eigenart in einem bestimmten Browser ist.

Wenn Sie sich den oben verlinkten HTML-5-RFC-Abschnitt ansehen, sehen Sie, dass die optionalen Tags seltsamerweise mit dem Vorhandensein von Kommentaren verknüpft sind! Das sollte Ihnen sagen, dass die Autoren keine Designhüte tragen. Sie spielen stattdessen das Spiel "Dokumentieren Sie die Macken" in wichtigen Implementierungen. Daher können wir die Spezifikation in dieser Hinsicht nicht allzu ernst nehmen.

Die Lösung lautet also: Schwitzen Sie nicht. Gehen Sie zu etwas über, das wirklich wichtig ist. :) :)

— John
quelle

5

Ich denke, die beste Antwort ist das Schließen von Tags zur Lesbarkeit oder Fehlererkennung. Wenn Sie jedoch viel generiertes HTML (z. B. Datentabellen) haben, können Sie erhebliche Bandbreite sparen, indem Sie optionale Tags weglassen.

— Gabe
quelle

2

Richard: Wenn Sie tief verschachtelte Strukturen haben, ist es für Sie viel einfacher, Fehler zu finden, da die schließenden Tags mehr Informationen über die Absicht enthalten.

— Gabe

1

Ich denke, "schließende Tags geben mehr Informationen über Absichten" ist die beste prägnante Antwort auf diese Frage. Argumentiert einen guten klaren Grund auf die eine oder andere Weise.

— squarecandy

4

Meine Empfehlung ist, dass Sie die meisten optionalen Close-Tags und alle optionalen Attribute, mit denen Sie durchkommen können, weglassen. Viele IDEs werden sich beschweren, so dass Sie möglicherweise nicht in der Lage sind, einige davon wegzulassen, aber es ist im Allgemeinen besser für kleinere Dateigrößen und weniger Unordnung. Wenn Sie Codegeneratoren haben, lassen Sie dort definitiv End-Tags weg, da Sie dadurch eine gute Größenreduzierung erzielen können. Normalerweise spielt es auf die eine oder andere Weise keine Rolle.

Aber wenn es darauf ankommt, dann handeln Sie danach. Bei einigen meiner jüngsten Arbeiten konnte ich die Größe meines gerenderten HTML-Codes von 1,5 MB auf 800 KB reduzieren, indem ich die meisten generierten End- und redundanten Wertattribute für das offene Tag eliminierte, bei dem der Text des Elements mit dem Text identisch war Wert. Ich habe ungefähr 200 Tags. Ich könnte dies auf eine ganz andere Weise implementieren, aber das wäre mehr Arbeit ($$$), so dass ich die Seite auf einfache Weise reaktionsfähiger machen kann.

Nur aus Neugier stellte ich fest, dass ich 20 KB sparen könnte, wenn ich Anführungszeichen um Attribute entferne, die sie nicht benötigen, aber meine IDE (Visual Studio) mag es nicht. Ich war auch überrascht, dass die wirklich lange ID, die ASP.NET generiert, 20% meiner Datei ausmacht.

Die Idee, dass wir jemals einen relevanten Bruchteil von HTML streng gültig bekommen könnten, war in erster Linie falsch. Tun Sie also, was für Sie und Ihre Kunden am besten funktioniert. Die meisten Tools, die ich jemals gesehen oder verwendet habe, sagen, dass sie xhtml generieren, aber sie funktionieren nicht wirklich zu 100%, und die strikte Einhaltung hat sowieso keinen Vorteil.

— user1777246
quelle

Ich kann es kaum akzeptieren, optionale End-Tags wegzulassen, aber ich finde es eine ziemlich schlechte Idee, Anführungszeichen für Attribute wegzulassen. Sie riskieren, dass Ihre Website auf diese Weise in einigen Browsern beschädigt wird. Wenn Sie 800-KB-HTML-Dateien haben, machen Sie etwas schwerwiegendes falsch.

— Christoph

2

@Christoph: Das Weglassen optionaler End-Tags (wie </p>oder </li>) ist gemäß der HTML-Spezifikation vollkommen in Ordnung. Wenn der Browser das nicht versteht, liegt ein Problem mit dem Browser vor.

— Konrad Borowski

2

Persönlich bin ich ein Fan von XHTML und wie Ghoppe: "Ich versuche, End-Tags niemals wegzulassen, weil es mir hilft, streng zu sein und keine notwendigen Tags wegzulassen."

aber

Wenn Sie absichtlich HTML 4.n verwenden, kann man nicht behaupten, dass das Einschließen von HTML 4.n das Konsumieren des Dokuments erleichtert, da der Begriff der Wohlgeformtheit im Gegensatz zur Gültigkeit ein XML-Konzept ist und Sie diesen Vorteil verlieren, wenn Sie bestimmte enge Tags verbieten . Das einzige Problem wird also die Gültigkeit ... und wenn es ohne sie noch gültig ist ... können Sie genauso gut die Bandbreite sparen, nein?

— Richard JP Le Guen
quelle

2

Die Verwendung von End-Tags erleichtert den Umgang mit Fragmenten, da deren Verhalten nicht von Geschwisterelementen abhängt. Dieser Grund allein sollte überzeugend genug sein. Beschäftigt sich jemand mehr mit monolithischen HTML-Dokumenten?

— CurtainDog
quelle

1

In einigen Sprachen mit geschweiften Klammern wie C # können Sie die geschweiften Klammern um eine if-Anweisung weglassen, wenn sie nur zwei Zeilen lang ist. beispielsweise...

if ([Bedingung])
[Code]

aber das kannst du nicht machen ...

if ([Bedingung])
[Code]
[Code]

Die dritte Zeile ist nicht Teil der if-Anweisung. Es beeinträchtigt die Lesbarkeit, und Fehler können leicht eingeführt und schwer zu finden sein.

Aus den gleichen Gründen schließe ich alle Tags. Tags wie das img-Tag müssen noch geschlossen werden, nur nicht mit einem separaten schließenden Tag.

— MiguelR
quelle

Können Sie ein Beispiel für HTML nennen, das so schwierig ist? Nach meiner Erfahrung täuschen optionale End-Tags nicht so sehr.

— Kornel

Ich erinnere mich, dass ich vor einigen Jahren ein Problem mit IE7 hatte, bei dem ich ein öffnendes Li-Tag in einer separaten Zeile des darin enthaltenen Textes fand, ohne dass Li geschlossen wurde. IE7 behandelte alle Aufzählungszeichen wie eine große Aufzählungszeichen. Wenn Sie das Tag und den Text in eine Zeile setzen oder das Tag schließen, wird das Problem behoben. Ich kann das jetzt allerdings nicht tadeln, also hatte es wahrscheinlich auch etwas mit dem CSS im Spiel zu tun. aber ich würde dir nicht die Schuld geben, dass du das als "Ich habe total eine Freundin ... in Kanada!" Geschichte.

— MiguelR

0

Wenn Sie einen HTML-Parser schreiben würden, wäre es einfacher, HTML zu analysieren, das optionale schließende Tags enthält, oder HTML, das dies nicht tut? Ich denke, die optionalen schließenden Tags würden es einfacher machen, da ich nicht ableiten müsste, wo sich das schließende Tag befinden sollte.

Aus diesem Grund füge ich immer die optionalen schließenden Tags hinzu - in der Theorie, dass meine Seite möglicherweise schneller gerendert wird, da ich weniger Arbeit für den HTML-Parser des Browsers erstelle.

— Joel Mueller
quelle

1

Ich bin nicht einverstanden; Der Begriff der Wohlgeformtheit im Gegensatz zur Gültigkeit ist ein reines XML-Konzept und wird irrelevant, wenn Sie Elemente haben, deren enge Tags verboten sind .

— Richard JP Le Guen

1

Ich verstehe das, aber das gerenderte DOM-Element hat sowohl einen Anfang als auch ein Ende, auch wenn Ihr HTML-Tag dies nicht tut. Wenn Sie ein <li>Tag ohne schließendes Tag einfügen, muss der Browser irgendwann entscheiden, wo das Element endet, und so tun, als hätten Sie an diesem Punkt ein End-Tag eingefügt. Dies mag eine relativ triviale Menge an Logik sein, aber "einige" sind immer noch mehr als "keine", und ich halte es nicht für unangemessen anzunehmen, dass das Weglassen optionaler End-Tags mehr Arbeit für den Browser bedeutet, als sie einzuschließen.

— Joel Mueller

Es ist ein interessanter Punkt, aber ich bin immer noch anderer Meinung. die engen Tags sind optional , da sie und damit implizit nach Validierungsregeln erforderlich wäre ... also wenn der Parser ein Punkt erreicht , wo es hat ein End - Tag nach Validierung sein, es könnte nicht behaupten, dass die Aufgabe des Verzehrs Ein schließendes Tag (falls vorhanden) würde es nur verlangsamen?

— Richard JP Le Guen

@Richard - Ich denke, das hängt von der tatsächlichen Implementierung in einem bestimmten Browser ab, aber es fällt mir schwer, die Idee zu würdigen, dass es für die Leistung schlechter wäre, explizit anzugeben, wo ein Element enden soll, als dem Browser zu sagen, dass er es herausfinden soll Sie.

— Joel Mueller

@RichardJPLeGuen Ich denke, es hängt alles davon ab, wie genau die Regeln aussehen. Wenn Sie ein schließen </table>und Ihr Stapel enthält <table><tbody><tr><td>, können Sie einfach alles schließen, bis Sie mit dem übereinstimmen <table>. Ähnliches gilt für das Öffnen <p>in einem Nicht-Uhr-Kontext. Aber es kann viel schwierigere Fälle geben, ich weiß es nicht.

— Maaartinus

-1

Tun Sie alles, was Sie für besser lesbar und wartbar halten.

Persönlich wäre ich immer geneigt zu schließen <td>und <tr>, aber ich würde mich nie darum kümmern <li>.

— Matthew Wilson
quelle

1

Ich hoffte auf eine Anleitung für die ursprüngliche Designentscheidung und darauf, dass sie x gemacht hätten, wenn sie hätten können.

— Ian Boyd

Was ist der Unterschied zwischen <td>und <li>das macht dich nicht störend <li>? Für mich gibt es kaum einen Unterschied.

— Ghoppe

Es gibt keinen technischen Unterschied, es ist rein subjektiv. Ich habe das Gefühl, dass ich den HTML-Code besser lesen kann, wenn ich td und tr schließe. Aber ich habe nie das Bedürfnis mit li gespürt.

— Matthew Wilson

-2

Verwenden Sie für verbotene Schließarten folgende Syntax: <img />Mit dem />, um das in XML akzeptierte Tag zu schließen

— Dani
quelle

1

Es funktioniert nicht in HTML4 (es entspricht der obskuren SGML-Syntax, die etwas anderes bewirkt). In HTML5 ist es erlaubt, aber bedeutungslos.

— Kornel