Nach all den Jahren, in denen sich XHTML 1 größter Beliebtheit erfreute, sieht für viele Webworker so etwas aus wie ein einziger Syntaxfehler:
<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<p class="welt">Hallo Welt!
<ul>
<li>Lorem
<li>Ipsum
<li>Dolor
</ul>
Da fehlen zwar einige Start- und End-Tags, aber tatsächlich ist das ein absolut gültiges HTML(5)-Dokument. Man kann das gleiche Dokument natürlich auch so schreiben …
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<title>Hallo Welt!</title>
</head>
<body>
<p class="welt">
Hallo Welt!
</p>
<ul>
<li>Lorem</li>
<li>Ipsum</li>
<li>Dolor</li>
</ul>
</body>
</html>
… aber hat man etwas davon? Der Browser (jeder Browser) baut aus beiden HTML-Schnipseln das exakt gleiche DOM und damit die exakt gleiche Website zusammen. Tags wie <body>
und </li>
werden vom HTML-Parser auf eigene Faust an den richtigen Stellen eingebaut, so dass es im Endeffekt völlig egal ist, ob man HTML in der Spar-Variante schreibt, das XHTML-Lookalike nimmt oder sich seine eigene Mischform zusammenkombiniert. Welche Tags man unter welchen Umständen auslassen kann erklären unter anderem die HTML5-Spezifikationen.
Die Präsentation des ersten HTML-Schnipsels sorgt manchmal für erhebliches Gruseln, doch wenn man mal die ersten Abwehrreflexe sieht unaufgeräumt aus
und kenne ich nicht
überwunden hat, wird klar, dass minimales HTML durchaus seine Vorteile hat: man tippt schließlich weniger und transferiert weniger Bytes zum Browser des Users. Das Einzige, auf das man manchmal aufpassen muss, sind die Inhalte an den Grenzen ausgelassener Tags. Angenommen dies wäre unser HTML:
<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<script>alert("Hello World!")</script>
<p class="welt">Hallo Welt!
<!-- Saluton Mondo! -->
Wo werden hier </head>
und </body>
eingefügt? Landen der Kommentar und das <script>
-Element außerhalb oder innerhalb des Bodys? Die Antwort: das Script landet im Head und der Kommentar als letztes Element im Body. Der Parser schließt den Head erst, wenn er das erste Element antrifft, dass keinesfalls im Head vorkommen kann, was in diesem Fall das <p> wäre. Gleiches gilt beim Kommentar, denn der könnte zwar auch erst nach dem Body kommen, aber der Parser hat keinerlei Anlass, den Body vor dem Kommentar zu schließen. Wenn es bei solchen zweideutigen Elementen wie Scripts und Kommentaren mal wirklich wichtig ist, was in solchen Grenzgebieten wo landet sind die optionalen Tags von unter anderem <html>
, <body>
und <li>
das Mittel der Wahl, aber sonst? Kann man machen, muss man nicht.
Update: Lest das hier um zu verhindern, dass euch fehlende Body-Starttags im IE in den Hintern beißen.
Kommentare (24)
Rodney Rehm ¶
8. November 2010, 13:34 Uhr
Hallo Peter,
"muss man nicht" bedeutet aber nicht "sollte man nicht".
Man spart sich bei dieser minimalistischen Schreibweise doch bestenfalls 10 Sekunden Tipparbeit und vielleicht ein bisschen Traffic (wohoo!). Man verliert aber an Eindeutigkeit. Habe ich einen und einen muss ich nicht lange Denken um zu wissen in welchem Kontext das nun ausgeführt wird.
Valides xHTML5 kann von jeden dahingerotzten XML-Parser interpretiert werden. minimalistisches HTML5 nicht. Die Fehlerkorrektur des Browsers fehlt hier in aller Regel. Was dazu führt, dass WebScraping-Dienste einen (massiven) Mehraufwand fahren müssen, um ihre Daten extrahieren zu können.
Wir sprechen bspw. von Microformats und ähnlichen tollen Sachen, vergessen aber, dass sich auch andere Tools als Browser, und andere Services als Google und Yahoo an eben diesen Informationen erfreuen könnten. Wer seine Seiten semantisch (html+) auszeichnet, sollte auch dafür sorgen, dass diese Daten von simpler gestrickten Maschinen gelesen werden können.
Obwohl du natürlich recht hast, das minimalistische HTML durchaus legitim ist, halte ich es für fahrlässig dafür zu werben.
Axel ¶
8. November 2010, 13:35 Uhr
ist böse ;(
Das liefert man im HTTP-Header aus, ansonsten muss der Browser das Parsing nochmal beginnen.
Thomas ¶
8. November 2010, 13:46 Uhr
Ich schreibe bisher zwar auch "XHTML-Konformes" HTML5, könnte mir aber vorstellen nach und nach umzusteigen...
Es gibt sogar eine Situation, wo schließende Tags ein echtes Problem sind: nämlich bei inline-block-Elementen, wo der Whitespace zwischen zwei angrenzenden Elementen als einzelnes (und meist unerwünschtes) Leerzeichen dargestellt wird, sobald die beiden Elemente im Quelltext nicht unmittelbar aufeinander folgen.
Javos ¶
8. November 2010, 13:56 Uhr
Zitat Axel:
Wie definierst du denn den HTTP-Header in HTML?
Peter ¶
8. November 2010, 14:54 Uhr
Zitat Rodney Rehm:
Da würde ich widersprechen. Erstens: Was hilft es dir, dein HTML-Dokument in
<html></html>
einzuboxen? Was wird dadurch eindeutiger? Ich würde sogar ein Gegenbeispiel zu Felde führen, denn verschachtelte Listen werden durch Tag-Auslassung sehr viel einfacher zu schreiben, weil die Gefahr von versehentlichen Direkt-Verschachtelungen der Listen-Elemente ausgemerzt wird. Sowas hier, was normalerweise schnell mal passiert …… kann einem ohne
</li>
-Tags einfach nicht unterlaufen.Fehlerkorrektur? Die fehlenden Tags sind keine Fehler, sondern ein Sprachfeature! Und dass XML-Parser HTML nicht parsen können, ist in etwa so logisch, wie dass JavaScript-Interpreter kein Perl können.
Wenn all diese Scraper und sonstige „simpler gestrickten Maschinen“ nicht in der Lage sind, eine der vielen großartigen Open-Source-HTML-Parser zu verwenden, die allesamt 1A Fehlerkorrektur – für richtige Fehler, nicht ausgelassene Tags – verwenden, weiß ich ehrlich gesagt nicht was ich sagen will. Für den schnellen Zwischendurch-Scraper verwende ich zum Beispiel gerne Beautiful Soup (Python), das ist eine No-Brainer Drop-In-Lösung die auf fehlende Tags klarkommt und sonst auch den gröbsten Müll schluckt. Warum kann ich sowas und die nicht?
Zitat Axel:
Wohl wahr, aber wenn das das erste Element im Dokument ist, dürfte das kaum spürbare Verwerfungen hinterlassen. Und wenn das Charset im HTTP-Header schon festgelegt wurde, wird das Meta-Element ignoriert und ist nicht wirklich böse, sondern nur ein Backup.
cortex ¶
8. November 2010, 14:59 Uhr
Zitat Axel:
quatsch. die meta-angabe ist eine (gültige!) ergänzung zum entsprechenden http-header und dient als fallback, wenn letzterer nicht via skript / server gesetzt wird.
zum thema: ich bin bei rodney.
cx
Bertram Simon ¶
8. November 2010, 15:05 Uhr
Werden Tabellen unter HTML5 eigentlich auch dramatisch einfacher? Dann könnte ich meinen http://xoc.de/image2html.php erweitern.
Francesco ¶
8. November 2010, 16:48 Uhr
Im IE funktioniert ohne
body
der DOM-Zugriff per JavaScript nicht zuverlässig.Marco ¶
8. November 2010, 16:55 Uhr
Jeder wie er will.
Ich glaube wenn man es sauber einrückt, sieht es ohne schließende Tags deutlich eleganter und übersichtlicher aus. Python ist ja auch schöner als Java oder PHP zu lesen.
Dan ¶
8. November 2010, 17:08 Uhr
Das erinnert ein wenig an das »if« in PHP, welches auch mit Kurzschreibweise ohne geschweifte Klammern geschrieben werden kann. Geht schneller von der Hand und ist vermeintlich schnell zu erkennen. Aber fast alle großen Projekte empfehlen trotzdem geschweifte Klammern mitsamt Zeilenumbruch zu setzen, aus Gründen der Lesbarkeit und Eindeutigkeit. Ich glaube darums geht rodney auch: Mit obigen Code gibt's keine Probleme, wenn der konstant so geschrieben würde und nur wenn er nur in Browser XY Verwendung findet. Spätestens wenn mehrere Entwickler verschachteltes HTML raushauen seh ich dieses interessante, für mich neue HTML5 Feature als Veständnisbarriere wirken.
PS: Kann sein, dass ich als XHTML Geschädigter dieses Feature als Fehlertolleranzfeature wahrnehme auch wenns keins ist, denn es ist ja korrektes HTML, aber ich verlasse mich als Entwickler darauf, dass der Browser dann schon das richtige Tag setzt und dieses „drauf verlassen“ fühlt sich komisch an.
Axel ¶
8. November 2010, 17:24 Uhr
Zitat Javos:
Gar nicht, das muss man im Server einstellen. Bei Apache via .htaccess mit "AddDefaultCharset utf-8"
Wenn dein Hoster das nicht zulässt, dann würde ich dringend empfehlen ihn zu wechseln xD
Rodney Rehm ¶
8. November 2010, 19:02 Uhr
Natürlich hast du mit deinen Anführungen nicht unrecht, Peter. Und vielleicht bin ich, wie Dan, zu sehr xHTML-geschädigt. Aber ich sehe, wo Francesco gerade darauf hinweist, mehr Verwirrung als Verbesserung:
Schauen wir uns beispielsweise <tbody> an. Optional seit jeher. Auch in xHTML. Aber auch in Javascript und CSS?
document.querySelectorAll( 'table > tr' );
findet nichts. Sollte es (imho) aber, wenn <tbody> wirklich optional wäre. Sicher, die _Notation_ ist optional. Aber was ich nicht in den DOM werfe, erwarte ich dort doch auch nicht, oder?Würden wir nur über HTML sprechen, würde ich dir vermutlich sogar zustimmen. Webseiten bestehen heutzutage aber auch aus Javascript und CSS. Und die sehen manche Dinge einfach anders. Gerade "Anfänger" lassen sich von solchen Unterschieden schnell ins Boxhorn jagen. (Mich hat es damals jedenfalls Wahnsinnig gemacht.)
Peter ¶
8. November 2010, 20:26 Uhr
Zitat Bertram Simon:
Zitat Dan:
Das ist kein neues HTML5-Feature. Das war schon immer so in HTML, das haben bloß wegen des XHTML-Wahns alle vergessen. Daran ist überhaupt rein gar nichts HTML5-spezifisch. Entsprechend funktioniert das auch in jedem Browser der letzten 10 Jahre.
Zitat Rodney Rehm:
Genau das Beispiel wollte ich gerade rausholen! Ich kenne nämlich fast niemanden, der bei einfachen Tabellen überall
<tbody>
-Tags einfügt und bisher scheinen all diese Leute problemlos damit klargekommen zu sein. Warum sollte das plötzlich anders werden, wenn diese Strichliste nach reiflicher Überlegung um<html>
und<head>
erweitert würde?alexander farkas ¶
8. November 2010, 20:33 Uhr
Es ist immer sehr schwer Code einer Sprache zu beurteilen, die man täglich schreibt. Soviel Konvention und Gewohnheit führt zu dem typischen Empfinden, daß das was man schon immer macht:
1. schön aussieht und
2. verständlicher ist als andere Schreibweisen
Innerhalb des zusammenarbeitenden, eingespielten Entwicklerteams dürfte dieses Empfinden wohl auch stimmen.
Ich kann mich mit der minimalen HTML schreibweise nicht anfreunden, u.a. weil ich sie (durch Gewohnheit?) als häßlich empfinde und weil sie so lax ist. Ich habe auch nicht ansatzweise das Gefühl, daß ich mich mal zwingen sollte, es anders zu sehen/zu versuchen.
Codeersparnis sehe ich nicht wirklich, wenn ich am Ende die Größe der Seite, des CSS, JS und Bilder berücksichtige.
Zudem kommen mit der HTML-Schreibweise viele zusätzliche - nicht nötige - aber dafür mit Ausnahmen behaftete Schreibmöglichkeiten rein. Bei p, li-Elementen darfst du auf das schließende Tag verzichten bei div nicht. Bei Attributen kannst du die Anführungszeichen weglassen, nur eben nicht wenn du Leerzeichen in deinem Wert hast...
Letztendlich sind das schon Fehlerquellen und man kann Sie mit konsequenten polyglottem HTML(5) nicht nur vermeiden, sondern hat auch ein Validierungstool dafür. Sofern es eine Art zuverlässigen HTML-Lint/HTML-Stylechecker geben würde, mit dem man sich seine eigene "Laxheit" zwischen XHTML und HTML Schreibweise zusammenkonfigurieren könnte, würde ich das bei bestimmten nicht XHTML-fähigen Schreibweisen vielleicht anders sehen. Aber mit den herkömlichen Validatoren haben wir eh nur die Möglichkeit zwischen vollkommen lax oder strict und da wähle ich dann strict.
Rodney Rehm ¶
8. November 2010, 20:55 Uhr
Zitat Peter:
Ich. hier. Oft um Gruppen von Datensätzen auch als solche identifizieren zu können. Meistens jedoch einfach aus Gewohnheit, weil wir das in unserem Team als Konvention eingeführt haben, um alle auf einen Nenner zu bringen und potentiellen Fehlern (siehe Alexander Farkas) von vornherein den Gar aus zu machen.
Zitat Peter:
Tummelst du dich öfter mal an Orten wo auch Frischfleisch zu Wort kommt? Ich sehe solche Fragen immer wieder mal. Das doofe ist, dass wenn das Problem auftaucht, der Fragesteller meist noch nie etwas von
<tbody>
gehört hat. Warum auch? Ist ja optional. Braucht kein Mensch…Zitat Peter:
Ich glaube, dass wir zwei uns hier nicht annähern. Du bleibst im HTML-Lager und mein Bett steht in der xHTML-Baracke. Aber das ist ja auch vollkommen in Ordnung so :)
antpaw ¶
8. November 2010, 21:27 Uhr
wenn man html kann, sollte man sowieso haml nutzen :)
Jakob ¶
9. November 2010, 06:32 Uhr
Eine Alternative ist das minimale HTML sicherlich, aber bevorzugen würde ich es nicht. Zeitersparnis sehe ich kaum; Eine Seite ist meist schnell geschrieben, und die meiste Zeit geht dann für Stylesheets, Optimierung und Content drauf. Also denke ich, dass es sich auf Seiten mit viel Inhalt einfach nicht rentiert, da viel zu viel "langsamladende"-Grafiken und eine Fülle an Content ein wenig HTML gegenübersteht mit nem haufen CSS im Hintergrund.
Kaiuwe ¶
9. November 2010, 08:35 Uhr
Angesichts vorhandener Editoren und IDEs mit automatischer Codevervollständigung ist der Vorteil eher gering.
Thomas Scholz ¶
9. November 2010, 08:47 Uhr
Zitat Rodney Rehm:
Nein, sollte es nicht. Die explizite Notation ist optional, aber das Element existiert in HTML immer. Das ist genauso wie bei
body
,head
undhtml
. Nur in echtem XHTML (passender HTTP-Header) klappt das nicht mehr, da triffttable > tr
tatsächlich zu.Das Starttag für
html
lasse ich nicht aus, weil hier der beste Platz für die Sprachangabe ist:Alle anderen Möglichkeiten, wie HTTP-Header oder Meta-Element, werden nicht so zuverlässig erkannt. Leider.
Schepp ¶
9. November 2010, 15:49 Uhr
Zitat Axel:
Stimmt nur bedingt: http://www.kylescholz.com/blog/2010/01/performance_implications_of_charset.html
Zitat Rodney Rehm:
Gut argumentiert! Sehe ich wie Du.
Axel ¶
9. November 2010, 16:14 Uhr
Auch abgesehen von der Performance ist es einfach schöner das im Header zu versenden, anstatt es *ins* Dokument zu setzen, von dem das Encoding an diesem Punkt ja noch gar nicht bekannt ist.
Das hat was von sich an den Haaren aus dem Moor ziehen.
Thomas Scholz ¶
9. November 2010, 21:40 Uhr
Das Meta-Element mit dem Charset steht doch nur für Mozilla drin (und WebKit?). Opera und der IE schreiben die Zeichenkodierung beim Abspeichern brav ins Dokument, Mozilla nicht. Zumindest ältere, neue habe ich nicht mehr daraufhin getestet.
Verwendet man also ordentliches UTF-8 und läßt die Angabe weg, so fällt Mozilla beim Anzeigen selbst abgespeicherter Dokumente auf den Standardwert zurück, der hierzulande meistens Windows-1252 ist. Sieht blöd aus. Will man nicht.
Gleiches gilt für Stylesheets, in denen man Nicht-ASCII-Zeichen benutzt hat: Da kommt
@charset "UTF-8";
an den Anfang, oder es geht schief.Die Zeichenkodierung ist eine Eigenschaft des Dokumentes, nicht des Transports. Ein wenig koordinierte Redundanz schadet hier nicht. Eleganz muß da leider zurücktreten, bis wir uns auf schlaue Browser verlassen dürfen.
Schamlose Selbstwerbung: Zeichenkodierung angeben.
André ¶
14. November 2010, 14:51 Uhr
Es ist aber hoffentlich auch klar, dass DOM-Zugriffe mit .textContent bzw. .innerText usw. auf die offengelassenen LI-Elemente etwas anderes zurückliefern als auf die geschlossenen - nämlich noch einen Zeilenumbruch am Ende.
Peter ¶
14. November 2010, 15:10 Uhr
Oh Gott! Zeilenumbrüche