HTML: Fügen oder ausschließen, optional Endtags?

https://stackoverflow.com/questions/3008593

26-09-2019
|

Frage

Einige HTML ¹ Schließen-Tags sind optional , das heißt:

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

Hinweis: Nicht mit dem Schließen-Tags verwechselt werden, die sind verboten enthalten sein, das heißt:.

</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, das erfordert alle -Element einen schließenden Tag haben. Ein End-Tag sein verboten in html, noch obligatorisch in xhtml.

Sind die optionalen schließenden Tags

idealerweise enthalten , aber wir werden sie akzeptieren, wenn Sie sie vergessen, oder
idealerweise nicht enthalten, aber wir werden sie an, wenn Sie sie setzen in

Mit anderen Worten: sollte Ich schließe sie, oder sollte ich nicht sind sie?

Die HTML 4.01-Spezifikation spricht über das Schließelement-Tags sein optional , wird aber nicht sagen, ob es vorzuziehen ist, sie zu schließen, oder besser, sie nicht enthalten.

Auf der anderen Seite, ein zufälliger Artikel auf DevGuru sagt :

Der End-Tag ist optional. Es wird jedoch empfohlen, dass sie aufgenommen werden.

Der Grund, warum ich frage ist, weil Sie nur weiß es ist optional aus Kompatibilitätsgründen; und sie hätte sie ( obligatorisch | verboten ) gemacht. wenn sie könnte

Anders formuliert: Was HTML hat 1, 2, 3 tun in Bezug auf diese, jetzt optional, End-Tags. Was bedeutet HTML 5 do? Und was sollte I tun?

Hinweis

Einige Elemente in HTML sind verboten von End-Tags haben. Sie können damit nicht einverstanden ist, aber das ist die Spezifikation, und es ist nicht zur Debatte. Ich bitte über optional End-Tags, und was die Absicht war.

Fußnoten

¹ HTML 4.01

Lösung

Die optionalen, sind alle diejenigen, die semantisch klar sein sollte, wo sie enden, ohne dass die End-Tag zu benötigen. Z.B. jeder <li> impliziert eine </li>, wenn es nicht ein Recht, bevor es ist.

Die verbotenen Endtags alle würden sofort durch ihren End-Tag gefolgt werden, so wäre es irgendwie überflüssig zu haben <img src="blah" alt="blah"></img> jedes Mal eingeben.

ich immer fast die optionalen Tags verwenden (es sei denn ich einen sehr guten Grund, nicht zu haben), weil es besser lesbar und aktualisierbar Code verleiht.

Andere Tipps

Es gibt Fälle, in denen explizite Tags Hilfe, aber manchmal ist es unnötig pedantism.

Beachten Sie, dass die HTML-Spezifikation klar spezifiziert, wenn es wegzulassen Tags gültig ist, so ist es nicht immer ein Fehler.

Zum Beispiel Sie nie </body></html> benötigen. Niemand hat je erinnert <tbody> explizit setzen (zu dem Punkt, dass XHTML Ausnahmen für sie gemacht).

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

Verschachtelte Listen sind eigentlich besser dran ohne </li>, denn dann ist es schwieriger errorneous ul > ul Baum zu erstellen.

Gültig:

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

Ungültig:

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

Und bedenken Sie, dass End-Tags impliziert werden, ob Sie versuchen, alle Elemente zu schließen oder nicht. End-Tags setzt nicht automatisch robuste Parsen:

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

wird analysieren, wie:

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

Es kann nur helfen, wenn Sie validieren Dokumente.

Ich füge hier einige Links, die Sie mit der Geschichte von HTML zu helfen, für Sie die verschiedenen Widersprüche zu verstehen. Dies ist nicht die Antwort auf Ihre Frage, aber Sie wissen mehr, nachdem diese verschiedenen Digests zu lesen.

Einige Auszüge aus Dive Into HTML5 :

[D] ie Tatsache, dass „gebrochen“ HTML-Markup noch in Web-Browsern geführt Autoren gearbeitet, um gebrochen HTML-Seiten zu erstellen. Viele gebrochene Seiten. Nach einigen Schätzungen über 99% der HTML-Seiten im Web heute mindestens einen Fehler in ihnen. Aber weil diese Fehler nicht Ursache Browser sichtbar Fehlermeldungen angezeigt werden, niemand jemals Behebungen sie.

Das W3C sah dies als ein grundlegendes Problem mit der Web, und sie machten sie zu korrigieren. XML, im Jahr 1997 veröffentlicht wurde, brach aus der Tradition der verzeiht Kunden und den Auftrag, dass alle Programme, die XML verbraucht, so genannte „Wohlgeformtheits-“ Fehler als fatal behandeln müssen. Dieses Konzept des auf dem ersten Fehler versagt wurde bekannt als „drakonisch Fehlerbehandlung“, nach dem griechischen Führer Draco , die die Todesstrafe für relativ kleinere Vergehen seiner Gesetze eingeleitet. Wenn der W3C HTML als XML-Vokabular neu formuliert, beauftragt sie, dass alle Dokumente mit dem neuen application/xhtml+xml MIME-Typ bedient unterliegen würden drakonische Fehlerbehandlung. Wenn es auch nur ein einziger Wohlgeformtheits- Fehler in der XHTML-Seite ist [...] Web-Browser würde keine andere Wahl, als Stop-Verarbeitung und Anzeige eine Fehlermeldung an die Endbenutzer.

Diese Idee war nicht überall beliebt. Mit einem geschätzten Fehlerquote von 99% auf bestehende Seiten, die allgegenwärtigen Möglichkeit von Fehlern an die Endbenutzer angezeigt wird, und der Mangel an neuen Funktionen in XHTML 1.0 und 1.1, um die Kosten zu rechtfertigen, Web-Autoren grundsätzlich ignoriert application/xhtml+xml. Aber das bedeutet nicht, dass sie XHTML gänzlich ignoriert. Oh, ganz sicher nicht. Anhang C der XHTML 1.0 Spezifikation gab die Web-Autoren der Welt eine Lücke: „Verwenden Sie etwas, das aussieht wie eine Art XHTML-Syntax, halten aber mit dem text/html MIME-Typ zu dienen.“ Und das ist genau das, was Tausende von Web-Entwickler haben: sie „Upgrade“ zu XHTML-Syntax aber hielt es mit einem text / html MIME-Typ dienen.

Auch heute Millionen von Web-Seiten behaupten, XHTML zu sein. Sie beginnen mit dem XHTML-Doctype auf der ersten Zeile, Tag-Namen verwendet Klein, verwenden Sie Anführungszeichen um Attributwerte, und einen Schrägstrich nach leeren Elementen wie <br /> und <hr /> hinzufügen. Aber nur ein winziger Bruchteil dieser Seiten wird mit dem application/xhtml+xml MIME-Typ bedient, die XML drakonische Fehlerbehandlung auslösen würde. Jede Seite, servierte mit einem MIME-Typ text/html - unabhängig von Doctype, Syntax oder Stil Codierung - wird eine „verzeiht“ HTML-Parser analysiert wird unter Verwendung stumm all Markup-Fehler zu ignorieren, und nie Endanwendern Alarmierung (oder jemand anderes), auch wenn die Seiten werden technisch gebrochen.

XHTML 1.0 diese Lücke enthielt, aber XHTML 1.1 geschlossen es, und die nie fertig gestellt XHTML 2.0 setzte die Tradition von erfordern drakonische Fehlerbehandlung. Und deshalb gibt es Milliarden von Seiten, die behaupten, XHTML zu 1,0, und nur eine Handvoll, dass Anspruch auf XHTML 1.1 (oder XHTML 2.0). So verwenden Sie wirklich XHTML? Prüfen Sie die MIME-Typ. (Eigentlich, wenn Sie nicht wissen, was MIME-Typ Sie verwenden, kann ich ziemlich garantieren, dassSie verwenden text/html noch.) Wenn Sie Ihre Seiten mit dem MIME-Typ application/xhtml+xml sind dient, Ihre so genannte „XHTML“ ist XML nur dem Namen nach.

[T] er Menschen, die vorgeschlagen hatte sich entwickelnden HTML und HTML-Formulare mit zwei Entscheidungen konfrontiert wurden: aufgeben oder ihre Arbeit außerhalb des W3C fortzusetzen. Sie wählten die letztere registriert die whatwg.org Domäne, und im Juni 2004 die WAS-Arbeitsgruppe wurde geboren .

[T] er, was Arbeitsgruppe leise wurde auf ein paar anderen Dinge arbeiten, auch. Einer von ihnen war eine Spezifikation, die ursprünglich genannt Web Forms 2.0 , die neue Arten von Kontrollen zu HTML-Formularen hinzugefügt. (Sie werden mehr über Web-Formulare in eine Form des Wahnsinns lernen.) Ein weiterer Entwurf einer Spezifikation war „genannt Web Applications 1.0 „, die wie wichtige neue Funktionen enthalten Direktzeichnungsmodus Leinwand und native Unterstützung für Audio und Video ohne Plugins .

Im Oktober 2009 das W3C die XHTML 2 Arbeitsgruppe herunterzufahren und diese Erklärung abgegeben ihre Entscheidung erklären:


Wenn W3C die HTML und XHTML 2 Arbeitsgruppen März 2007 angekündigt, haben wir darauf hingewiesen, dass wir den Markt für XHTML 2. W3C zur Überwachung erkennt die Bedeutung eines klaren Signal an die Gemeinschaft über die Zukunft von HTML würden.

Während wir den Wert der XHTML 2 Arbeitsgruppe Beiträge im Laufe der Jahre, nach einer Diskussion mit den Teilnehmern zu erkennen, hat die W3C-Management beschlossen, der Arbeitsgruppe Charta zu ermöglichen, am Ende des Jahres 2009 auslaufen und nicht, sie zu erneuern.


Diejenigen, die sind diejenigen gewinnen, dass Schiff.

Der Grund, warum ich frage ist, weil Sie nur wissen, dass es aus Gründen der Kompatibilität optional ist; und sie würden sie gemacht haben (verpflichtend | verboten). wenn sie könnte

Das ist eine interessante Folgerung. Meine Lektüre davon ist, dass fast jedes Mal, wenn ein Tag zuverlässig abgeleitet werden könnte, der Tag ist optional. Der Entwurf schlägt vor, dass die Absicht, es schnell und einfach zu schreiben machen war.

Was HTML hat 1, 2, 3 tun in Bezug auf diese, jetzt optional, End-Tags.

Die DTD für HTML-2 sind in dem eingebetteten RFC , die zusammen mit die ursprüngliche HTMLDTD , hat optional Start- und End-Tags alle über den Ort .

HTML 3 wurde aufgegeben (dank der Browser-Kriege) und ersetzt mit HTML 3.2 (die den dann aktuellen Stand der Bahn zu beschreiben entworfen wurde).

Was bedeutet HTML 5 do?

HTML 5 wurde darauf ausgerichtet, "Schaffung der cowpaths" von Anfang an.

Und was soll ich tun?

Ah, jetzt, ist subjektiv und argumentative:)

Einige Leute denken, dass die expliziten Tags sind besser für die Lesbarkeit und Wartbarkeit durch die Augen vor den Lesern zu sein.

Einige Leute denken, dass gefolgert Tags sind besser für die Lesbarkeit und Wartbarkeit durch den Editor nicht unübersichtlich.

Was bedeutet HTML 5 do?

Die Antwort auf diese Frage ist in dem W3C Working Draft: http://www.w3.org/TR/html5/syntax .html # Syntax-tag-Auslassung

Und was soll ich tun?

Es ist eine Frage des Stils. Ich versuche, nie auslassen End-Tags, weil es mir streng zu sein hilft und nicht auslassen Tags, die notwendig sind.

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

Wenn es einen Zweck dient (auch eine scheinbar triviale Aufgabe, wie Sie Ihre IDE beschwichtigen oder Ihre Augen Beschwichtigung), lassen Sie es in.

Es ist selten in einer gut definierten Spezifikation optionale Elemente zu sehen, die nicht Verhalten beeinflussen. Mit Ausnahme von „Kommentare“, natürlich. Aber die HTML-Spezifikation ist weniger ein Design-Spezifikation, und eines Dokuments über den Stand der aktuellen großen Implementierungen. Also, wenn ein Element in HTML optional ist und es scheint keinen Zweck zu dienen, wir, dass optionale Natur erraten können lediglich Dokumentation einer Marotte in bestimmtem Browser ist.

Mit Blick auf die HTML-5-Spezifikation RFC Abschnitt oben verbunden, sehen Sie, dass die optionalen Tags seltsam auf das Vorhandensein von Kommentaren verbunden sind! Das sollte Ihnen sagen, dass die Autoren nicht Design Hüte tragen. Sie spielen stattdessen das Spiel von „Dokument der Macken“ in großen Implementierungen. Also haben wir die Spezifikation zu ernst in dieser Hinsicht nicht nehmen.

Die Lösung ist also: Tun Sie es nicht schwitzen. Fahren Sie mit etwas, das tatsächlich ankommt. :)

Ich denke, die beste Antwort zu schließen Tags für Lesbarkeit oder Fehlererkennung enthalten ist. wenn Sie viele generierten HTML (zum Beispiel Datentabellen) haben jedoch konnte man durch Weglassen optionale Tags signifikante Bandbreite sparen.

Meine Empfehlung ist, dass Sie die meisten optional schließen Tags weglassen, und alle optionalen Attribute, die Sie mit wegkommen kann. Viele IDEs wird sich beschweren, so dass Sie nicht in der Lage sein kann, mit Weglassen einige davon wegzukommen, aber es ist in der Regel besser für kleinere Dateigröße und weniger Unordnung. Wenn Sie Codegeneratoren auf jeden Fall auslassen End-Tags gibt, weil Sie können einige gute Größenreduzierung von ihm erhalten. Normalerweise ist es nicht wirklich wichtig, eine oder andere Weise.

Aber wenn es nicht Sache wirkt dann auf sich. Bei einigen neueren Arbeiten von mir konnte ich die Größe meiner gerenderte HTML von 1,5 MB auf 800 KB reduzieren, indem die meisten der erzeugten Ende und redundanten Wert Attribute für den offenen Tag, wo der Text des Elements war die gleiche wie die Beseitigung Wert. Ich habe über 200 Tags. Ich könnte diese etwas andere Art und Weise vollständig umzusetzen, aber das wäre mehr Arbeit ($$$) sein, so dass diese mir erlaubt auf einfache Weise die Seite zu machen mehr ansprechbar.

Nur aus Neugier fand ich, dass, wenn ich Anführungszeichen um Attribute entfernt, die sie nicht brauchen, habe ich 20 KB retten könnte, aber meine IDE (Visual Studio) mag es nicht. Ich war auch, dass die wirklich lange ID finden überrascht, dass ASP.NET-Konto für 20% meiner Datei erzeugt.

Die Idee, dass wir jemals eine falsche Entscheidung alle relevanten Anteil von HTML streng gültig bekommen konnte an erster Stelle, so tun, was für Sie und Ihre Kunden am besten funktioniert. Die meisten Tools, dass ich jemals sagen, sie erzeugen xhtml gesehen oder benutzt, aber sie wirklich 100% nicht funktioniert, und es gibt keinen Nutzen für die strikte Einhaltung trotzdem.

Ich persönlich bin ein Fan von XHTML und, wie ghoppe: „Ich versuche Tags nie auslassen Ende, weil es hilft mir streng und nicht auslassen Tags zu sein, die notwendig sind.“

und

Wenn Sie sich bewusst HTML 4.n verwenden, kann man nicht behaupten, dass sie einschließlich macht es einfacher, das Dokument zu konsumieren, wie der Begriff der Wohlgeformtheits- als Geltungsgegen ein XML-Konzept ist, und Sie verlieren, dass Nutzen, wenn Sie verbieten bestimmte schließen Tags. So ist die einzige Frage wird Gültigkeit ... und wenn es ohne sie noch gültig ... Sie könnte genauso gut sparen die Bandbreite, nicht wahr?

Mit End-Tags macht mit Fragmenten zu tun einfacher, weil ihr Verhalten auf die Geschwisterelemente abhängt. Allein aus diesem Grund sollte zwingend genug sein. Hat jemand Deal mit monolithischen HTML-Dokumente mehr?

In einigen geschweifte Klammer Sprachen wie C #, können Sie die geschweiften Klammern um eine if-Anweisung wenn es nur zwei Zeilen lang auslassen. zum Beispiel ...

if ([Bedingung])
[Code]

Sie können dies aber nicht tun ...

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

In der dritten Zeile wird nicht ein Teil der if-Anweisung sein. es tut weh, Lesbarkeit und Bugs leicht eingeführt werden kann und schwer zu finden sein.

aus den gleichen Gründen, schließe ich alle Tags. Tags wie der img-Tag muß noch geschlossen werden, nur nicht mit einem separaten schließenden Tag.

Wenn Sie einen HTML-Parser schreiben würden, wäre es einfacher zu parsen HTML, das optional Schließen-Tags enthalten, oder HTML das nicht? Ich denke, die optional Endtags anwesend wäre es einfacher machen, als würde ich nicht schließen, wo der Schluss-Tag sein sollte.

Aus diesem Grund habe ich immer auch die optionalen schließenden Tags - auf der Theorie, dass meine Seite schneller machen könnte, wie ich die Schaffung weniger Arbeit für die HTML-Parser des Browsers

tun, was Sie fühlen, macht den Code lesbar und wartbar.

Persönlich würde ich immer zu schließen <td> und <tr> geneigt sein, aber ich würde nie mit <li> stören.

Für verboten Schließen Typen verwenden Syntax wie: <img /> Mit dem /> den Tag zu schließen, die in XML

akzeptiert

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow