Verwendung von <br>

[Tanja]

Hi,

vor längerer Zeit habe ich auf Anregung alle <br> in <br /> umgewandelt. Jetzt meldet der HTML-Checker:

Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.

Was ist heute die Empfehlung?

[Auge]

Hallo

vor längerer Zeit habe ich auf Anregung alle <br> in <br /> umgewandelt.

Jetzt meldet der HTML-Checker:

Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.

Was ist heute die Empfehlung?

Kommt darauf an.

Prinzipiell handelt es sich in beiden Schreibweisen um das gleiche Element. Die Schreibweise <br /> ist dann verpflichtend, wenn dein HTML-Dokument, aus welchen Gründen auch immer, als XHTML und damit als XML ausgeliefert werden muss. Das wäre zum Beispiel bei einer maschinellen Verarbeitung deiner HTML-Dokumente als XML der Fall. Bei <br />handelt es sich ja, wie zum Beispiel auch <img /> um ein inhaltsleeres Element, also eines, das keinen Inhalt umschließt, weshalb es mit dem Slash als „geschlossen“ markiert wird.

Schreibst du kein XHTML, sondern „nur“ HTML, ist <br> die richtige Schreibweise. Aber auch mit <br /> geht dein HTML-Dokument (ohne „X“) nicht kaputt, die Browser können damit umgehen.

Du solltest die Sache aber auch aus einem anderen Blickwinkel betrachten, nämlich, wann <br> oder auch <br /> überhaupt angewendet werden soll. Das ist nur innerhalb eines Textabschnitts (zum Beipiel innerhalb eines <p>…</p>) sinnvoll, wenn ein Teil des Inhalts in einer neuen Zeile weitergeführt werden soll. Zur Gliederung in mehrere Absätze benutzt man stattdessen mehrere <p></p> (oder welches Element auch immer konkret benutzt werden sollte). Ich schreibe das nur, weil auch heute von einigen immer noch Zeilenumbrüche (welches <br> auch immer) zur Schaffung von Abstand zwischen Abschnitten benutzt werden, obwohl dafür die Formatierung mit CSS zu benutzen ist.

Tschö, Auge

[Rolf B]

Hallo Tanja,

die Antwort lautet, wie so oft: kommt drauf an.

<br> ist ein inhaltsleeres Element, das eigentlich nur das Start-Tag benötigt. Davon gibt es einige.

Inhaltsleere Elemente verursachen Probleme, wenn man das HTML Dokument von einem XML-Parser verarbeiten lassen möchte. In XML muss jedes Element aus Start- und Ende-Tag bestehen, oder die Kurzfassung <bla /> verwenden.

Zu HTML 4 Zeiten unterschied man zwei HTML Dialekte: HTML und XHTML. Mit HTML 5 macht man das nicht mehr, allerdings gibt es die XML-Form nach wie vor, man nennt sie aber einfach "HTML in XML-Schreibweise". Oder anders gesagt: man formuliert das HTML so, dass es für einen XML-Parser verständlich ist. Dazu gehört unter anderem die <bla />-Schreibweise für inhaltsleere Elemente und der Grundsatz, alle Attributwerte in Anführungszeichen zu setzen.

Die Meldung des HTML-Checkers ist deshalb mit einem Löffel Salz zu genießen.

Trailing slash on void elements has no effect

Für einen HTML-Parser ist das richtig. Aber wenn ein XML Parser verwendet werden soll, dann gibt es einen Effekt. Und zwar der, dass das Parser überhaupt erst verwendbar ist.

and interacts badly with unquoted attribute values.

Diesen Teil finde ich sehr merkwürdig formuliert. In HTML sind Attributwerte ohne Anführungszeichen zulässig. In XML hingegen nicht. D.h. wenn man die Absicht hat, sein HTML Dokument auch für XML Parser verständlich zu machen, sind „unquoted attribute values“ schlichtweg unzulässig. Eine Schreibweise wie <br id=foo /> wäre kompletter Unsinn. Entweder will man XML-Verarbeitung, dann muss foo in Anführungszeichen, oder man will nur HTML, dann kann man das / weglassen.

Vielleicht fragst Du jetzt noch, wann man denn überhaupt einen XML Parser für ein HTML Dokument verwenden sollte. Antwort: solange Du das HTML von Hand oder mit einem HTML-Tool erzeugst und in einem Browser anzeigen lassen willst, gar nicht. Aber wenn Du XML-basierende Daten oder Arbeitsabläufe hast, dann kann die Verarbeitbarkeit als XML Vorteile haben.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Trailing slash […] interacts badly with unquoted attribute values.

Diesen Teil finde ich sehr merkwürdig formuliert.

Ich erinnere mich an die Anfangszeit der CSSBattle, als SVG noch erlaubt war. Leere SVG-Elemente müssen auch in HTML mit /> geschlossen werden (außer das letzte, das nimmt der Parser auch ohne Slash).

Bei Attributwerten ohne Anführungszeichen muss man ein Leerzeichen vor den Slash setzen:

Geht nicht: <circle r=50 cx=50 cy=50 fill=darkred/>, weil / als Bestandteil des Attributwerts angesehen wird.

Geht: <circle r=50 cx=50 cy=50 fill=darkred />

Geht auch: <circle r=50 cx=50 cy=50 fill="darkred"/> (Ist aber ein Zeichen länger.)

☞ Spielwiese

Vielleicht meinten sie das mit “interacts badly”.

Kwakoni Yiquan

[Der Martin]

Hallo,

[...] Dazu gehört unter anderem die <bla />-Schreibweise für inhaltsleere Elemente und der Grundsatz, alle Attributwerte in Anführungszeichen zu setzen.

... und auch, alle Element- und Attributnamen konsequent klein zu schreiben. Großschreibung oder CamelCase ist nicht XHTML-konform, weil XML per definitionem case-sensitive ist.

and interacts badly with unquoted attribute values.

Diesen Teil finde ich sehr merkwürdig formuliert.

Aber Gunnars Erklärung dazu überzeugt mich - auch wenn sie gegenstandslos ist, solange man sich konsequent für einen Dialekt entscheidet.

Generell sage ich aber auch: Attributwerte ohne Anführungszeichen zu schreiben, ist bad practice, selbst wenn es erlaubt ist.

In HTML sind Attributwerte ohne Anführungszeichen zulässig.

... solange sie nur Buchstaben und Ziffern enthalten.

Einen schönen Tag noch
 Martin

[Gunnar Bittersmann]

@@Der Martin

... und auch, alle Element- und Attributnamen konsequent klein zu schreiben.

HTML-Element- und -Attributnamen.

Bei SVG-in-HTML mag auch <svg viewbox="…"> erlaubt sein, bei Standalone-SVG ist es das nicht, es muss CamelCase viewBox heißen, wie du sagst:

weil XML per definitionem case-sensitive ist.

Da würde ich als Empfehlung rausgeben, immer die CamelCase-Schreibweise zu verwenden, auch bei SVG-in-HTML.

---

In HTML sind Attributwerte ohne Anführungszeichen zulässig.

... solange sie nur Buchstaben und Ziffern enthalten.

… oder andere erlaubte Zeichen wie ., +, -, %, …

Kwakoni Yiquan

[Rolf B]

Hallo Martin,

... solange sie nur Buchstaben und Ziffern enthalten.

Ich wollte das nicht ausdetaillieren.

Die HTML Spec sagt:

(Unquoted attribute values), in addition to the requirements given above for attribute values, must not contain any literal ASCII whitespace, any U+0022 QUOTATION MARK characters ("), U+0027 APOSTROPHE characters ('), U+003D EQUALS SIGN characters (=), U+003C LESS-THAN SIGN characters (<), U+003E GREATER-THAN SIGN characters (>), or U+0060 GRAVE ACCENT characters (`), and must not be the empty string.

Die "requirements above" sind, soweit ich das gefunden habe, die Vorschrift, dass es kein mehrdeutiges & geben darf. Das wäre sowas wie &martin; - das sieht aus wie eine benannte Zeichenreferenz, aber es ist keine, weil für diesen Namen nichts registriert ist.

D.h. folgendes ist gültig, wenn auch voller Tretminen:

#\25AE  b {   /* 2 Spaces! */
  color: red;
}
#💩 { color: brown; }

<div id=&marker;>Hallo <b>Martin</b></div>
<div id=💩>Hello Mr. Hankey, that's a nice muffin!</div>

Rolf

[Gunnar Bittersmann]

@@Rolf B

D.h. folgendes ist gültig, wenn auch voller Tretminen:

Die explosivste ist das ' in

<div id=💩>Hello Mr. Hankey, that's a nice muffin!</div>

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

Forentypographie ist bekanntlich eine Sucht, die mich nicht gepackt hat

Rolf

[Matthias Scharwies]

Servus!

Hi,

vor längerer Zeit habe ich auf Anregung alle <br> in <br /> umgewandelt.

Jetzt me[cker]t der HTML-Checker:

Was ist heute die Empfehlung?

W3C, MDN und SELFHTML verwenden in ihren Beispielen alle <br>. Das nannte der W3C mal HTML5; die WHATWG hat das in HTML Living Standard umbenannt.

Imho sind die vorherigen Antworten alle sachlich richtig; führen aber eher Spezialfälle als die allgemeine Praxis an.

@Auge habe ich einen Pluspunkt gegeben, weil er die generelle Verwendung von <br> zur Abstandskontrolle und die bessere Alternative marginerwähnt hat.

Herzliche Grüße

Matthias Scharwies

[j.j.]

Hallo!

Kurze Antwort: <br> ist richtig, <br/> ist falsch, <br /> ist noch fälscher, aber alles funktioniert gleichermaßen.

Lange Antwort: <br> ist HTML-Syntax und Du schreibst HTML, also nimm das.

<br/> <br /> ist XML-Syntax, Du schreibst aber kein XML, also nimm das nicht.

XML-Syntax hat schon immer in HTML funktioniert, ist aber erst seit seit HTML5 erlaubt - aber nicht empfohlen. Das Leerzeichen vor den Slash ist übrigens besonders wichtig wegen Kompatibilität mit Netscape Navigator 4 (1998) 😀

(Wens genauer interessiert, dem kann ich den Link raussuchen zur E-Mail, in der damals Ian Hickson (HTML-Editor) schweren Herzens die Entscheidung getroffen hat, den Quatsch zu erlauben)

j.j.

[Gunnar Bittersmann]

@@j.j.

Kurze Antwort: <br> ist richtig, <br/> ist falsch, <br /> ist noch fälscher,

Kurze Antwort: Deine Antwort ist zu ⅓ richtig, zu ⅔ falsch.

Und wenn wir noch einbeziehen, ob man „falsch“ steigern kann, ist das letzte Drittel gar noch falscher. 😜

XML-Syntax hat schon immer in HTML funktioniert, ist aber erst seit seit HTML5 erlaubt

Eben: erlaubt. Also nicht falsch.

aber nicht empfohlen.

Sagt wer?

(Wens genauer interessiert, dem kann ich den Link raussuchen zur E-Mail, in der damals Ian Hickson (HTML-Editor) schweren Herzens die Entscheidung getroffen hat, den Quatsch zu erlauben)

Man kann Hixie nicht nachsagen, jemals die Vorteile von XML verstanden zu haben.

Ich schreibe jedenfalls polyglottes HTML (also XML-Syntax): <br/>. Und da ich auf Kompatibilität mit Netscape Navigator 4 keinen Wert lege, ohne Lehrzeichen.

Kwakoni Yiquan

[Der Martin]

Hi Gunnar,

ohne Lehrzeichen.

eerlich?

Einen schönen Tag noch
 Martin

[Gunnar Bittersmann]

@@Der Martin

ohne Lehrzeichen.

eerlich?

Ērlich.

(Bin gerade in Rīga. Im Lettischen schreibt man lange Vokale mit Makron. Da kann man schon mal durcheinander kommen. 🤪)

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Gunnar Bittersmann

(Bin gerade in Rīga. Im Lettischen schreibt man lange Vokale mit Makron. Da kann man schon mal durcheinander kommen. 🤪)

„Sie werden Shakespeare erst wirklich genießen, wenn Sie ihn im lettischen Original lesen.“

Kwakoni Yiquan

[j.j.]

@@j.j.

Kurze Antwort: <br> ist richtig, <br/> ist falsch, <br /> ist noch fälscher,

Kurze Antwort: Deine Antwort ist zu ⅓ richtig, zu ⅔ falsch.

Und wenn wir noch einbeziehen, ob man „falsch“ steigern kann, ist das letzte Drittel gar noch falscher. 😜

... they call it houmor ...

XML-Syntax hat schon immer in HTML funktioniert, ist aber erst seit seit HTML5 erlaubt

Eben: erlaubt. Also nicht falsch.

Kann man so sehen. Für mich ist es falsch, weil es umfangreicher (in vieler Hinsicht) ist, ohne Mehrwert.

aber nicht empfohlen.

Sagt wer?

?! Ich sagte: > XML-Syntax [...] ist [...] erlaubt – aber nicht empfohlen.

Also niemand, zumindest HTML nicht (direkt). Indirekt mglw. über sämtliche Codebeispiele und den Quellcode der Spezifikation selbst.

Allerdings gibt es https://html.spec.whatwg.org/multipage/syntax.html#start-tags, Punkt 6: ... it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution ... Dieser Text wird übrigens – je nach Sichtweise – gerne als Argument gegen anführungszeichenfreie Attributwerte ge- bzw. mißbraucht.

Aber es gibt diverse Syle-Guides (auch für den Spec-Text selber oder füt WPT (wenn ich nicht irre)). Auch Google sieht das so, aber nur die alten Säcke halten sich noch dran.

(Wens genauer interessiert, dem kann ich den Link raussuchen zur E-Mail, in der damals Ian Hickson (HTML-Editor) schweren Herzens die Entscheidung getroffen hat, den Quatsch zu erlauben)

Man kann Hixie nicht nachsagen, jemals die Vorteile von XML verstanden zu haben.

Was soll die Polemik? Nach meine Einschätzung versteht er XML besser als wir beide zusammen. Er gewichtet die Vorteile halt anders als Du.

XML hat/hätte sicher Vorteile [gehabt] (wollen wir dieses Faß jetzt wirklich aufmachen?). Aber das ist kein Grund den Syntax in HTML zu verwenden.

Ich schreibe jedenfalls polyglottes HTML (also XML-Syntax)

Cooool, daß es sowas heut' noch gibt! (dazu fällt mir dieser Link ein: https://html.spec.whatwg.org/multipage/html-xhtml-author-guide/html-xhtml-authoring-guide.html (merkst Du was?)

Hast du auch nur einmal eine dieser "polyglotten" Dateien als "text/xml" servieren lassen und hat der Browser was sinnvolles angezeigt? Wenn ja, war da auch Javascript dabei? Wenn ja, dann würd ich gern einen Link sehen!

Auf die Gefahr hin, daß es doch noch ein Faß gibt: https://html.spec.whatwg.org/#the-xhtml-syntax

Using the XML syntax is not recommended, for reasons which include the fact that there is no specification which defines the rules for how an XML parser must map a string of bytes or characters into a Document object, as well as the fact that the XML syntax is essentially unmaintained — in that, it’s not expected that any further features will ever be added to the XML syntax (even when such features have been added to the HTML syntax).

Kwakoni Yiquan

[Gunnar Bittersmann]

@@j.j.

Man kann Hixie nicht nachsagen, jemals die Vorteile von XML verstanden zu haben.

Was soll die Polemik? Nach meine Einschätzung versteht er XML besser als wir beide zusammen.

Es gibt Aussagen von ihm, die mich das bezweifeln lassen.

Aber das ist kein Grund den Syntax in HTML zu verwenden.

Die Syntax ist weiblich.

Hast du auch nur einmal eine dieser "polyglotten" Dateien als "text/xml" servieren lassen und hat der Browser was sinnvolles angezeigt?

Ja – um etwas zu machen, was in HTML gar nicht geht: selbst definierte Entitys. Testseite, Präse Slides 20 ff.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

Die Syntax ist weiblich.

Nicht immer 😜

selbst definierte Entitys.

Das ist ja mal eine coole Idee. Aber ist das nicht so, als würde man die Zange benutzen, um einen Nagel einzuschlagen? Nur um Aliasnamen für NCRs zu erschaffen, dem Browser einen XML-Mode mit SGML-Historie abzuverlangen? Da sollte man doch eher die Entity-Definition zu einem regulären Teil von HTML machen.

HTML in XML-Schreibweise ergibt Sinn, wenn man einen kompletten XML Workflow hat. Den haben aber die wenigsten, der XML Hype hat sich für HMTL nicht gehalten. Weißt Du, ob es hierzu Nutzungsdaten gibt?

Und natürlich ist der XML-Parser nicht totzukriegen, weil es Seiten da draußen gibt, die ihn brauchen, und Kompatibilität das oberste Credo im Web ist. Das ist aber kein Grund, XML zu zementieren. Find ich.

Wichtig ist halt dies: Wenn man schon mit <br /> anfängt, dann muss man es auch richtig machen und ein XML-valides HTML Dokument erstellen (a.k.a. polyglott). Das ist gar nicht mal so einfach, im HTML Mode verzeiht der Browser einiges, was er im XML-Mode brutal abwürgt.

Nachtrag an j.j.:

Für mich ist es falsch, weil es umfangreicher (in vieler Hinsicht) ist, ohne Mehrwert.

Dass Dir Dinge aus deiner Perspektive falsch erscheinen, bedeutet längst nicht, dass sie objektiv auch wirklich falsch sind. Dass Du potenzielle Mehrwerte nicht benötigst, heißt nicht, dass sie nicht existieren.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Nur um Aliasnamen für NCRs zu erschaffen, dem Browser einen XML-Mode mit SGML-Historie abzuverlangen?

Was meinst du mit „mit SGML-Historie“?

„Abzuverlangen“? Der XML-Parser ist in Browsern nun mal da. Man kann ihn also verwenden.

Und wie du weiter unten schriebst, wäre es von Browserherstellern töricht, den XML-Parser zu entfernen.

Und man kann nicht nur „Aliasnamen für NCRs erschaffen“, sondern auch für Abkürzungen:

<!DOCTYPE html [  
  <!ENTITY h "Hommingberg">
  <!ENTITY g "Gepardenforelle">
  <!ENTITY hg "&h;er &g;">
]>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>&hg;</title>
  </head>
  <body>
    <h1>&hg;</h1>
    <p>
      <b>&hg;</b> ist ein Suchbegriff, mit welchem die Computerzeitschrift
      c’t im April 2005 einen Suchmaschinenoptimierungs-Wettbewerb ausrief.
      Der Begriff „&hg;“ wurde gewählt, weil es weder einen Ort <i>&h;</i>
      noch eine <i>&g;</i> gibt und somit die Suchmaschinen dazu vor dem
      Beginn des Wettbewerbes keine Treffer lieferten.
    </p>
    <footer>
      Quelle: Wikipedia,
      <a href="https://de.wikipedia.org/wiki/&h;er_&g;">&hg;</a>
    </footer>
  </body>
</html>

☞ Testseite

---

Da sollte man doch eher die Entity-Definition zu einem regulären Teil von HTML machen.

Glaubst du dran?

---

HTML in XML-Schreibweise ergibt Sinn, wenn man einen kompletten XML Workflow hat. Den haben aber die wenigsten, der XML Hype hat sich für HMTL nicht gehalten. Weißt Du, ob es hierzu Nutzungsdaten gibt?

Nein. Der Anteil an XHTML dürfte aber verschwindend gering sein. Ob das nun 0.01% sind oder 0.001% …

Kwakoni Yiquan

[ThomasM]

Hallo zusammen,

Nein. Der Anteil an XHTML dürfte aber verschwindend gering sein. Ob das nun 0.01% sind oder 0.001% …

Bei E-Books (EPUB) wären es 100% und somit ist polyglottes HTML der auch aus meiner Sicht anzustrebende ganzheitliche Ansatz.

Grüße,
<Thomas/>

[Gunnar Bittersmann]

@@j.j.

XML-Syntax hat schon immer in HTML funktioniert, ist aber erst seit seit HTML5 erlaubt

Eben: erlaubt. Also nicht falsch.

Kann man so sehen. Für mich ist es falsch, weil es umfangreicher (in vieler Hinsicht) ist

??

ohne Mehrwert.

Doch, XML-Syntax bietet einen Mehrwert: einfache Regeln.

Anstatt „du kannst Attributwerte in Anführungszeichen setzen, musst das aber nicht tun, es sei denn, der Wert enthält Zeichen aus <lange Liste>, dann musst du es doch tun“ in HTML-Syntax einfach „Attributwerte müssen in Anführungszeichen stehen“ in XML-Syntax.

Anstatt „du kannst bei diesen Elementen <lange Liste> End-Tags setzen oder auch nicht, bei anderen wiederum musst du es tun, bei wieder anderen – den Standalone-Elementen – darfst du es nicht tun“ in HTML-Syntax einfach „jedes Element muss geschlossen werden, bei Standalone-Elementen ist dafür die Kurzschreibweise zu verwenden“ in XML-Syntax.

Die Schreibweise <x/> für Standalone-Elemente bietet gegenüber <x> den Mehrwert, dass sie die Suche nach einem End-Tag erspart, wenn man den Elementtypen nicht kennt.

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Die Schreibweise <x/> für Standalone-Elemente bietet gegenüber <x> den Mehrwert, dass sie die Suche nach einem End-Tag erspart, wenn man den Elementtypen nicht kennt.

Lief über’n Ticker:

🔥 Hot take: The self-closing syntax makes HTML easier to learn.

It means novices can tell the difference between valid and invalid markup *before* they memorize HTML’s entire vocabulary of element names.

Given that HTML is the most novice-friendly language in the web platform, I think that’s a benefit worth preserving.

But even to experts, the cognitive process of reading a tag name and remembering whether it’s self-closing is much slower (though both tasks are very fast in absolute terms).

Generally, *reading* even one word is much slower than identifying familiar symbols which can be recognized in one go, as images (the "familiar" part is important; unfamiliar symbols introduce way more friction than reading — I’m looking at you WebKit devtools).

— Lea Verou

Kwakoni Yiquan

PS: Tab Atkins widerspricht im Thread.