HTML5: Best practice bei leeren Elementen?

[misterunknown]

Moin,

ist es in HTML5 üblich leere Elemente wie bei XHTML zu kennzeichnen? Also quasi nicht <br> sondern <br /> zu schreiben? Gültig ist ja beides, und auf den Seiten des w3c werden beispielsweise Meta-Elemente nicht geschlossen. Andererseits werden hier beispielsweise die Input-Elemente geschlossen. Gibt es da Argumente dafür und dagegen?

Grüße Marco

[suit]

Gibt es da Argumente dafür und dagegen?

<br /> ist länger, aber hat dafür aber das Potential, dass du HTML-Schnipsel mit einem XML-Parser lesen/schreiben kannst. Ich erzeuge z.B. mein HTML grundsätzlich mit SimpleXML, dann kann nix schief gehen - valide ist es beidermaßen.

<br> ist kürzer - wenn du also du brrrrrrr-Orgien neigst, nimm das :)

[dedlfix]

Tach!

ist es in HTML5 üblich leere Elemente wie bei XHTML zu kennzeichnen? Also quasi nicht <br> sondern <br /> zu schreiben? Gültig ist ja beides, und auf den Seiten des w3c werden beispielsweise Meta-Elemente nicht geschlossen. Andererseits werden hier beispielsweise die Input-Elemente geschlossen. Gibt es da Argumente dafür und dagegen?

Es ergibt für mich keinen Sinn, leere Elemente nach XHTML-Stil zu schließen, dann aber Attribute nach HTML-Stil zu verwenden, also nur den Namen ohne Inhalt zu notieren, so wie das auf der verlinkten Seite zu sehen ist. Das ist dann ein Mischmasch aus XML- und HTML-Stil. Praktisch argumentiert ist es den HTML(5)-Parsern vermutlich egal, was sie da vorgesetzt bekommen, sie müssen so fehlertolerant sein, beides verstehen zu können. Demzufolge ist das / nur zusätzliche Mehrarbeit. Das war es im Prinzip auch bei XHTML-Dokumenten, weil die üblicherweise nicht durch den XML-Parser sondern den normalen HTML-Parser gesendet wurden, der mit Tag-Soup statt wohlgeformtem XML umzugehen wusste. Sie wurden vermutlich selten bis nie in XML-Umgebungen gelesen. Andererseits kann das / zur besseren Lesbarkeit beitragen, um zu kennzeichnen, dass da ein leeres Element beabsichtig ist. Aber eigentlich ist auch das nicht notwendig, denn ein HTML-Schreiber sollte wissen, welche Elemente leer sind und welche nicht.

dedlfix.

[Gunnar Bittersmann]

@@misterunknown:

nuqneH

ist es in HTML5 üblich leere Elemente wie bei XHTML zu kennzeichnen?

„Üblich“ würde ich nicht sagen.

Also quasi nicht <br> sondern <br /> zu schreiben? Gültig ist ja beides

Ja, im Gegensatz zu HTML 4 ist <br /> in HTML5 erlaubt.

Gibt es da Argumente dafür und dagegen?

Dafür: Dieselben Argumente, die für XHTML 1 statt HTML 4 sprachen. Polyglottes HTML5 ist als XML verarbeitbar, bspw. nach strengeren Regeln validierbar.

Dagegen: Es sind jeweils ein Byte (bei <br/> ohne Leerzeichen) bzw. zwei Byte (bei <br /> mit Leerzeichen) mehr.

Du wägst ab.

Qapla'

[dedlfix]

Tach!

Dafür: Dieselben Argumente, die für XHTML 1 statt HTML 4 sprachen. Polyglottes HTML5 ist als XML verarbeitbar, bspw. nach strengeren Regeln validierbar.

Waren/sind das vorwiegend theoretische Argumente oder hat tatsächlich jemand einen Nutzen von der XML-Nutzbarkeit von Webseiten? Die sind doch üblicherweise nicht dafür gedacht, XML-lesbar (maschinell auswertbar) zu sein. Um auf diese Weise Daten zu extrahieren ist doch viel zu viel unnützer Kram dabei. (Von rechtlichen Aspekten mal ganz abgesehen.) Besser ist es doch, die bereitgestellten APIs zu verwenden, wenn der Betreiber ein Datenabschnorcheln vorgesehen hat.

Suchmaschinen allerdings sind ein etwas anderes Thema. Die sollen ja nicht die reinen Daten sehen, sondern die Seiten so vorgesetzt bekommen, wie sie auch die menschlichen Besucher sehen. Um die Bedeutung der Daten zu erhalten, ist (X)HTML auch nicht sonderlich hilfreich. Da steht dann sowas wie "Liste" im Code, aber den Sinn der Liste, geschweige denn den Sinn der Inhalte, kann man ja aus den HTML-Elementen nicht herauslesen. Die zeichnen den Inhalt nur in Bezug auf die Päsentation aus. Nicht umsonst bilden sich solche Projekte wie Semantic Mediawiki, die die Daten an sich in Beziehung setzen, so dass sie zum Beispiel gezielter durchsuchbar sind. Die Hauptstadt eines Landes ist da schon auf Datenebene als Hauptstadt zu erkennen. Aus einer (X)HTML-Seite ist es hingegen ungleich schwieriger, die Hauptstadt-Information zu extrahieren.

dedlfix.

[molily]

Hallo,

Waren/sind das vorwiegend theoretische Argumente oder hat tatsächlich jemand einen Nutzen von der XML-Nutzbarkeit von Webseiten?

Anbindungen an performante, valide XML-Parser mit eleganten APIs finden sich in jeder Programmiersprache. Anbindungen an wirklich taugliche HTML5-Parser sind leider immer noch rar. Vor kurzem hat Google erst einen wiederverwendbaren HTML5-Parser in C veröffentlicht, für den gerade Bindings entstehen. Das haben wir für XML schon seit 10 Jahren.

Besser ist es doch, die bereitgestellten APIs zu verwenden, wenn der Betreiber ein Datenabschnorcheln vorgesehen hat.

Kommt auf die Daten an. Eine klassische REST-API ist sinnvoll, solange es ein spezifisches, sich wiederholendes Datenformat gibt und ein zentraler Zugriff von außen nötig ist. HTML ist ein geeignetes Format, um generische, verknüpfte Dokumente auszuzeichnen, die noch mit ein paar Metadaten angereichert sind. Es kann über verschiedene Protokolle übertragen werden.

Um die Bedeutung der Daten zu erhalten, ist (X)HTML auch nicht sonderlich hilfreich.

Das würde ich so nicht sagen. Einfache Texte lassen sich in (X)HTML gut auszeichnen und maschinell verarbeiten. Mit Microdata, RDFa und meta-/link-Elementen habe ich durchaus die Möglichkeit, zusätzliche Semantik unterzubringen.

Mathias

[dedlfix]

Tach!

Waren/sind das vorwiegend theoretische Argumente oder hat tatsächlich jemand einen Nutzen von der XML-Nutzbarkeit von Webseiten?
Anbindungen an performante, valide XML-Parser mit eleganten APIs finden sich in jeder Programmiersprache. Anbindungen an wirklich taugliche HTML5-Parser sind leider immer noch rar. Vor kurzem hat Google erst einen wiederverwendbaren HTML5-Parser in C veröffentlicht, für den gerade Bindings entstehen. Das haben wir für XML schon seit 10 Jahren.

Das ist immer noch Theorie. Und die Praxis? Wo werden denn Webseiten ausgewertet und benötigt dazu XHTML? Wenn man nicht selbst die Seiten erstellt hat, kann man sich doch nicht sicher sein, dass da alles richtig ist, geschweige denn, dass man Anspruch auf eine Reparatur hat. Wenn man mit dem Anbieter zusammenarbeitet, werden sich auch Möglichkeiten finden, nicht gerade Webseiten zum Datenaustausch zu verwenden.

Also, wo ist denn das prominente Beispiel, wo XHTML einen Nutzen bringt? (Weniger prominente reichen mir allerdings auch.)

Um die Bedeutung der Daten zu erhalten, ist (X)HTML auch nicht sonderlich hilfreich.
Das würde ich so nicht sagen. Einfache Texte lassen sich in (X)HTML gut auszeichnen und maschinell verarbeiten.

Was nützt mir als Otto-Normalverbraucher die Semantik der Textstrukturierung. Das ist doch, mal so gesagt, nur Schnickschnack für die optische Darstellung. Daraus lässt sich doch nur sehr begrenzt etwas über den Inhalt sagen.

Mit Microdata, RDFa und meta-/link-Elementen habe ich durchaus die Möglichkeit, zusätzliche Semantik unterzubringen.

Und was macht die auslesende Maschine, wenn der Seitenbetreiber sich entschließt, die Elemente umzusortieren? Fehlermeldungen schreiben, weil der XPath-Ausdruck nicht mehr stimmt. Ich weiß nicht so recht, Webseiten als Transportmedium für maschinell auswertbare Daten scheint mir weiterhin nicht wirklich praktikabel zu sein.

Ich erweitere noch mal die eigentliche Frage: Ist XHTML zu verwenden für den 08/15-Seitenbetreiber wirklich vorteilhafter als HTML?

dedlfix.

[misterunknown]

Moin,

vielen Dank für eure Antworten. Ich denke ich werde die schließenden Slashs bei leeren Elementen weglassen, da ich keine XML-Konformität brauche.

Grüße Marco