Was sind alle gültigen selbstschließenden Elemente in XHTML (wie von den wichtigsten Browsern implementiert)?


188

Was sind alle gültigen selbstschließenden Elemente (z. B. <br/>) in XHTML (wie von den wichtigsten Browsern implementiert)?

Ich weiß, dass XHTML technisch zulässt, dass jedes Element selbst geschlossen wird, aber ich suche nach einer Liste der Elemente, die von allen gängigen Browsern unterstützt werden. Unter http://dusan.fora.si/blog/self-closing-tags finden Sie Beispiele für einige Probleme, die durch selbstschließende Elemente wie <div /> verursacht werden.


7
Ist dies nicht die Standardeinstellung von XHTML? Ich dachte, einer der Vorteile von XHTML ist, dass Sie einen XML-Generator verwenden können, um HTML zu generieren. Warum sollte ein XML-Generator wissen, welche Tags sich selbst schließen dürfen? Zu verrückt.
Elijah

6
Der Grund, warum die "lahme", "falsche" Antwort akzeptiert wurde, ist, dass sie die Frage beantwortete, die Kamens offensichtlich stellte. Er wollte wissen, welche Elemente sich selbst schließen können, wenn XHTML als Text / HTML bereitgestellt wird, ohne Renderingprobleme in Browsern zu verursachen. Viele Seiten sind in XHTML geschrieben und dienen als Text / HTML, obwohl dies technisch nicht korrekt ist. Die Frage könnte mit dieser Klarstellung verbessert werden, aber die Beantwortung einer anderen Frage (was passiert, wenn Sie als application / xml dienen oder ob einzelne Tags in text / html ein schließendes / haben sollten) ist in diesem Fall nicht hilfreich.
Nick Lockwood

Antworten:


180

Jeder Browser, der XHTML unterstützt (Firefox, Opera, Safari, IE9 ), unterstützt die selbstschließende Syntax für jedes Element .

<div/>, <script/>, <br></br>Sollten alle gut funktionieren. Wenn dies nicht der Fall ist , haben Sie HTML mit unangemessen hinzugefügtem XHTML DOCTYPE.

DOCTYPE ändert nichts an der Interpretation des Dokuments. Nur der MIME-Typ funktioniert .

W3C-Entscheidung zum Ignorieren von DOCTYPE :

Die HTML-Arbeitsgruppe hat dieses Problem erörtert: Alte Browser (nur HTML) sollten XHTML 1.0-Dokumente akzeptieren, indem sie den Richtlinien folgen und sie als Text / HTML bereitstellen. Daher sollten Dokumente, die als Text / HTML bereitgestellt werden, als HTML und nicht als XHTML behandelt werden.

Dies ist eine sehr häufige Gefahr, da W3C Validator diese Regel weitgehend ignoriert, Browser sie jedoch religiös befolgen. Lesen Sie das Grundlegendes zu HTML, XML und XHTML im WebKit-Blog:

Tatsächlich wird die überwiegende Mehrheit der angeblich XHTML-Dokumente im Internet als bereitgestellt text/html. Dies bedeutet, dass es sich überhaupt nicht um XHTML handelt, sondern um ungültiges HTML, das bei der Fehlerbehandlung von HTML-Parsern zurechtkommt. Alle diese "Valid XHTML 1.0!" Links im Web sagen wirklich "Ungültiges HTML 4.01!".


Um zu testen, ob Sie mit XHTMLs DOCTYPE über echtes XHTML oder ungültiges HTML verfügen, fügen Sie Folgendes in Ihr Dokument ein:

<span style="color:green"><span style="color:red"/> 
 If it's red, it's HTML. Green is XHTML.
</span>

Es validiert und in echtem XHTML funktioniert es perfekt (siehe: 1 vs 2 ). Wenn Sie Ihren Augen nicht trauen können (oder nicht wissen, wie MIME-Typen festgelegt werden sollen), öffnen Sie Ihre Seite über den XHTML-Proxy .

Eine andere Möglichkeit zur Überprüfung ist das Anzeigen der Quelle in Firefox. Es werden rote Schrägstriche hervorgehoben, wenn sie ungültig sind.

In HTML5 / XHTML5 hat sich dies nicht geändert, und die Unterscheidung ist noch deutlicher, da Sie nicht einmal zusätzliche haben DOCTYPE. Content-Typeist der König.


Für den Datensatz ermöglicht die XHTML-Spezifikation, dass sich jedes Element selbst schließt, indem XHTML zu einer XML-Anwendung gemacht wird : [Hervorhebung von mir]

Tags für leere Elemente können für jedes Element verwendet werden, das keinen Inhalt hat , unabhängig davon, ob es mit dem Schlüsselwort EMPTY deklariert wurde oder nicht.

Es wird auch explizit in der XHTML-Spezifikation gezeigt :

Leere Elemente müssen entweder ein End-Tag haben oder das Start-Tag muss mit enden />. Zum Beispiel <br/>oder<hr></hr>


7
Afaik nicht korrekt, da die Verwendung von selbstschließenden Versionen von <script>oder <div>zu einer unterschiedlichen Darstellung / Interpretation führt.
ZeissS

13
@ZeissS nur in text/html. In echtem XHTML, gesendet, da application/xhtml+xmles gut funktioniert. Bitte lesen Sie vor dem Downvoting den Artikel, auf den ich verlinkt habe (oder Anhang C der XHTML-Spezifikation).
Kornel

3
@pornel können Sie garantieren, dass selbstschließende <script /> -Tags in älteren Browsern funktionieren? Das glaube ich nicht. Sie klingen maßgeblich und die meisten Ihrer Informationen sind korrekt, aber die Erfahrung zeigt, dass selbstschließende Skript-Tags problematisch sind und es am besten ist, sie ganz zu vermeiden, anstatt sich selbst Kopfschmerzen zu bereiten.
Metagrapher

6
@Metagrapher Wenn ältere Browser kein echtes XHTML unterstützen oder Sie den MIME-Typ nicht festlegen können , funktioniert dies nicht. In XHTML-unterstützenden Browsern ( derzeit alle wichtigen) mit application/xhtml+xmlMIME-Typ kann ich jedoch garantieren, dass dies <script/>funktioniert. Mit dem MIME-Typ. Nur.
Kornel

4
@capdragon: Ältere Browser unterstützen XHTML nicht (dient als 'application / xhtml + xml'). Wenn Sie ihnen ein XHTML-Dokument als 'text / html' senden, wird das XHTML als Tag-Suppe gerendert (dh der Browser analysiert es als HTML und berücksichtigt selbstschließende Tag-Fehler, von denen es ordnungsgemäß wiederhergestellt wird). Ihre Optionen sind: 1. Schreiben Sie HTML 4 (nicht gerade eine Option, wenn Sie ASP.NET verwenden, das XHTML rendert), 2. Stellen Sie Ihr XHTML als 'application / xhtml + xml' bereit (erfordert IE9 +, und dieser MIME-Typ bricht Skripte in allen Browsern sowieso, also definitiv keine Option), 3. schreibe HTML 5, was im Grunde genommen Tag Suppe zum Standard macht :)
Triynko

41

Ein Element, mit dem Sie bei diesem Thema sehr vorsichtig sein sollten, ist das <scriptElement>. Wenn Sie eine externe Quelldatei haben, wird dies Probleme verursachen, wenn Sie diese selbst schließen. Versuch es:

<!-- this will not consistently work in all browsers! -->
<script type="text/javascript" src="external.js" />

Dies funktioniert in Firefox, funktioniert aber zumindest in IE6. Ich weiß, weil ich darauf gestoßen bin, als ich jedes Element, das ich sah, eifrig selbst schloss ;-)


Betrifft alle Versionen von MSIE: webbugtrack.blogspot.com/2007/08/…
scunliffe

4
<script> schließt sich in Firefox 3 nicht selbst.
hsivonen

Nun, es hat in Firefox funktioniert, als ich darauf gestoßen bin. Scheint, als würde es in keinem Browser mehr funktionieren. Könnte vielleicht auch nur im Mackenmodus funktionieren?
Erik van Brakel

1
@erickson es funktioniert gut in Firefox, wenn Sie Ihren MIME-Typ richtig machen.
Kornel

WebKit tut dies aus Kompatibilitätsgründen weiterhin.
Yuhong Bao

35

Die selbstschließende Syntax funktioniert für alle Elemente in application / xhtml + xml. Es wird für kein Element in Text / HTML unterstützt, aber die Elemente, die in HTML4 "leer" oder in HTML5 "ungültig" sind, nehmen ohnehin kein End-Tag an. Wenn Sie also einen Schrägstrich auf diese setzen, sieht es so aus Die selbstschließende Syntax wurde unterstützt.


33

Von der Referenzseite der W3-Schulen :

<area />
<base />
<basefont />
<br />
<hr />
<input />
<img />
<link />
<meta />

7
w3schools.com/tags/default.asp Ich sehe 12 Tags, die enden mit />:"area", "base", "basefont", "br", "col", "frame", "hr", "img", "input", "link", "meta", "param"
mpen

94
Bitte beachten Sie, dass W3schools nicht mit W3C verbunden ist und sogar nicht auf Korrekturen reagiert, die von W3C-Mitgliedern gesendet wurden.
Kornel

2
Wie so oft ist w3schools fast richtig. Ein genauer Weg, um die leeren Elemente zu finden, ist zu laufen grep EMPTY xhtml1-strict.dtd | sortodergrep EMPTY xhtml1-transitional.dtd | sort
cayhorstmann

1
IMHO, Leute schlagen W3Schools viel zu hart. Es hat sich als großartige Ressource erwiesen, wenn Sie mit einem Thema beginnen, von dem Sie nichts wissen.
Priidu Neemre

28

Die bessere Frage wäre: Welche Tags können auch im HTML-Modus selbst geschlossen werden, ohne den Code zu beeinflussen? Antwort: Nur diejenigen, die leeren Inhalt haben (sind ungültig). Gemäß den HTML-Spezifikationen sind die folgenden Elemente ungültig:

area, base, br, col, embed, hr, img, input, keygen, link, menuitem, meta, param, source, track, wbr

Ältere Version der Spezifikation ebenfalls aufgeführt command. Außerdem sind nach verschiedenen Quellen die folgenden veralteten oder nicht standardmäßigen Tags ungültig:

basefont, bgsound, frame, isindex


10

Hoffe das hilft jemandem:

<base />
<basefont />
<frame />
<link />
<meta />

<area />
<br />
<col />
<hr />
<img />
<input />
<param />

5

Was ist mit <meta>und <link>? Warum sind sie nicht auf dieser Liste?

Schnelle Faustregel: Schließen Sie kein Element, das Inhalt enthalten soll, selbst, da dies früher oder später definitiv zu Browserproblemen führen kann.

Diejenigen, die sich von Natur aus selbst schließen, wie <br>und <img>, sollten offensichtlich sein. Diejenigen, die es nicht sind ... schließen Sie sie einfach nicht selbst!


4

Als ich das letzte Mal nachgesehen habe, waren die folgenden leeren / nichtigen Elemente in HTML5 aufgeführt.

Gültig für Autoren: Bereich, Basis, br, col, Befehl, Einbettung, Ereignisquelle, hr, img, Eingabe, Link, Meta, Parameter, Quelle

Ungültig für Autoren: basefont, bgsound, frame, spacer, wbr

Neben den wenigen, die in HTML5 neu sind, sollte Ihnen dies eine Vorstellung davon geben, welche möglicherweise unterstützt werden, wenn XHTML als Text / HTML bereitgestellt wird. (Testen Sie sie einfach, indem Sie das erzeugte DOM untersuchen.)

Für XHTML, das als Anwendung / xhtml + xml dient (wodurch es XML wird), gelten XML-Regeln und jedes Element kann leer sein (obwohl die XHTML-DTD dies nicht ausdrücken kann).


4

Sie sollten sich die xHTML-DTDs ansehen , sie sind alle aufgelistet. Hier ist eine kurze Übersicht aller wichtigen:

<br />
<hr />
<img />
<input />

1
Markup behoben und bereinigt. Vorsichtig mit Links auf diesen Seiten, sie werden langsam geladen.
E-Satis

4

Sie werden in HTML 5 als "void" -Elemente bezeichnet. Sie sind in der offiziellen W3-Spezifikation aufgeführt .

Ein void-Element ist ein Element, dessen Inhaltsmodell es unter keinen Umständen zulässt, dass Inhalte vorhanden sind.

Ab April 2013 sind dies:

area, base, br, col, befehl, einbetten, hr, img, eingabe, keygen, link, meta, param, quelle, track, wbr

Ab Dezember 2018 (HTML 5.2) sind dies:

area, base, br, col, einbetten, hr, img, eingabe, link, meta, param, quelle, spur, wbr


2

Ein weiteres selbstschließendes Tag-Problem für IE ist das Titelelement. Wenn IE (gerade in IE7 ausprobiert) dies sieht, wird dem Benutzer eine leere Seite angezeigt. Wie auch immer Sie "Quelle anzeigen" und alles ist da.

<title/>

Ich habe das ursprünglich gesehen, als mein XSLT das selbstschließende Tag generiert hat.


Chrom mag auch keine <title/>Tags.
uınbɐɥs

2

Ich werde nicht versuchen, dies zu überarbeiten, zumal die meisten Seiten, die ich schreibe, entweder generiert werden oder das Tag Inhalt enthält. Die einzigen zwei, die mir jemals Probleme gemacht haben, sie selbst zu schließen, sind:

<title/>

Aus diesem <head></head>Grund habe ich einfach darauf zurückgegriffen, ihm immer ein separates schließendes Tag zu geben, da es Ihren Code ohnehin nicht wirklich unordentlicher macht , wenn er dort oben im Code ist.

<script/>

Dies ist der große, mit dem ich kürzlich Probleme hatte. Ich hatte jahrelang immer selbstschließende <script/>Tags verwendet, wenn das Skript von einer externen Quelle stammt. Aber ich habe vor kurzem angefangen, JavaScript-Fehlermeldungen über ein Nullformular zu erhalten. Nach mehreren Tagen der Recherche stellte ich fest, dass das Problem (angeblich) darin bestand, dass der Browser nie zum <form>Tag kam, weil er nicht wusste, dass dies das Ende des <script/>Tags war. Als ich es in separate <script></script>Tags schaffte, funktionierte alles. Warum auf verschiedenen Seiten, die ich mit demselben Browser erstellt habe, anders, weiß ich nicht, aber es war eine große Erleichterung, die Lösung zu finden!


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.