HTML5: So sparst du Quelltext und bleibst dennoch standardkonform
Auf HEAD und BODY verzichten
Die HEAD- und BODY-Elemente gehören zu den elementarsten HTML-Elementen. Doch in HTML5 gibt es nicht mehr die grundsätzliche Pflicht, diese Elemente im Quelltext aufzuführen. Es geht auch ohne:
<!DOCTYPE html>
<html>
<title>Titel der Seite</title>
<link href="style.css" rel="stylesheet" type="text/css" />
<script src="script.js" type="text/javascript"></script>
<p>Hier steht Text.</p>
</html>Der im Beispiel dargestellte Quelltext ist valide, obwohl HEAD- und BODY-Element fehlen. Denn Browser, die HTML5 interpretieren können, ergänzen von sich die beiden Elemente. Dabei werden alle Elemente, die im HEAD-Element vorkommen können, automatisch deam HEAD zugeordnet. Erst das P-Element, was im Kopf einer Seite nichts zu suchen hat, wird dem BODY-Element zugeordnet.
Lässt man sich die DOM-Struktur der Seite darstellen, wird man feststellen, dass der Browser eigenständig HEAD- und BODY-Element dem DOM hinzugefügt und die vier Elemente (TITLE-, LINK-, SCRIPT- und P-Element) entsprechend dem HEAD- oder BODY-Element zugeordnet hat.
Zwingend erforderlich wäre das HEAD-Element nur, wenn das SCRIPT-Element nicht im Kopf, sondern im Body des Dokumentes dargestellt werden soll.
Auf schließende Tags verzichten
In vielen Fällen kann auf schließende Tags verzichtet werden. Das ist zum Beispiel bei Listen der Fall, bei denen schließende Tags verzichtbar sind:
<ul> <li>Äpfel <li>Birnen <li>Kischen </ul>
Auch hier ergänzt der Browser die schließenden Tags automatisch in der DOM-Struktur. Ähnliches gilt auch für das P-Element. Auch hier kann auf das schließende Tag verzichtet werden, wenn eindeutig ist, an welcher Stelle der Browser das schließende P-Tag ergänzen soll.
Folgt zum Beispiel eine Überschrift, ist eindeutig, dass das P-Element an dieser Stelle geschlossen werden soll:
<p>Hier ist ein Absatz, der da endet, wo eine Überschrift steht <h1>Überschrift</h1>
Auch für Tabellengilt diese Regel:
<table> <tr><td>Äpfel<td>Birnen<td>Kirchen</tr> </table>
Fazit
Grundsätzlich lässt sich sagen, dass auf öffnennde und schließende Tags dann verzichtet werden kann, wenn für den Browser eindeutig zu erkennen ist, an welcher Stelle ein öffnendes beziehungsweise schließendes Tag einzufügen ist.
Konkrete Regeln, bei welchen Elementes das unter welchen Umständen der Fall ist, lassen sich beim W3C nachlesen. Wer sich auf minimalistisches HTML5 einlässt, sollte gut wissen, ob auf das Setzen des Tags tatsächlich verzichtet werden kann. Wer auf platzsparenden Quelltext setzt, um seine Seite etwas ressourcensparender auszuzeichen, wird sicher Freude daran haben.
Was haltet ihr von der Möglichkeit, Quelltext zu sparen, indem ihr auf bestimmte Tags verzichtet? Lohnt sich das oder ist die Gefahr zu groß, unübersichtlichen und gegebenenfalls nicht mehr validen Text zu bekommen?
Weiterführende Links zum Thema HTML5:
- HTML5-Websites offline nutzen mit Application Cache
- HTML5: Browser-Kontextmenü um eigene Menüpunkte erweitern
- HTML5 Video: 18 Player für Websites und Blogs
- HTML5 Please! Alle Features im Überblick
- HTML5: Pflichtfelder und Eingabevorgaben für Formulare festlegen
Interessant zu wissen, aber bloß nicht einsetzen. Die meisten Editoren werden dann verrückt spielen, zumindest am Anfang. Außerdem haben die meisten Webseiten andere Probleme als zu viele schließende Tags und man sollte eher da ansetzen.
Das Ganze ist ja auch nicht komplett neu. Die Browser versuchen schon seit längerer Zeit fehlende Tags automatisch hinzuzufügen. Ist natürlich für die Fehlersuche nicht gerade das gelbe vom Ei. Neu daran ist hauptsächlich, dass es trotzdem valider HTML Code ist.
Ich schließe mich meinem Vorschreiber an. Es ist interessant als Möglichkeit, aber wie sieht das mit etwas älteren Browsern aus? Wie ist es wenn man die HTML Seiten minified ausgibt?
Wenn man mit CMS arbeitet, gibt es oft die Notwendigkeit zu ladezeitoptimierung einen Teil der Skripte ans Ende der Seite zu packen (wurde ja auch in den Artikeln erwähnt). Ich denke das dies in der Praxis (noch?) keinen Relevanz hat.
Auch macht das in der Ladezeit bei komplexen Seiten nicht so viel aus. Ich könnte mir ggf. vorstellen, das es dadurch länger dauert, bis der Browser die Seite gerendert hat (Komplexere Seite vorausgesetzt).
Ich denke man kauft sich mehr Ärger als Vorteile ein.
Allerdings wird dann wohl die rückwärtskompatibilität zu älteren Browsern darunter leiden. Und ob Screenreader damit auch richtig klarkommen?
@robbz Guter Einwurf Screenreader werden gerne immer vergessen.
Mir ist die Page Performance immer sehr wichtig. Daher würde ich testen, ob eine Seite schneller lädt, die auch den schließenden Tag im Code aufweist, als eine Seite, welche durch den kompatiblen Browser, an unmissverständlicher Stelle, „korrigiert“ werden muss.
Spontan würde ich dazu neigen, den HTML-Code als etwas unübersichtlich wahrzunehmen, wenn schließende Tags weggelassen werden würden, gerade beim Code, den man nicht selbst geschrieben haben könnte.
Jetzt gefällt es mir erst einmal nicht – der Code wirkt schließlich fehlerhaft.
technisch nette idee, aber nicht wirklich sinnvoll zu gebrauchen, die paar bytes sind meist schneller geladen, als dass dann doch etwas zufällige rendern (vorallem in alten Browsern) dauert. Von Fehlersuche mit dem Editor mal ganz abgesehen …
Ich würde mal sagen, das bischen Performance, kann man gut und gerne an anderer Stelle einsparen. Gerade der Übersichtlichkeit halber.
Allein von der Tatsache her, ist es aber schon recht befriedigend zu wissen, dass mir der Browser einiges an Fehlersuche abnimmt, indem er einige der Tags schließt, falls ich mal ein schließendes Tag vergessen haben sollte (was natürlich nicht eigentlich nicht vorkommt :D )
Die einzigen Pflichtelemente in HTML sind Doctype und title-Element. Das gibt’s aber nicht erst seit HTML5, sondern war auch schon vorher so.
Deshalb auf die anderen Elemente oder die schließenden Tags zu verzichten, halte ich für wenig sinnvoll. Welche Ressourcen kostet es denn, ein schließendes auszulesen?
Würde ich aus verschiedenen Gründen in der Praxis nicht anwenden – Gründe wurden ja schon genannt.
Auf meiner (platzhalter) Website tquensen.de hab ich das zum Spass trotzdem gemacht und komme dadurch auf ganze 5 Zeilen valides HTML5 ;)
Wenn man z.B. EPGs darstellen will und nur EDGE hat, wäre nett wenn man nur (TD) und kein (/TD) bräuchte in Tabellen. Da könnte man tausende Tags einsparen. Oder wenn man Macros hätte wie #defines in C aber ohne die Macken.
Wichtig wäre ein Rewriter der alle kickbaren Elemente anzeigt und markiert bzw. wieder hinzufügt (als proxy within). Anhand der W3C-Standards kann man sowas ja bauen. Wichtig wären auch Hinweise wie „Deine Javascripte sind … weshalb das …-Tag gebraucht wird. Setz sie an folgende Stellen und das Tag kann gespart werden… .
gzip/bzip2 schadet auch nicht, wenn man weiss, das ein Edge-Phone an der anderen Seite der Leitung ist. Wenn man FTTH o.ä. „merkt“, kann man die Seiten auch raw unkomprimiert rüberschicken. Der Oma hilft man die Einkäufe in die Tasche zu packen, der schnellen Hausfrau schiebt man es nur schnell vor den Einkaufswagen – wenn man an der Kasse „served“.
Auch Scraper und Auslesetools welche kommen werden, wenn man endlich mal Microformate nutzen würde, könnten Probleme kriegen. So gesehen währen proxies within (sowas wie Greasemonkey-standalone oder Proxomitron) wohl schon eine schlaue Infrastruktur.
Man könnte mit xmllint und –html (html-Parser) und –xmlout (force XML output when –html) mal schauen und in der Anleitung nachlesen ob die es nach W3C-Standard machen und damit evtl. auch erfolgreich die fehlenden Tags nachrüsten. Z.b. mit den Beispielen aus dem Text.
In Verbindung mit fremdem html/xml-Code sollte man vielleicht sowieso häufig xmllint vorschalten um Probleme zu vermeiden oder zu bemerken. Statt solche simplen Standards systematisch zu nutzen wird lieber gefrickelt und bei Problemen nachgefrickelt. xmllint ist die Wareneingangskontrolle der xml-Welt aber auch als Schweizer Taschenmesser zu nutzen.
Schön zu wissen, dass man so einiges einsparen könnte, aber ich denke auch, diese Kurzschreibweise (vor allem die fehlenden schließenden Tags) würde den Code mehr als unübersichtlich machen und vor allem in älteren Browsern vermehrt zu Fehlern führen.
Soll HTML-Code exakt maschinenlesbar sein (z.B. via Javascript), sollten Elemente immer geschlossen werden. Der von Element.innerHTML bzw. Element.textContent zurückgegebene Inhalt hängt ja auch von der Position des schließenden Tags ab. Werden Elemente explizit geschlossen, befindet sich der in der Praxis meist folgende Zeilenumbruch außerhalb des Elementes — schließt man es nicht, bekommt man diesen in Element.textContent mitgeliefert.
@xml lint rules da house: Warum muss eine im Grunde ganz einfache Sache immer bloß so kompliziert gemacht werden, anstatt sie einfach einfach zu machen.
Eines der wesentlichen Elemente von Ladezeitoptimierung ist (wie schon oben erwähnt) das Verlagern von JS-Dateien an das Ende des Dokumentes.
Damit ist der Ansatz zwar schön, geht aber an der Realität vorbei.
Da die meisten Browser heute mit gzip-komprimierten Seiten umgehen können und man bei den meisten Providern die Dateien auch entsprechend ausliefern lassen kann, fallen die wenigen eingesparten Byte bei der Ladezeit sowiso nicht ins Gewicht.
Wesentlich mehr kann durch Optimierung der zusätzlich zu ladenden Dateien, wie der verwendeten Grafiken (und evtl. Filme) eingespart werden.
Ein Vielfaches an Datenübetragung könnte man z.B. dadurch sparen, dass für Animationseffekte benötigte JS-Biblotheken und dazugehörende Erweiterungen nicht jedes mal vollständig neu geladen werden müssten, (weil x-verschiedene Varianten) sondern als standardisierte Erweiterung überall vorhanden wären.
Ausserdem in dem man viele Animationsgrafiken nicht als animated gif oder gar als mpg-movie o.ä. sondern als animierte Vektorgrafiken a‘ la Flash einbindet (nach meiner Erfahrung bis zu 20fache Ersparnis).
Danke für den Hinweis. In der Summe machen sich die Code-Einsparungen dann nämlich doch irgendwann bemerkbar.
Auf HEAD und BODY werde ich bei meinem nächsten Projekt einfach mal verzichten und schauen, ob es Probleme gibt.
Noch ein Hinweis: Beim Einbinden der CSS-Anweisung kann man type=“text/css“ auch noch weglassen, da Browser diesen Typ ohnehin standardmäßig vermuten.