Abschluss Schrägstrich mittlerweile falsch < />

[Henry]

Hallo,

ich dachte eine korrekte Auszeichnung für eine Imagedatei so sein:
Bsp. <img src="x.png" title="y" alt="blabla" />

Dann stellte ich durch Auswertung vom removeAttribute('title') Resultat fest, dass der IMG-Tag auch verändert wurde, nicht nur title-Attribut entfernt.

Es wurde zu <img src="x.png" alt="blabla"> also ohne abschließenden Schrägstrich.

Dachte zuerst an einen Fehler von removeAttribute(), wobei mich schon wundert, dass es mehr macht als es soll, doch ein Blick ins Selfhtml brachte mich dann auf die Spur.

In XHTML benötigt das image-Tag den schließenden Schrägstrich (/).

Aha... also back to the roots? Alles wieder beim Alten auch dieses dämliche </ br> offensichtlich wieder in <br>. Sehr gut ;-)

Aber gibt es da noch was zu beachten, evtl. Ausnahmen?

Gruss
Henry

[Gunnar Bittersmann]

@@Henry

ich dachte eine korrekte Auszeichnung für eine Imagedatei so sein:
Bsp. <img src="x.png" title="y" alt="blabla" />

Ja, das ist korrekt – in XHTML 1.x sowie in HTML5 a/k/a HTML.

Dann stellte ich durch Auswertung vom removeAttribute('title') Resultat fest, dass der IMG-Tag auch verändert wurde, nicht nur title-Attribut entfernt.

Es wurde zu <img src="x.png" alt="blabla"> also ohne abschließenden Schrägstrich.

?? Wo wurde es das? Im Entwicklungswerkzeug deines Browsers?

Nein, wurde es nicht. Es war schon vorher so, bevor du removeAttribute('title') aufgerufen hast.

Das Entwicklungswerkzeug stellt das DOM dar, nicht den HTML-Quelltext, und zwar ohne / beim <img>-Tag, auch wenn’s im HTML-Quelltext als <img/> notiert ist.

Dachte zuerst an einen Fehler von removeAttribute(), wobei mich schon wundert, dass es mehr macht als es soll, doch ein Blick ins Selfhtml brachte mich dann auf die Spur.

In XHTML benötigt das image-Tag den schließenden Schrägstrich (/).

Nein, das stimmt so nicht. (Steht das so in SELFHTML? Wenn ja, bitte die Stelle angeben, damit das berichtigt werden kann.)

In XHTML müssen auch leere Elemente wie img geschlossen werden. Das kann durch / im Start-Tag geschehen – oder auch mittels End-Tag: <img src="…" alt="…"></img>

Aha... also back to the roots? Alles wieder beim Alten auch dieses dämliche </ br> offensichtlich wieder in <br>. Sehr gut ;-)

Du meintest <br/>?

HTML5 kann in HTML-Syntax sowie in XHTML-Syntax geschrieben werden.

In XHTML-Syntax muss es <br/> heißen, in HTML-Syntax (die üblicherweise verwendet wird) ist beides erlaubt: <br> und <br/>. [HTML §8.1.2.1]

Aber gibt es da noch was zu beachten, evtl. Ausnahmen?

Alles – ohne Ausnahme.

Äh, was meintest du mit der Frage?

LLAP 🖖

[Henry]

Hallo,

ich dachte eine korrekte Auszeichnung für eine Imagedatei so sein:
Bsp. <img src="x.png" title="y" alt="blabla" />

Ja, das ist korrekt – in XHTML 1.x sowie in HTML5 a/k/a HTML.

hmmm?

Das Entwicklungswerkzeug stellt das DOM dar, nicht den HTML-Quelltext, und zwar ohne / beim <img>-Tag, auch wenn’s im HTML-Quelltext als <img/> notiert ist.

Stimmt, habs gerade überprüft(quelltextausgabe über script, sehr vieles sieht dann anders aus). Wundert mich allerdings diese Inkonsistenz. Gestern hatte ich hier ein anderes Problem geschildert und da ging es darum, dass relative links in besagter Quelltextausgabe erscheinen wie im Originalquelltext, obwohl sie anders verarbeitet werden. Wenn das DOM schon umgestellt wird und ich es mir dann auf Basis des Entwicklerwerkzeugs(wie du es nennst:-) anschaue, dann doch komplett und nicht mal so und dann wieder anders.

Bsp.
<img src="xy.png" alt="test" />

wird zu
<img alt="test" src="xy.png">

Attr. Reihenfolge geändert, Slash entfernt.

Während ich dann erwartet hätte:
<img alt="test" src="http://irgendwas/xy.png">.

In XHTML benötigt das image-Tag den schließenden Schrägstrich (/).

Nein, das stimmt so nicht. (Steht das so in SELFHTML? Wenn ja, bitte die Stelle angeben, damit das berichtigt werden kann.)

Bin mir zwar sicher, dass du das längst kontrolliert hast... aber hier

In XHTML müssen auch leere Elemente wie img geschlossen werden. Das kann durch / im Start-Tag geschehen – oder auch mittels End-Tag: <img src="…" alt="…"></img>

Schon klar, aber warum sollte noch jemand, dieses ungeliebte, XHTML verwenden?

Äh, was meintest du mit der Frage?

Mich eigentlich vergewissern, dass nun keine End-Slashes mehr notwendig sind oder sogar falsch. Und wie(keine wirkliche Frage) bring ich das nur meinem Editor bei, keine Fehlermeldung mehr bei fehlendem Slash zu zeigen ;-)

Gruss
Henry

[dedlfix]

Tach!

ich dachte eine korrekte Auszeichnung für eine Imagedatei so sein:
Bsp. <img src="x.png" title="y" alt="blabla" />

Ja, das ist korrekt – in XHTML 1.x sowie in HTML5 a/k/a HTML.

hmmm?

XHTML ist XML-kompatibel und hat dessen Syntaxregel zu folgen, die deutlich strenger sind als die von HTML. XML-Kompatibilität spielt aber keine Rolle im Browser.

Wenn das DOM schon umgestellt wird und ich es mir dann auf Basis des Entwicklerwerkzeugs(wie du es nennst:-) anschaue, dann doch komplett und nicht mal so und dann wieder anders.

Es wird nicht zum Spaß umgestellt, sondern weil das DOM die Grundlage ist, mit der der Browser arbeitet, um seine Ausgabe erstellen zu können. Dazu gehört dann auch, dass Fehler korrigiert werden, dass relative Links zu vollständigen aufgelöst werden, und so weiter. Mit relativen Adressen können keine Requests abgesetzt werden.

Bsp.
<img src="xy.png" alt="test" />

wird zu
<img alt="test" src="xy.png">

Attr. Reihenfolge geändert, Slash entfernt.

Die Reihenfolge spielt keine Rolle, der Slash ebensowenig. Diese Ausgabe wird zurückgerechnet aus der internen Datenhaltung. Deswegen wirst du die Attribute vermutlich so sehen, wie der Browser die Eigenschaften in seinen internen Objekten angeordnet hat.

Schon klar, aber warum sollte noch jemand, dieses ungeliebte, XHTML verwenden?

Es war lange Zeit der Standard. Der Mensch ist ein Gewohnheitstier und schaltet gern mal den Verstand aus und schreibt das in altbewährter Weise hin. Die Browser sind ja sehr gutmütig. Bevor XHTML standardisiert wurde, waren diese unnötige Slashes sogar ein Fehler. Sie mussten extra mit Leerzeichen davor geschrieben werden, damit die Browser das als unbekanntes Attribut angesehen und ignoriert haben.

Zudem gibt es weiterhin Programmierwerkzeuge, die diese Slashes von selbst einfügen, wenn sie inhaltsleere Elemente wie meta, image oder br einfügen/autovervollständigen.

Mich eigentlich vergewissern, dass nun keine End-Slashes mehr notwendig sind oder sogar falsch.

Browser sind tolerant, XML-Kompatibilität spielt und spielte so gut wie keine Rolle.

Und wie(keine wirkliche Frage) bring ich das nur meinem Editor bei, keine Fehlermeldung mehr bei fehlendem Slash zu zeigen ;-)

Wenn du es konfigurieren kannst, dann XML-Kompatibilität ausschalten oder HTML5 einschalten. Oder aber die Klasse/Severity(Schweregrad) der Fehlermeldung anpassen, von Fehler auf Hinweis oder Ignorieren. Das kommt auf deinen Editor an, was man da drehen kann.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Schon klar, aber warum sollte noch jemand, dieses ungeliebte, XHTML verwenden?

Es war lange Zeit der Standard.

Nein, das denke ich nicht. Zu Zeiten von HTML 4.01 und XHTML 1.0 wurde wohl deutlich mehr HTML 4.01 als XHTML 1.0 verfasst.

Bevor XHTML standardisiert wurde, waren diese unnötige Slashes sogar ein Fehler.

In HTML 4.01, ja.

Sie mussten extra mit Leerzeichen davor geschrieben werden, damit die Browser das als unbekanntes Attribut angesehen und ignoriert haben.

Dann waren die Slashes in HTML 4.01 aber immer noch ein Fehler.

Das Leerzeichen war deshalb, weil einige Browser <br /> verarbeiten konnten, <br/> aber nicht.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Zu Zeiten von HTML 4.01 und XHTML 1.0 wurde wohl deutlich mehr HTML 4.01 als XHTML 1.0 verfasst.

Andernfalls wäre die Entwicklung von XHTML 2 auch nicht im Sande verlaufen.

Das Leerzeichen war deshalb, weil einige Browser <br /> verarbeiten konnten, <br/> aber nicht.

Solche Browser sollte es heutzutage nicht mehr geben.

Ingrid

LLAP 🖖

[MudGuard]

Hi,

Bevor XHTML standardisiert wurde, waren diese unnötige Slashes sogar ein Fehler.

Nein, das > danach. Und auch nach Standardisierung von XHTML war HTML immer noch SGML.

In SGML ist der / ein Tag-Ende (unter anderem).

<p>bla</p>

und

<p/bla/

waren gleichbedeutend. Zumindest in der Theorie, die Browser haben die Slash-Variante eher nicht unterstützt.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Zumindest in der Theorie, die Browser haben die Slash-Variante eher nicht unterstützt.

Das und die Tatsache(?), dass die SGML-Spec nicht frei verfügbar ist, haben mich nie die Untiefen von HTML/SGML lernen lassen.

HTML5 ist nicht so schön einfach wie XML, aber zumindest ist es kein SGML mehr. 😉

LLAP 🖖

[Henry]

Hallo,

Ja, das ist korrekt – in XHTML 1.x sowie in HTML5 a/k/a HTML.

hmmm?

XHTML ist XML-kompatibel und hat dessen Syntaxregel zu folgen, die deutlich strenger sind als die von HTML. XML-Kompatibilität spielt aber keine Rolle im Browser.

Nochmal hmmm... Welche Schreibweise ist denn nun richtig in HTML5

Wenn das DOM schon umgestellt wird und ich es mir dann auf Basis des Entwicklerwerkzeugs(wie du es nennst:-) anschaue, dann doch komplett und nicht mal so und dann wieder anders.

Es wird nicht zum Spaß umgestellt, sondern weil das DOM die Grundlage ist, mit der der Browser arbeitet, um seine Ausgabe erstellen zu können. Dazu gehört dann auch, dass Fehler korrigiert werden, dass relative Links zu vollständigen aufgelöst werden, und so weiter. Mit relativen Adressen können keine Requests abgesetzt werden.

Eben, genau das meine ich ja, wenn schon interne Korrektur, dann doch auch das DOM komplett korrigiert anzeigen, inkl. relative Links -> Komplettlink.

Danke an alle für die ausführlichen Antworten, doch leider bin ich nun noch mehr verwirrt.

Was ist denn nun wirklich die einzig korrekte Schreibweise für HTML5?:

<img src="" alt="">
oder
<img src="" alt="" />

Gruss
Henry

[dedlfix]

Tach!

Was ist denn nun wirklich die einzig korrekte Schreibweise für HTML5?:

<img src="" alt="">
oder
<img src="" alt="" />

Beide. Nimm die erste, die zweite ist nur länger.

dedlfix.

[Gunnar Bittersmann]

@@Henry

Nochmal hmmm... Welche Schreibweise ist denn nun richtig in HTML5

Das hatte ich doch schon im allerersten Posting beantwortet. Sogar mit Link zur entsprechenden Stelle der Spec. Punkt 6 ist der entscheidende hier.

LLAP 🖖

[Henry]

Hallo,

Das hatte ich doch schon im allerersten Posting beantwortet. Sogar mit Link zur entsprechenden Stelle der Spec. Punkt 6 ist der entscheidende hier.

6.Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single "/" (U+002F) character. This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.

Na ja, klar war das für mich nicht wirklich, erst recht nicht mit deinen, sorry, recht wagen Aussagen:

Ja, das ist korrekt – in XHTML 1.x sowie in HTML5 a/k/a HTML.

Nein, das stimmt so nicht. (Steht das so in SELFHTML?...

Dabei ist die Antwort von Dedlfix klar und unmissverständlich. Mein Fehler lag darin, dass ich davon ausging, es gäbe nur eine einzig richtige Schreibweise.

Gruss
Henry

[Gunnar Bittersmann]

@@Henry

… mit deinen, sorry, recht wagen Aussagen:

Ich hatte weder zu Wagen noch zu Waagen Aussagen gewagt. 😉

Ja, das ist korrekt – in XHTML 1.x sowie in HTML5 a/k/a HTML.

Was war an der Aussage, dass die Schreibweise mit / richtig ist, vage?

Nein, das stimmt so nicht. (Steht das so in SELFHTML?...

Was war an der Aussage, dass das <img>-Tag in XHTML kein schließendes / benötigt (wenn das Element durch ein End-Tag </img> geschlossen wird), vage?

Dabei ist die Antwort von Dedlfix klar und unmissverständlich.

Ebenso klar und unmissverständlich wie Punkt 6 in dem verlinkten Abschnitt der Spec. Deshalb hatte ich ihn verlinkt.

Und war genau war an meiner Antwort „in HTML-Syntax (die üblicherweise verwendet wird) ist beides erlaubt: <br> und <br/>“ nicht klar und unmissverständlich?

Ich kann dedlfix’ Schlussfolgerung übrigens nicht teilen und setze dem entgegen: Nimm die zweite (mit /), die ist eindeutiger.

Mein Fehler lag darin, dass ich davon ausging, es gäbe nur eine einzig richtige Schreibweise.

Warum meine erste Antwort dein Missverständnis nicht ausgeräumt hat, bleibt mir ein Rätsel.

LLAP 🖖

[dedlfix]

Tach!

Ich kann dedlfix’ Schlussfolgerung übrigens nicht teilen und setze dem entgegen: Nimm die zweite (mit /), die ist eindeutiger.

Für wen? Dass img, meta, br und so weiter leere Elemente sind, und auch wozu sie da sind und deshalb keinen Inhalt haben, muss man schon wissen, wenn man Code verstehen möchte. Und der Parser braucht das Zeichen nicht. Einen / zu notieren, bringt aus meiner Sicht keinen gesteigerten Nutzen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Nimm die zweite (mit /), die ist eindeutiger.

Für wen?

Für Leser des Codes.

Dass img, meta, br und so weiter leere Elemente sind […], muss man schon wissen, wenn man Code verstehen möchte.

Mit / muss man das eben nicht wissen, sondern der Code sagt es einem.

Einen / zu notieren, bringt aus meiner Sicht keinen gesteigerten Nutzen.

Gesteigerten nun nicht gerade. Für mich überwiegt aber der mögliche Nutzen den „Nachteil“, ein Zeichen mehr zu schreiben.

LLAP 🖖

[dedlfix]

Tach!

Nimm die zweite (mit /), die ist eindeutiger.

Für wen?

Für Leser des Codes.

Welchen Typ Leser stellst du dir da vor?

Dass img, meta, br und so weiter leere Elemente sind […], muss man schon wissen, wenn man Code verstehen möchte.

Mit / muss man das eben nicht wissen, sondern der Code sagt es einem.

Man muss solche inhaltlichen Dinge nicht wissen, aber die Feinheiten der Syntax kennt man bereits? Was ist das für ein Leser? Beziehungsweise, was nützt es ihm?

"Aha, das ist ein leeres Element, aber was es tut, weiß ich nicht."

vs.

"Oh, ein unbekanntes Element. Was tut es?" Nachlesen. "Aha, dafür ist es da und leer ist es außerdem." (anhand der Beschreibung erklärt bekommen).

Das Wissen braucht er sowieso, denn es wird ihm auch Code begegnen, der diese überflüssigen Zeichen nicht enthält oder mal verwendet und mal nicht.

Einen / zu notieren, bringt aus meiner Sicht keinen gesteigerten Nutzen.

Gesteigerten nun nicht gerade. Für mich überwiegt aber der mögliche Nutzen den „Nachteil“, ein Zeichen mehr zu schreiben.

Zwei Zeichen.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Welchen Typ Leser stellst du dir da vor?

Gar keinen. Ich schreibe einfach mit /; vielleicht nutzt es jemandem. Es schadet ja niemandem.

Gesteigerten nun nicht gerade. Für mich überwiegt aber der mögliche Nutzen den „Nachteil“, ein Zeichen mehr zu schreiben.

Zwei Zeichen.

Eins. Ich schreibe <br/>, nicht <br />. Clients, die das ohne Leerzeichen nicht raffen, sind so veraltet (sicherheitsgefährdend), dass sie nicht mehr am Netzverkehr teilnehmen sollten.

Wie ich schon sagte, besteht ein Nutzen von polyglottem HTML-Code darin, ihn als XML verarbeiten zu können. Beispielsweise nach den strengeren XML-Regeln zu prüfen. Ein HTML-Parser wird nicht geschlossene Elemente u.U. nicht anmeckern und ein anderes DOM erzeugen als beabsichtigt. Es ist ein Einzeiler in der Serverkonfiguration, sein Zeugs als application/xhtml+xml an den Markup-Checker und als text/html an alle anderen Clients auszuliefern.

Aber das / meine ich nur als Empfehlung; ich bin weit davon entfernt, da den Zeigefinger heben zu wollen und zu sagen: du solltest. Oder gar: du musst.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Dass img, meta, br und so weiter leere Elemente sind […], muss man schon wissen, wenn man Code verstehen möchte.

Mit / muss man das eben nicht wissen, sondern der Code sagt es einem.

Die Vermutung, dass ein Code-Leser versteht, dass <br /> ein leeres Tag ist aber nicht weiß, dass br per se leer ist, halte ich für durchaus gewagt 😉

Ich habe aber prinzipiell auch nichts gegen <br />-Schreiber, das geht mir genau so rein wie <br>, ich will nicht gegen eine dieser Schreibweisen argumentieren.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Die Vermutung, dass ein Code-Leser versteht, dass <br /> ein leeres Tag ist aber nicht weiß, dass br per se leer ist, halte ich für durchaus gewagt 😉

Vielleicht lässt sich dafür ein anderes Beispiel als br finden. Vielleicht auch nicht. 😉 Neu hinzukommende leere Elemente wird es in HTML wohl nicht geben.

Leere Elemente sind ja ein Sprachdesignfehler in HTML.

LLAP 🖖

[Gunnar Bittersmann]

@@Henry

Schon klar, aber warum sollte noch jemand, dieses ungeliebte, XHTML verwenden?

„XHTML verwenden“ hieße heute:

1. die XHTML-Syntax zu verwenden und
2. das mit XHTML-Medientypen wie application/xhtml+xml auszuliefern.

Letzters will man i.a.R. nicht.

Ersteres hat dieselben Vorteile wie vor 10 Jahren.

Die Verwendung von XHTML-Syntax, damit man das als text/html oder als XML ausliefern kann, nennt sich jetzt „polyglottes HTML“.

LLAP 🖖

[dedlfix]

Tach!

Ersteres hat dieselben Vorteile wie vor 10 Jahren.

Ich würde das neutral als Eigenschaften benennen. Ob es ein Vorteil oder vielleicht nur unnötiger Ballast ist, kommt auf die Situation beim Empfänger an.

Webseiten sind vorwiegend für die Darstellung im Browser da, der seine umfangreichen Fehlerkorrekturmechanismen mitbringt. Zum maschinellen Datenaustausch, für den man ein einfach und eindeutig und ohne große Umstände zu lesendes Format haben möchte, gibt es solche mit strengerer Syntax. Und vor allem ohne den unnötigen Ballast, den nur der Browser für die Darstellung braucht.

dedlfix.

[Felix Riesterer]

Lieber Gunnar,

„XHTML verwenden“ hieße heute:

1. die XHTML-Syntax zu verwenden und
2. das mit XHTML-Medientypen wie application/xhtml+xml auszuliefern.

ich habe den Wortlaut unter dem Beispiel so geändert:

Bei xml-konformer Schreibweise (wie z.B. in XHTML) benötigt das image-Tag den schließenden Schrägstrich (/).

Das sollte so klarer machen, dass die selbstschließende Schreibweise mit XML-Konformität zu tun hat und dass XHTML diese benötigt.

Letzters will man i.a.R. nicht.

Das wiederum steht auf einem völlig anderem Blatt.

Liebe Grüße,

Felix Riesterer.

[Matthias Scharwies]

Servus!

In XHTML benötigt das image-Tag den schließenden Schrägstrich (/).

Aha... also back to the roots? Alles wieder beim Alten auch dieses dämliche </ br> offensichtlich wieder in <br>. Sehr gut ;-)

Einen imho interessanten Überblick über Entstehung und Entwicklung von HTML gibt es hier:

• HTML/Entstehung_und_Entwicklung

Das verlinkt dann auch auf:

• HTML/Unterschiede_von_HTML_zu_XHTML

• HTML/Unterschiede von HTML5 zu HTML4

Herzliche Grüße

Matthias Scharwies