0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

3 Vorbereitende Basics In diesem Kapitel soll im Schwerpunkt die Basis des gesamten WWW behandelt werden – (X)HTML. Wenn Sie JavaScripts im Rahmen einer Webseite anwenden wollen, werden Sie das immer innerhalb eines HTML- bzw. XHTML-Gerüsts machen. Deshalb zählt die grundsätzliche Kenntnis von (X)HTML zum unabdingbaren Wissen, wenn Sie JavaScript programmieren wollen. Dabei soll aber in diesem Kapitel ausdrücklich im Auge behalten werden, dass die Zielgruppe für dieses Buch bereits Erfahrung mit der Erstellung von Webseiten hat. Sie werden hier weder eine Einführung in die Webseitenerstellung noch eine vollständige Behandlung von HTML finden. Stattdessen betrachten wir das Thema aus einem höheren Blickwinkel, bei dem die Grundlagen vorausgesetzt werden. Und zudem wird ein Fokus auf die Neuerungen von HTML5 gelegt, was der kommende Standard im Web werden wird. Über (X)HTML hinaus berühren wir in diesem Kapitel aber auch Style Sheets (CSS) und XML. Dabei ist das Wissen in beiden Techniken vielleicht nicht so elementar für einen JavaScript-Programmierer, wie es die Kenntnis von (X)HTML ist. Aber bei anspruchsvolleren Skripten respektive Webseiten werden Sie einen Kontakt nicht vermeiden können. Und spätestens bei AJAX bzw. RIAs werden Sie mit beiden Techniken konfrontiert. Sie lernen in diesem Kapitel etwas über die Geschichte von HTML und XHTML, die Probleme von HTML mit seinen vielen Dialekten, den prinzipiellen Aufbau von HTML und XHTML, die Grundstrukturen von HTML und XHTML sowie die Unterschiede zwischen HTML und XHTML, die neuen HTML5-Elemente, erste Grundlagen zum DOM-Konzept, die wesentlichen Fundamente von Style Sheets anhand von CSS (inklusive der Neuerungen von CSS3) und XML-Grundlagen.

53

Kapitel 3

Vorbereitende Basics

3.1

Der Aufbau von (X)HTML-Dateien

Fassen wir am Anfang zusammen, was wir bereits über HTML wissen bzw. was ich voraussetzen möchte. HTML ist eine interpretierte Dokumentbeschreibungssprache mit einem festgelegten Satz von Anweisungen, mit der im Wesentlichen die logischen Strukturen eines Dokuments beschrieben werden. Das gesamte WWW besteht in seiner Grundstruktur aus HTML. HTMLDateien selbst bestehen immer aus reinem Klartext ohne irgendwelche Formatierungen zur Gestaltung des Quellcodes. Damit sind HTML-Dokumente plattformunabhängig. Eine HTML-Datei muss jedoch im Browser interpretiert werden, um der Seite eine über reinen Text hinausgehende Bedeutung zu verleihen, und kann auch binäre Ressourcen wie Bilder durch Verknüpfung verwenden. HTML verfügt nun im Gegensatz zu vollständigen Programmier- oder Skriptsprachen (wie etwa JavaScript) über keine Kontrollstrukturen in Form von Bedingungen, Sprüngen oder Schleifen. Es gibt keinen Programmfluss in dem Sinn, wie er bei Programmen oder Skripten vorkommt. Ebenso werden Sie in HTML keine Variablen finden (im engeren Sinn – Formularfelder kann man im weiteren Sinn als Variablen verstehen). Es gibt ebenso keine Befehle im Sinne von Befehlswörtern, die eine Aktion auslösen. Allerdings beinhaltet HTML ab der Version 4 Schlüsselwörter, die Voraussetzung für das Aufrufen von Funktionen sind (sogenannte Eventhandler). Ein solcher Eventhandler dient in HTML aber zum Aufruf von Funktionen wie JavaScripts und nicht zu einer Programmflusssteuerung auf Basis von HTML. Nun werden auch Dokumentenbeschreibungssprachen wie HTML über die Zeit immer weiter entwickelt (zurzeit der Bucherstellung wird die fünfte Vollversion von HTML freigegeben und es gibt bis heute eine Vielzahl von Zwischenversionen und herstellerspezifischen Spezialvarianten sowie XHTML). Es gibt dementsprechend zum einen eine Vielzahl von Browsern, die spezielle Varianten von HTML verstehen, die anderen Browsern unbekannt sind. Zum anderen gibt es über die gesamte Existenz des WWW immer ältere Browser, die Befehle neuerer Sprachversionen nicht kennen (können), da zu deren Entstehungszeit die entsprechenden Befehle noch nicht vorhanden waren. Kurz gefasst – es gibt also Befehle, die der eine Browser kennt, der andere jedoch nicht.

3.1.1 Das Prinzip der Fehlertoleranz Was soll nun aber geschehen, wenn ein Browser eine Webseite mit einer Anweisung lädt, die er nicht versteht. Abstürzen? Oder eine Fehlermeldung bringen, mit der üblicherweise kein Anwender etwas anfangen kann? Es gibt noch eine dritte Lösung – ein Browser kann unbekannte Befehle einfach ignorieren. Das mag zwar erst einmal nicht besonders positiv erscheinen, ist aber – zumindest bei der Beschreibung von Dokumenten – immer noch die beste der drei Varianten. Das Ignorieren von unbekannten Anweisungen durch den Browser basiert auf dem Prinzip der Fehlertoleranz, welches zu den Eckdaten der Interpretation von HTML respektive dem gesamten WWW gehört.

54

Der Aufbau von (X)HTML-Dateien

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

Vereinfacht gesagt veranlasst das Prinzip der Fehlertoleranz Programme zur Auswertung von HTML-Dokumenten, bei der Interpretation so fehlertolerant wie irgend möglich zu sein. Der äußerst positive Effekt ist, dass dann auch syntaktisch unkorrekte Dokumente oder Dokumente mit unbekannten Anweisungen so weit wie möglich ausgewertet werden können. Soweit Browser korrekte bzw. bekannte Anweisungen vorfinden, werden diese Anweisungen ausgeführt. Falsche, unbekannte oder unvollständige Anweisungen werden ganz einfach ignoriert. Im ungünstigsten Fall bleibt reiner, unformatierter Text über und damit jedoch die eigentliche Information einer Webseite weitgehend erhalten. Und das Prinzip der Fehlertoleranz sorgt ebenso dafür, dass fehlende Elemente in einer HTML-Seite quasi automatisch vom Browser im Hintergrund ergänzt werden, wenn die Ergänzung eindeutig möglich ist. Dies ist z.B. der Grund, warum auch Webseiten ohne Grundgerüst im Browser angezeigt werden – meist gänzlich ohne Probleme. Lassen Sie uns das einmal beweisen. Erstellen Sie ein neues Webprojekt kap3 und dort die folgende HTML-Datei kap3_1.html: 01 Eine Webseite – ohne Grundgerüst

Selbst wenn Sie noch nicht oft mit HTML gearbeitet haben, wird Ihnen auffallen, dass in dem Beispiel keinerlei Tags vorkommen und offensichtlich jede Form eines Gerüsts fehlt. Dennoch wird jeder Browser diese Datei als Webseite akzeptieren. Sie werden nirgends einen Hinweis auf einen Fehler finden1. Nun lassen Sie sich die Datei einmal in Firefox anzeigen und analysieren Sie mit Firebug, was der Browser intern aus dem Quelltext macht. Dazu klicken Sie am besten mit der rechten Maustaste in die Webseite und wählen aus dem Kontextmenü den Befehl ELEMENT UNTERSUCHEN. Anschließend öffnet sich Firebug am unteren Rand des Browsers und Sie sehen im Register HTML, dass der Browser das komplette Grundgerüst intern mit einer Vorgabeeinstellung ergänzt hat. Er tut also so, als hätten Sie das Grundgerüst notiert. Sie sehen an diesem Beispiel bereits, wie Sie mittels Firebug sehen können, wie der Browser tatsächlich eine Seite aufbaut. Der Quellcode ist nur eine Arbeitsanweisung für einen Browser, um eine Webseite aufzubereiten. Und wie diese intern tatsächlich umgesetzt wird, hat vielfach nur sehr, sehr wenig mit dem Code zu tun, den Sie notiert haben. Gerade bei sehr komplexen RIAs wird dies zutreffen – vor allem, wenn Strukturen dynamisch erzeugt werden.

Listing 3.1 Hier fehlt das gesamte Grundgerüst der Webseite.

Tipp

Lassen Sie uns festhalten – das Prinzip der Fehlertoleranz vereinfacht die Bereitstellung von Informationen erheblich und hat in der Anfangszeit ohne Zweifel erst den Erfolg des Webs ermöglicht. Allerdings verlieren solche nur lose reglementierten Klartextdokumente die Möglichkeit, zuverlässig von automatischen Analysesystemen ausgewertet zu werden. Und natürlich geht ein Stück Information verloren, wenn es keine Eindeutigkeit von Strukturen gibt.

1 Höchstens könnte die Zeichenkodierung bei Sonderzeichen Probleme machen.

55

Vorbereitende Basics

Kapitel 3

Abbildung 3.1 Der intern verwendete Code unterscheidet sich massiv von dem Quellcode, der geladen wurde.

Info

Bei XHTML wurde deshalb das Prinzip der Fehlertoleranz explizit abgeschafft! Das war im Grunde der hauptsächliche Fortschritt von XHTML, obgleich es vielen Webseitenerstellern eher als Nachteil erschienen ist und letztendlich zum Scheitern von XHTML geführt hat. HTML5 versucht erneut, das Prinzip der Fehlertoleranz zu schwächen, aber nicht so radikal wie XHTML. Darauf kommen wir gleich noch zurück.

HTML ist nun seit seinem ersten Auftauchen um 1990 herum durch mehrere Versionen gegangen. Die bereits angesprochene HTML-Version 4, die bereits seit 1997 verfügbar ist und 1999 nur geringfügig weiterentwickelt wurde, ist auch bis zum Zeitpunkt der Bucherstellung der letzte offiziell verabschiedete Entwicklungsschritt von HTML gewesen und im Web trotz des schon antik zu nennenden Alters immer noch aktuell. Oder anders ausgedrückt – derzeit können Sie sich darauf verlassen, dass HTML4 überall funktionieren wird. HTML5 wird sukzessive aber diesen Standard aktualisieren bzw. erweitern. Info

56

Es gibt seit Januar 2000 mit XHTML die offizielle Ablösung von HTML. XHTML 1.0, was im Gegensatz zu HTML auf XML basiert, ist eine Neuformulierung von HTML 4.01. Die Sprache enthält dabei alle Elemente von HTML 4.01. Nur ist die Syntax von XHTML bedeutend strenger als die von HTML. Die Konsequenz ist, dass ein nicht XHTML-fähiger Webbrowser XHTML-Dokumente jederzeit richtig darstellen kann. Für ihn erscheinen sie als normales HTML. Im Fall einer unklaren Situation wird das Prinzip der Fehlertoleranz ausgenutzt. Gleichzeitig kann XHTML von neueren Browsern gemäß den strengen XHTML-Regeln verarbeitet werden. XHTML hat sich jedoch faktisch in der

Der Aufbau von (X)HTML-Dateien

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

Web-Community nicht durchgesetzt, da die wesentlichen Vorteile von XHTML (strengere Syntax und Reduzierung nichtstandardisierter Anweisungen) dem gemeinen Webdesigner oder auch Hobby-Webseitenersteller eben kaum verständlich sind. Und da die Masse der Webseitenersteller einfach HTML statt XHTML (oder eine Mischform) eingesetzt hat, hüteten sich Browser-Hersteller davor, die HTML-Unterstützung einzustellen und die strengen XHTMLRegeln einzufordern. Im Gegenteil – XHTML wird in der aktuellen Version 2 eingefroren und offiziell nicht mehr weiterentwickelt. Wir werden im Lauf des Kapitels die Unterschiede zwischen HTML und XHTML zusammenfassen.

3.1.2 Steueranweisungen Obwohl es Ihnen bekannt sein dürfte, möchte ich ein paar kleine Bemerkungen über Steueranweisungen verlieren. (X)HTML-Steueranweisungen sind aus sogenannten Tags aufgebaut. Ein Tag beginnt immer mit einer geöffneten spitzen Klammer < und endet mit der geschlossenen spitzen Klammer >. Im Inneren der beiden Klammern befindet sich der konkrete Befehl (der Name eines HTML-Elements). Das kennen Sie. Ein Tag kann unter HTML sowohl klein als auch groß geschrieben werden. Auch Mischen von Groß- und Kleinbuchstaben ist erlaubt. Das hat absolut keine unterschiedliche Auswirkung. Niemals. Dies gilt jedoch nicht für XHTML. Dort werden Anweisungen ausschließlich klein geschrieben. Um konform zu den strengen XHTML-Regeln die Webseiten zu erstellen, sollten Sie in neuen Seiten Steueranweisungen ausschließlich klein schreiben bzw. Ihren HTML-Editor so konfigurieren, dass er das im Hintergrund automatisch macht. Sofern Sie einen unterstützenden Editor haben, bei dem Sie HTML oder XHTML als Zielcode einstellen können, wählen Sie auf jeden Fall XHTML. Das ist niemals von Nachteil, denn auch für ältere Browser ist das dann eben einfach nur (besseres) HTML. Und in Hinsicht auf JavaScript werden wir Eigenschaften immer klein schreiben.

Tipp

In (X)HTML gibt es zwei Formen von Tags: Ein einleitendes Tag (Anfangs-Tag oder Beginn-Tag genannt) Ein beendendes Tag (Abschluss-Tag oder Ende-Tag genannt) Das einleitende Tag öffnet eine Anweisung, während das beendende Tag sie wieder ausschaltet. Beide Tags sehen fast identisch aus, außer dass beim beendenden Tag dem Tag-Befehl ein Zeichen vorangestellt wird – der Slash (Schrägstrich) /. Das öffnende Tag würde mit wieder geschlossen. Wenn beide Tags angegeben werden, bilden Sie immer einen Container (in XML wird dieser Element genannt und diese Bezeichnung kann man auch unter HTML verwenden). Das bedeutet, die im einleitenden Tag angegebene Anweisung (etwa eine Formatierung) wirkt sich auf sämtliche Dinge (Objekte) aus, die sich im Inneren des Containers befinden. Dies wird in vielen Fällen ein Text sein, es kann sich aber auch um eine Grafik oder andere Multimediaobjekte handeln. Das Ende-Tag hebt die Wirkung eines Anfangs-Tag auf.

57

Kapitel 3

Achtung

Vorbereitende Basics

In reinem HTML werden die meisten Tags paarweise vorkommen. Es gibt jedoch einige Situationen, wo HTML-Tags keine Container bilden oder Sie vergessen, ein Ende-Tag anzugeben. In einigen Fällen greift das Prinzip der Fehlertoleranz. Das betrifft die Tags, die nach offizieller Vorgabe paarweise auftreten müssten, aber deren Wirkungsende sich auch ohne Abschluss-Tag auf Grund einer anderen Situation eindeutig ergibt. Der andere Fall betrifft die HTML-Tags, die gar kein offizielles Abschluss-Tag haben (etwa ein Zeilenvorschub mit dem Tag
oder eine horizontale Trennlinie mit ). In XHTML muss aber jedes Tag mit einem Abschluss-Tag versehen werden oder explizit als sogenanntes leeres Element definiert werden (etwa so:
oder

).

Elemente können beliebige – sinnvolle – andere Tags (sogenannte Kindelemente) enthalten, aber die Reihenfolge der Auflösung sollte eingehalten werden! Wenn ein Container weitere Container enthält, sollten diese wieder von innen nach außen beendet werden – in umgekehrter Reihenfolge der Einleitungs-Tags. Man nennt so eine Möglichkeit der Verschachtlung von Elementen ein Strukturmodell. In HTML ist das aber sehr locker formuliert und eine falsche Verschachtlung wird durch das Prinzip der Fehlertoleranz auch stark abgemildert.

Achtung

In XHMTL ist das Einhalten der richtigen Reihenfolge beim Schließen von Elementen zwingend. Ebenso ist hier ziemlich genau festgelegt, welche Elemente überhaupt ineinander verschachtelt werden dürfen. Oder anders ausgedrückt – es gibt hier ein sehr strenges Strukturmodell.

3.1.3 Attribute Viele Tags sind erst dann sinnvoll einzusetzen, wenn sie genauer spezifiziert werden. Das gilt nicht für jedes Tag, aber nicht alle Anweisungen sind eindeutig. Das Abschluss-Tag wird niemals mit Parametern erweitert.

Achtung Parameter beziehungsweise Attribute erweitern ein einleitendes (X)HTMLTag und spezifizieren damit genauer die Bedeutung des Tag. In HTML gibt es zwei Formen von Parametern: 1. Parameter mit einer Wertzuweisung 2. Parameter, die bereits einen Wert repräsentieren

Listing 3.2 Schema eines HTMLTags mit Parameter und Wertzuweisung

58

Parameter mit einer Wertzuweisung bekommen über einen Zuweisungsoperator – das Gleichheitszeichen (=) – den entsprechenden Wert zugeordnet. Dies kann ein Text oder eine Zahl sein. Der zugewiesene Wert kann auch eine beliebige andere Form haben. Ein Tag mit einem Parameter mit einer Wertzuweisung sieht schematisch so aus:

Der Aufbau von (X)HTML-Dateien

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

Viele Befehle lassen sich über mehr als einen Parameter spezifizieren. Diese werden dann einfach durch Leerzeichen getrennt aufgelistet. Bei mehreren Parametern spielt die Reihenfolge der Parameter keine Rolle. In vielen Fällen kann man bei der Wertzuweisung in einem HTML-Tag auf Hochkommata verzichten. Die Anweisung funktioniert in HTML uneingeschränkt. In XHTML muss der zugewiesene Wert jedoch in Hochkommata eingeschlossen werden. Sie sollten in jedem Fall Hochkommata setzen, auch wenn man in HTML5 die Attributwerte nicht zwingend in Hochkommata setzen muss. Denn in einigen Fällen ist das notwendig und wenn man konsequent bleibt, gibt es weniger Fehler und der Code ist besser wartbar bzw. lesbar..

Achtung

Parameter, die bereits einen Wert repräsentieren, brauchen in HTML bloß durch ein Leerzeichen von der Anweisung oder anderen Parametern abgetrennt (!) in das Einleitungs-Tag geschrieben werden. Sie fungieren immer als Schalter. Wenn sie angegeben werden, wird eine Eigenschaft aktiviert, fehlen sie, ist die jeweilige Eigenschaft deaktiviert. Ein Tag mit einem Parameter, der bereits einen Wert repräsentiert, sieht schematisch so aus:

Beispiel:

In XHTML gibt es keine Parameter ohne Wertzuweisung. HTML5 hingegen übernimmt wieder die lockere Variante von reinem HTML und beinhaltet einige Parameter ohne Wertzuweisung.

Listing 3.3 Schema für einen Parameter ohne Wertzuweisung Listing 3.4 Setzen eines Tabellenrahmens

Achtung

3.1.4 Strukturierung und Gestaltung mit HTML Obwohl HTML über die Zeit zahlreiche Gestaltungsmöglichkeiten für eine Webseite erworben und die Webdesigner diese in der Vergangenheit auch exzessiv ausgelebt haben, versucht man seit Jahren, möglichst alle Layoutfragen einer Webseite nicht mehr mit (X)HTML zu lösen. Stattdessen wird das Layout vollkommen in – möglichst externe – Style Sheets (Formatvorlagen) ausgelagert. Dies erleichtert auch massiv die Veränderung der Seite per JavaScript. (X)HTML wird nur noch zu Strukturierung einer Webseite verwendet. Das beginnt mit dem Grundgerüst samt vorangestelltem Prolog (wenn nötig) und setzt sich fort über die eigentliche Webseite im Inneren des -Tags. Dieser Schritt ist ein Teil der Umwandlung des WWW in ein semantisches Web, in dem die reinen Inhalte stark formalisiert und damit maschinenlesbar werden. Gerade HTML5 forciert diese Entwicklung.

59

Vorbereitende Basics

Kapitel 3

Info

Unter dem Begriff Semantik versteht man die Lehre von der Bedeutung von Zeichen (Wörter, Phrasen, Token oder Symbole).

3.1.5 Das Grundgerüst einer Webseite Sie werden das Grundgerüst einer Webseite kennen, nehme ich an. Dennoch sollen hier kurz ein paar Ausführungen notiert werden. Ein typisches, vollständiges HTML-Grundgerüst einer Webseite sieht so aus (HTML 4.01 – Strict): Listing 3.5 Das Schema eines HTML-Grundgerüsts

... Meta-Informationen ... sichtbarer Bereich der Webseite

In dem Kopfbereich der Seite werden Metainformationen zu der Webseite wie der Titel, der Zeichensatz, der Autor, Schlüsselwörter für Suchmaschinen, eine Beschreibung für Suchmaschinen oder ähnliche Informationen untergebracht. Im Körper der Webseite werden alle in der Webseite anzuzeigenden Informationen samt formatierender Tags notiert. In der Praxis hat es sich eingebürgert, dass man im Fall von HTML oft auf die vorangestellte DOCTYPE-Anweisung zur Angabe der HTML-Version verzichtet. Und – wie wir oben gesehen haben – auch auf andere Bestandteile des Grundgerüsts, weil ja die Browser die Fehler automatisch korrigieren. Dies gilt nicht im Fall von XHTML. Hier sieht ein korrektes Grundgerüst (XHTML 1.0 – Strict) wie folgt aus (es muss für die strenge Konformität zu XHTML auch immer diese Form haben, wobei aber in der Praxis oft auf die erste Zeile – die sogenannte XML-Deklaration – verzichtet wird): Listing 3.6 Das Schema eines XHTML-Grundgerüsts

...

Sie erkennen eine andere DOCTYPE-Deklaration und zudem muss das Wurzelelement html einem sogenannten Namensraum zugeordnet werden. In HTML5 geht man nun einen Mittelweg zwischen diesen beiden Varianten. Hier beginnt ein Grundgerüst so:

60

Der Aufbau von (X)HTML-Dateien ...

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

Listing 3.7 Der Beginn eines XHTML-Grundgerüsts

Die XML-Deklaration fehlt, aber die oben notierte – vereinfachte – DOCTYPEAnweisung wird grundsätzlich notiert. Die Dokumenttypangabe in HTML5Dokumenten soll Browsern das Verarbeiten des Quelltextes im standardkonformen Modus nach der HTML5-Spezifikation ermöglichen. Die meisten modernen Browser unterstützen das auch.

3.1.6 Der Header Der Kopfbereichr einer Webseite ist der Abschnitt einer Webseite, der im Anzeigebereich des Browsers nicht angezeigt wird. Dennoch ist der Header sehr wichtig, denn er enthält Metainformationen über die Webseite. Innerhalb des Kopfbereichs einer Webseite können diverse Tags untergebracht werden, zum Beispiel Hintergrundinformationen über das Dokument wie das Erstellungsdatum oder der verwendete Zeichensatz. Diese Metadaten werden dem Betrachter einer Seite nicht direkt angezeigt, stehen aber auswertenden Programmen wie Suchmaschinen oder anderen Dokumentationstools zur Verfügung. Daneben gibt es Aktionen wie eine Weiterleitung einer Seite, die über Metainformationen ausgelöst werden. Innerhalb eines Headers können beliebig viele -Tags verwendet werden. Hauptsächlich finden Sie Tags in Verbindung mit den Attributen name und content. Diese beiden Informationen bilden zusammen ein Wertepaar, das auch nur in der Kombination Sinn macht. Eine wichtige Anwendung von Metainformationen ist die Beeinflussung der HTTP-Headerinformationen einer Anfrage des Browsers. Attribut

Beschreibung

http-equiv

Simulation von HTTP-Headerinformationen

name

Der Name der Metainformation. Dieses Attribut identifiziert einen Eigenschaftsnamen.

content

Die mit dem Attribut name assoziierte Information, die dieses Attribut genauer spezifiziert.

Tabelle 3.1 Attribute des -Tags zu Simulation von HTTPHeaderinformationen

HTTP-Headerinformationen in Zusammenhang mit dem http-equiv-Attribut können für diverse Zwecke verwendet werden. Wenn Dokumente über HTTP verschickt werden, können damit verschiedene Aktionen beeinflusst werden, die in einigen Fällen an echte Programmierung erinnern und sich durchaus auch mit JavaScript programmieren lassen2. Über das Attribut http-equiv kann auch die Zeichenkodierung eines HTML-Dokuments festgelegt werden. Das nachfolgende Beispiel spezifiziert die Zeichenkodierung eines HTMLDokuments nach der Norm ISO-8859-5, wie sie in Westeuropa üblich ist:

Listing 3.8 Festlegung der Zeichenkodierung einer Webseite

2 Etwa die automatische Weiterleitung auf eine andere Webseite.

61

Vorbereitende Basics

Kapitel 3

Tipp Listing 3.9 Festlegung der Zeichenkodierung einer Webseite als UTF-8

Man sollte den Zeichensatz von Webseiten und allen integrierten Klartextressourcen (etwa Skript) als UTF-8 kodieren, wenn eine internationale Verwendung zu erwarten ist. Also wie folgt:

Damit vermeidet man die falsche Darstellung von Sonderzeichen sowie Umlauten. Dann sollte aber auch auf jeden Fall das Textdatei-Encoding (die Kodierung) der Datei auf UTF-8 eingestellt werden. In jedem Fall sollten das Textdatei-Encoding und der verwendete Zeichensatz zueinander passen (also identisch sein)3. Sie vermeiden so sehr viele Probleme in der Darstellung von Sonderzeichen sowie Umlauten. Das Textdatei-Encoding können Sie in jedem besseren Editor einstellen. In Aptana machen Sie das entweder global für ein Webprojekt über die Projekteigenschaften (PROJECT PROPERTIES RESOURCE) oder individuell für eine HTML-Datei über das Kontextmenü und dann den Befehl PROPERTIES RESOURCE. In Notepad++ legen Sie das Textdatei-Encoding explizit über den Befehl KODIERUNG im Menü fest. HTML5 vereinfacht übrigens vielfach auch die Meta-Angaben im Header. So könnte in HTML5 die Festlegung des Zeichensatzes gehen:

Listing 3.10 Die Festlegung des Zeichensatzes mit HTML5



Wenn Sie JavaScripts in Ihre Webseiten einbinden, können Sie auch da das Attribut charset verwenden (beim Element script). Das ist allerdings nur dann sinnvoll, wenn sich die Textkodierung in der Webseite selbst und die Kodierung im Skript unterscheiden – und das sollten Sie grundsätzlich vermeiden4.

Eine andere interessante Anwendung des http-equiv-Attributs ist die automatische Umleitung bzw. Weiterleitung eines Besuchers auf eine andere Webseite. Wenn der Besucher den URL einer Webseite im Webbrowser eingibt, wird er nach einer gewissen Zeitspanne auf eine andere Webseite weitergeleitet. Dazu dient das refresh-Attribut. Dessen Wert enthält als ersten Eintrag die Wartezeit (in Sekunden) und anschließend – durch Semikolon abgetrennt – das Ziel der Umleitung in Form eines URL. Beispiel (die vollständige Datei finden Sie unter kap3_2.html auf der ergänzenden Webseite zum Buch):34 Listing 3.11 Automatische Weiterleitung

Achtung



Bei diesem Beispiel wird ein Besucher nach einer Zeitspanne von drei Sekunden an den URL http://rjs.de weitergeleitet. Ganz alte Browser unterstützen die Weiterleitung von Seiten auf diese Art und Weise nicht. Zwar sollten solche Browser mittlerweile ausgestorben sein, aber auch in einigen neueren Browsern kann ein Anwender die automatische Weiterleitung deaktivieren. Deshalb sollte auf jeden Fall auf einer Seite auch die Verzweigung per Hyperlink vorgesehen sein.

3 Es handelt sich hier quasi um eine "interne" und eine "externe" Angabe des verwendeten Zeichensatzes einer HTML-Datei. Indem Sie eben global auf UTF-8 setzen. 4 Indem Sie eben global auf UTF-8 setzen.

62

XML-Grundlagen

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

3.1.7 Der Körper von Webseiten Die Bedeutung von HTML kann man bei modernen Seiten auf drei wesentliche Aufgaben reduzieren: Verknüpfung von Ressourcen Struktur und Semantik festlegen Interaktion Sie sehen, dass explizit Layoutaufgaben in der Aufzählung fehlen.

3.2

XML-Grundlagen

XML (Extensible Markup Language = erweiterbare Auszeichnungssprache) hat Bedeutung im allgemeinen Datenaustausch, aber auch im Rahmen des WWW. Jeder moderne Browser kann direkt XML-Daten anzeigen. Wenn Sie die XML-Daten dann auch noch mit Style Sheets formatieren, kann XML wie gewöhnliches HTML zum Aufbau einer Webseite verwendet werden (obgleich dies beileibe nicht die Hauptaufgabe von XML darstellt und in der Praxis so kaum gemacht wird). Ebenso ist XML die Basis von XHTML. Und aus Sicht von JavaScript hat XML aus einem weiteren Grund Bedeutung – AJAX. Die ausgeschriebene Version von AJAX ist Asynchronus JavaScript and XML. Wie dies zeigt, stellen neben JavaScript XML sowie damit verbundene Techniken wesentliche Bestandteile des Umfelds dar. Dabei kann XML auf dem Server zum Bereitstellen einer Antwort eine Rolle spielen, aber Sie können auch auf Seiten des Clients damit umgehen. Und nicht nur das – auch Webseiten aus reinem (X)HTML können als baumartige Dokumente aufgefasst werden (im Rahmen des DOM-Konzepts) und haben dann eine hohe Ähnlichkeit mit XML-Dokumenten. XML beschreibt erst einmal nur einen plattformneutralen Klartextstandard auf Unicode-Basis zur Erstellung maschinen- und menschenlesbarer Dokumente – wie HTML eine Auszeichnungssprache (Markup Language) ist, um über die Textinformation hinaus eine Struktur der Information zu bieten. XML-Dokumente liegen dabei wie gesagt immer in Form einer Baumstruktur vor. Auf diesem Baum ist eine Navigation zu den einzelnen Zweigen des Baums möglich. Die in einem Dokument enthaltenen Informationen werden dazu durch frei wählbare Tags strukturiert, die wie in HTML auch unter XML in spitze Klammern notiert werden. Im Gegensatz zu HTML, das über eine solche Semantik verfügt und neben jedem Tag auch dessen Bedeutung beschreibt, besteht XML lediglich aus einer Beschreibung der Syntax für Elemente und Strukturen. Damit ist XML freilich beliebig erweiterbar. Die XML-Spezifikation beschreibt lediglich, nach welchen Regeln Sie Elemente zu definieren haben. Die Festlegung der Elemente machen Sie selbst. Daher kann ein Leser oder Parser (zum Beispiel ein Webbrowser) die Bedeutung eines Elements aber auch nicht aus dem Kontext oder einer vorgegebenen Liste erschließen. Für einen konkreten Anwendungsfall (die Interpretation eines XML-Dokuments) müssen sämtliche relevanten Details spezifiziert

63

Kapitel 3

Vorbereitende Basics

werden. Dies betrifft insbesondere die Festlegung der Strukturelemente und ihre Anordnung innerhalb des Dokumentenbaums. Im Gegensatz zu HTML ist XML syntaktisch eine sehr strenge Sprache5, bei der es kein Prinzip der Fehlertoleranz gibt. Die XML-Spezifikation ist streng formal und lässt keine Ausnahmen und unklaren Strukturen zu. Dadurch ist XML jedoch einfach und automatisiert zu validieren. XML beschreibt nur wenige einfache, aber eben sehr strenge und absolut eindeutige Regeln, nach denen ein Dokument zusammengesetzt sein kann.

3.2.1 XML-Elemente Sogenannte Elemente bilden die elementaren Bausteine jedes XML-Dokuments. Diese können – sofern sie nicht eingeschränkt werden – selbst Unterelemente enthalten. Elemente selbst sind so aufgebaut, wie man es im Wesentlichen von HTML oder genauer XHTML in Form von Tags kennt. Es gibt ein Anfangs-Tag, das beispielsweise so aussieht: Listing 3.12 Ein Anfangs-Tag eines XML-Elements

Listing 3.13 Ein leeres XML-Element

Listing 3.14 Eine alternative Schreibweise für ein leeres XML-Element

Achtung



Im Inneren des Elements kann – sofern nicht besondere Regeln vorgegeben sind – beliebiger Inhalt notiert werden. Das können weitere Elemente oder Text sein. Auch gemischte Formen sind erlaubt. Eventuell im AnfangsTag notierte Attribute werden auf keinen Fall im Ende-Tag wiederholt. Das Anfangs-Tag muss in XML immer mit einem Ende-Tag abgeschlossen werden, das hinter einem Slash den Bezeichner wiederholt – es sei denn, ein Tag wird ausdrücklich als leeres Element gekennzeichnet. Solche leeren Elemente werden meist in Verbindung mit Attributen verwendet und wie folgt gekennzeichnet:

Zwischen dem Slash und dem Bezeichner darf ein Leerzeichen notiert werden. Diese Schreibweise wird sogar vom W3C empfohlen. Alternativ geht auch diese Form:

Bei der zweiten Schreibweise darf nicht einmal ein Leerzeichen oder ein anderer Whitespace wie ein Zeilenumbruch in dem Container notiert werden. Leerraum wird in XML als echter Inhalt angesehen (auch wenn man festlegen kann, dass ein XML-Parser Leerraum ignorieren soll).

Der Name eines XML-Elements muss mit einem Buchstaben, dem Unterstrich oder einem Doppelpunkt6 beginnen und darf danach aus beliebigen Buch5 Was bereits bei der Besprechung von XHTML deutlich geworden sein sollte. 6 Beim Doppelpunkt als erstes Zeichen machen allerdings einige XML-Tools beziehungsweise XML-Parser Probleme. Sie sollten deshalb zur Sicherheit darauf verzichten, den Doppelpunkt als erstes Zeichen zu nehmen.

64

XML-Grundlagen

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

staben, Zahlen, Punkten, Doppelpunkten, Bindestrichen und Unterstrichen bestehen. Ein Bezeichner darf jedoch nicht mit xml beginnen. Dieser Token hat in XML eine spezifische Bedeutung, wenn er am Anfang eines Elements notiert wird.

3.2.2 Die Syntax eines XML-Dokuments Ein XML-Dokument muss wenige, aber strenge syntaktische Regeln einhalten. Wenn ein Dokument diese Regeln einhält, nennt man es wohlgeformt! Entweder ein Dokument ist wohlgeformt oder aber es ist kein XML-Dokument.

Info Schauen wir uns die Regeln an, die ein XML-Dokument einhalten muss. Die Reihenfolge der Regeln ist dabei willkürlich. Unicode XML-Dokumente bestehen aus Unicode-Zeichen. Allerdings können Sie bei der Erstellung Ihres XML-Dokuments in einem Editor ANSI-Code speichern. Dann interpretiert der Parser das als Unicode. XML ist casesensitive In XML wird grundsätzlich zwischen Groß- und Kleinschreibung streng unterschieden. Ein Prolog ist zwingend Ein XML-Dokument beginnt immer mit einem sogenannten Prolog. Der Prolog muss am Beginn eines XML-Dokuments stehen und sieht derzeit in der einfachsten Form so aus:

Diese Syntax bezeichnet eine XML-Deklaration, die mit dem reservierten Token version die XML-Version angibt und zwingend mit dem ersten Zeichen eines XML-Dokuments zu beginnen hat. Es ist nicht einmal ein Leerzeichen zur Einrückung des Prologs gestattet, obwohl sich da einige interpretierende Tools vorschriftswidrig tolerant verhalten.

Listing 3.15 Die einfachste Form eines XML-Prologs

Achtung

Eindeutigkeit des Wurzelelements Ein XML-Dokument darf nur genau ein Wurzelelement (auch Root-Tag oder Dokumentelement genannt) besitzen und so ein Wurzelelement muss auch auf jeden Fall vorhanden sein. Es folgt, abgesehen von Kommentaren, unmittelbar dem Prolog.

65

Vorbereitende Basics

Kapitel 3

Saubere Verschachtelung aller Elemente Elemente müssen sauber verschachtelt werde. Das bedeutet, zwei öffnende und einander verschachtelnde Tags müssen in umgekehrter Reihenfolge wieder geschlossen werden. Oder in der bereits erwähnten Sprachwahl – es gibt ein strenges Strukturmodell. Jedes Element hat ein Ende-Tag oder ein leeres Element In XML muss jedes Tag ein Ende-Tag haben oder aber als leeres Element notiert werden. Attribute haben immer einen Wert In XML können Sie wie in HTML Elemente mit Attributen genauer spezifizieren. Allerdings muss Attributen in XML immer ein Wert zugewiesen werden. Und der Attributwert muss zwingend in Anführungszeichen stehen. Ein XML-Element kann auch mehrere Attribute besitzen, die in beliebiger Reihenfolge zum Anfangs-Tag hinzugefügt und einfach durch Leerzeichen getrennt werden. Info

Es gibt in XML einige reservierte Attribute mit fester Bedeutung. Diese beginnen alle mit dem Token xml, gefolgt von einem Doppelpunkt.

Eine wohlgeformte XML-Datei könnte also so aussehen (kap3.xml): Listing 3.16 Eine wohlgeformte XML-Datei

01 02 03 04 AJAX-NET.de 05 http://www.ajax-net.de 06 Portal zu AJAX und dem Web 2.0 07 08 09 RJS EDV-KnowHow 10 http://rjs.de 11 Homepage des Autors 12 13 14 RJS-Blog 15 http://blog.rjs.de 16 Der Blog des Autors 17 18

3.2.3 Gültige XML-Dokumente Die minimale Forderung an ein XML-Dokument ist wie schon erwähnt die Wohlgeformtheit. Darüber hinaus kann man von einem XML-Dkoument die Gültigkeit fordern. Das kennen Sie auch schon von (X)HTML-Dokumenten. Dies bedeutet, einem XML-Dokument wird über die syntaktische Wohlgeformtheit hinaus eine Grammatik zugeordnet, die ein validierender Parser berücksichtigen kann. Diese Grammatik wird in Form von Informationen

66

HTML versus XHTML

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

abgelegt, die nicht zum Inhalt des XML-Dokuments zählen. Die Grammatik wird entweder in Form einer DTD (Document Type Definition)7 oder eines XML-Schematas formuliert.

3.3

HTML versus XHTML

Mit dem Wissen um HTML und XML im Rücken können wir HTML und XHTML noch mal gezielt vergleichen. HTML wurde ursprünglich auf Basis von SGML (Standard Generalized Markup Language – http://www.w3.org/ MarkUp/SGML/) entwickelt. XHTML ist die erneute Definition von HTML auf Basis von XML und muss dessen strenge Regeln einhalten. Damit wurde XHTML strenger und schlanker definiert. Seit Januar 2000 gibt es XHTML 1.0 und das entspricht im Kern einer nicht fehlertoleranten Version von HTML 4.018. Wir haben ja bereits an verschiedenen Stellen HTML und XHTML gegeneinander gestellt. Nachfolgend sollen noch einmal die entscheidenden Unterschiede zwischen HTML und XHTML angegeben werden, wobei viele der Details in diesem Kapitel schon erwähnt wurden und sich vor allen Dingen auch aus den Ausführungen zu XML ergeben: Eine Erweiterung von XHTML betrifft die erlaubten MIME-Typen9. Zu dem unter HTML üblichen MIME-Typ (Multipurpose Internet Mail Extensions) text/html gibt es für XHTML-Dokumente noch text/xml oder application/xml. MIME ist ein Internetstandard zur Spezifizierung von Dateitypen bei der Kommunikation zwischen einem Server und einem Browser. Sowohl der Server als auch der Browser kennen bestimmte Dateitypen. Beim Übertragen vom Server zum Browser wird über das HTTP-Protokoll der MIME-Typ mit übertragen. Aufgrund einer Liste von MIME-Typen kann der Browser bzw. Server eine Datei eines bekannten Typs automatisch korrekt behandeln. Werden unbekannte Dateitypen geladen, kann das Programm nicht direkt damit umgehen, sondern muss die Datei speichern oder über zusätzliche Informationsquellen (etwa im Fall des Browsers über einen Benutzerdialog) nach der Behandlungsweise forschen. Die Verwendung von MIME-Typen umgeht zugleich das Problem, dass viele Dateierweiterungen von mehreren Programmen bearbeitet werden können (etwa .bmp, was unter Windows von zahlreichen Grafikprogrammen bearbeitet werden kann). Über MIME-Typen kann man auch eindeutig das bzw. die zu verwendende(n) Programm(e) zur Verarbeitung angeben. MIME-Typen werden nach folgendem Schema angegeben: Hauptkategorie/Unterkategorie

Info

Listing 3.17 Das Schema einer MIME-Spezifikation

7 Das ist der historisch ältere Weg. 8 XHTML lässt sich auf Grund der strengen syntaktischen Regeln besser maschinell auswerten als es bei HTML-Dokumenten möglich ist. Das bedeutet, dass z.B. Suchmaschinen XHTML-Dokumente besser analysieren und katalogisieren können. Auch mobile Endgeräte mit kleinen Bildschirmen können solche Dokumente besser skalieren. 9 Was auch für HTML5 von Interesse ist.

67

Vorbereitende Basics

Kapitel 3

Info

Hauptkategorien sind etwa text, image oder audio. Unterkategorien von text sind beispielsweise plain (eine reine Textdatei), javascript (beim Einbinden von JavaScripts) oder html (eine HTML-Datei). Unterkategorien von image sind beispielsweise gif oder jpeg.

Jede XHTML-Datei fordert als XML-Dokument als erste Anweisung eine XML-Deklaration. Aber wie erwähnt, verzichtet man darauf in der Praxis oft. Auch wenn das im Sinn von XML verboten ist und im Grunde das Fehlen der XML-Deklaration bereits die Wohlgeformtheit verletzt. Das einleitende -Tag (das Wurzelelement) besitzt in HTML normalerweise keine Attribute, während man in XHTML einen Namensraum angibt10. Etwa so: . XHTML erzwingt ein strengeres Einhalten des (X)HTML-Grundgerüsts (inklusive Header und Body). Das Strukturmodell ist allgemein streng. In HTML spielt die Groß- und Kleinschreibung grundsätzlich keine Rolle. XHTML unterscheidet strikt zwischen der Groß- und Kleinschreibung. In XHTML müssen alle Elemente und Attribute kleingeschrieben werden. HTML-Elemente ohne Abschluss-Tag müssen in XHTML mit der Zeichenfolge /> am Ende gekennzeichnet werden. Vor dem Schrägstrich sollte ein Leerzeichen stehen (etwa
). Alternativ ist die Notation von einem Anfangs- und End-Tag ohne weitere dazwischenliegende Zeichen, auch kein Leerzeichen, möglich. Parameter ohne Wertzuweisung gibt es in XHTML nicht. HTML und XHTML unterscheiden sich bezüglich der Behandlung von Skript- und Style-Containern, was wir hier nicht weiter ausführen wollen. Wie Sie sehen, sind die Unterschiede bezüglich der Optik und dem Verhalten einer Webseite bei Beachtung der XHTML-Regeln letztendlich nicht zu bemerken. In Anbetracht dessen, dass folgende Versionen von XHTML diese abstrakte und auf Hintergrundprozesse im Web ausgerichtete Strenge forciert und Elemente sowie Strukturen eingeführt haben, die kaum ein designorientierter Webseitenersteller verstehen bzw. akzeptieren konnte, wundert es nicht, dass XHTML gescheitert ist und mit dem Stand XHTML 2.0 eingefroren wurde, wobei ich dennoch empfehle, die Regeln von XHTML 1.0 so weit wie möglich einzuhalten (auch in HTML5). Denn die Regeln von XHTML 1.0 sind gerade in Hinsicht auf die Programmierung von Webseiten mit JavaScript und die Gestaltung mit CSS sehr zu empfehlen. Aber die Zukunft gehört HTML5. Bevor wir dazu kommen, befassen wir uns kurz mit dem (!) zentralen Begriff aller dynamischen Webseiten – dem DOM-Konzept.

10 Siehe dazu auch die Ausführungen zum Grundgerüst.

68

Ein erster Blick auf das DOM-Konzept

3.4

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

Ein erster Blick auf das DOM-Konzept

An der Stelle werfen wir also einen ganz kurzen, ersten Blick auf das DOMKonzept (Document Object Model)11. In diesem Konzept wird eine (X)HTMLSeite (oder allgemein ein baumartig aufgebautes Dokument – z.B. auch ein XML-Dokument) nicht als statisch aufgebaute, fertige und nicht unterscheidbare Einheit, sondern als differenzierbare Struktur betrachtet, deren einzelne Bestandteile Programmen und Skripten dynamisch zugänglich sind. Dieser Ansatz ermöglicht die individuelle Behandlung von Bestandteilen einer Webseite auch dann, wenn die Webseite bereits in den Browser geladen ist. Und zwar eine Behandlung, die weit über die einfache Interpretation durch den Browser beim Laden eines Dokuments von oben nach unten hinausgeht. Das DOM-Konzept beinhaltet verschiedene Teilaspekte. Es veranlasst beispielsweise einen Browser, eine (X)HTML-Seite zwar wie eine gewöhnliche Textdatei zu lesen und entsprechende (X)HTML-Anweisungen auszuführen. Darüber hinaus wird der Browser jedoch beim Laden der Webseite alle ihm im Rahmen des Konzepts bekannten und einzeln identifizierbaren Elemente einer Webseite bezüglich ihres Typs, ihrer relevanten Eigenschaften und ihrer Position innerhalb der Webseite indizieren. Dies ist eine Art Baum im Hauptspeicher des Rechners, der beim Laden der Webseite aufgebaut und beim Verlassen der Seite wieder gelöscht wird. Ähnliche Elemente werden dabei bei der Indizierung vom Browser gemeinsam in einem Feld verwaltet. Auf diese Weise hat der Browser nach dem Laden der Webseite genaue Kenntnis über alle relevanten Daten sämtlicher eigenständig für ihn ansprechbarer Elemente in der Webseite. Welche das jedoch sind und was er damit anstellen kann, das kann sich je nach Browser erheblich unterscheiden. Insbesondere spielt hier das Prinzip der Fehlertoleranz eine gravierende Rolle, wenn ein Browser automatisch gewisse Strukturen der Webseite ergänzt oder weglässt. Denn je nachdem, wie das ein Browser macht, wird der DOM-Baum möglicherweise unterschiedlich aussehen. Und das macht einen zuverlässigen Zugriff sehr schwer. Das DOM-Konzept hat für dynamische Webseiten erst die Grundlage gelegt. Denn jedes ansprechbare Element (etwa ein bestimmtes (X)HTML-Tag) kann bei Bedarf auch während der Lebenszeit der Webseite aktualisiert werden, etwa wenn mittels eines Skripts die Position eines Elements in der Webseite verändert oder über Style Sheets nach dem vollständigen Laden der Webseite das Layout eines Elements dynamisch verändert wird. Die Repräsentation von allen Elementen in einem Konzept wie DOM bedeutet, dass diese Elemente sich dort mit allen offengelegten Eigenschaften und Methoden verwenden lassen. Greifen Sie also auf ein Objekt im DOM-Baum zu, können Sie dessen Eigenschaften (Breite, Höhe, Farbe, ...) auslesen und oft auch verändern. Oder Sie nutzen eine Methode, um eine aktive Tätigkeit auszuüben. Das ist die Grundlage aller dynamischen Aktionen in einer modernen Webapplikation.

11 Wir brauchen es in JavaScript unbedingt, aber auch um zu verstehen, was HTML5 wirklich an Neuerungen bringt, sollte die Idee zumindest bekannt sein.

69

Kapitel 3

Vorbereitende Basics

3.5

HTML5 und DOM5

Im Laufe des Kapitels kamen wir ja bereits immer wieder auf HTML5 zu sprechen und wir werden auch – insbesondere bei den erweiterten JavaScriptTechniken – noch intensiv mit HTML5 arbeiten. Und Sie kennen mittlerweile schon einige Aspekte dessen, was als Zukunft von HTML gesehen wird. In diesem Abschnitt vertiefen wir in einer ersten Phase (soweit wir ohne Programmierung auskommen) diese Ausführungen. Insbesondere möchte ich gleich am Anfang eine persönliche und subjektive12 Wertung von HTML5 voranstellen. Ich verfolge seit 1995 die Entwicklung von HTML und wie damit Webseiten erstellt werden. Während sich nach meinem Verständnis die HTML-Versionen 2 bis 4 in ihrer Zielrichtung ähneln (mehr Features zur Darstellung und Funktionalität der Webseite im Browser), verstehe ich HTML5 als etwas anderes. Ich würde die Konzeption und die Idee von HTML5 mit der Version 1 gleichsetzen, die meines Erachtens einfach und genial war, während sich die Nachfolgeversionen von HTML in die falsche Richtung (Design und Gimmicks – oft mit proprietären Spezialitäten) entwickelt haben. Es geht also zum Teil back to the roots. Viele wichtige Neuerungen von HTML5 wird man nun entweder gar nicht in der Webseite sehen oder erst in einigen Jahren, wenn sich neue Browsergenerationen auf eine einheitliche optische Unterstützung geeinigt haben. Den Nutzen von HTML5 zu erkennen, erfordert deshalb vom Webseitenersteller ein gewisses abstraktes Denken. Webseitenersteller, die rein vom Design her kommen, sind meines Erachtens von vielen HTML5-Neuerungen stark gefordert bis überfordert. Webseitenersteller mit Programmierhintergrund oder XML-Kenntnissen hingegen werden den Nutzen leichter erfassen. Insgesamt wird es damit nicht mehr so leicht, HTML5 richtig zu lernen und zu verstehen, wie es etwa die Versionen 1 bis 4 auch Laien ermöglichten. Das Niveau steigt, wenn man insbesondere die Neuerungen und Konzepte von HTML5 verstehen will. Das stellt letztendlich auch kein echtes Problem dar, denn wer die Neuerungen nicht versteht und/oder verwendet, nutzt halt nur die Elemente, die es auch in HTML4 schon gibt (möglichst aber ohne die Elemente und Attribute, die als veraltet angesehen werden). Doch zurück zur objektiven Betrachtungsweise: HTML5, dessen erste Entwürfe bereits im Jahr 2004 vorgestellt wurden, ist der offizielle, praxisorientierte, modulare Nachfolger von HTML4, aber auch XHTML 1.0, wobei dessen direkter Nachfolger oft XHTML5 genannt wird13. Zum Zeitpunkt der Bucherstellung befindet sich die Sprache noch in der Entwicklung. Allerdings gibt es bereits sehr ausgereifte Entwürfe, die sich in zentralen Aspekten wohl nicht mehr groß ändern werden und teilweise auch schon in neuen Browsern unterstützt werden. Die zentralen Neuerungen von HTML5 gegenüber den Vorgängern liegen in den Bereichen von dynamischen 2D- und irgendwann auch 3D-Grafiken, der nativen Video- und Audioverarbeitung, 12 Ich nehme bewusst in Kauf, dass es sicher andere Sichtweisen gibt. 13 Was wir aber in der Regel nicht trennen werden.

70

HTML5 und DOM5

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

dem lokalen Speichern von Informationen, dem Verlagern von Aufgaben in Hintergrundprozesse, der nativen Spezifikation von Formulareingaben samt Bereitstellung neuer Benutzereingabeelemente wie Datums- oder Farbkomponenten, Fortschrittsanzeigen oder Menüs und Semantik14 und Microdaten15. Des Weiteren soll HTML5 die Wohlgeformtheit (Fehlerfreiheit) von Webseiten vorantreiben, ohne so rigide wie XHTML zu sein. Nur so eine Wohlgeformtheit kann die konsistente Erweiterung der DOM-Schnittstelle zuverlässig gewährleisten, was sich letztendlich hinter den meisten Erweiterungen verbirgt16. Eine bereits genannte zwingende Regel in XHTML ist, dass es keine Attribute ohne Wertzuweisung geben darf. das gilt auch bei Attributen, denen nur zwei Werte zugewiesen werden können (boolesche Werte – Wahrheitswerte), oder bei Attributen, denen man einfach einen Vorgabewert zuordnen kann, wenn das Attribut ohne Wertzuweisung gesetzt wird (etwa border bei Tabellen). Gerade bei booleschen Attributen muss man in XHTML manchmal solche seltsamen Konstruktionen notieren wie controls="controls". Sie weisen einem Attribut also dessen Namen als Wert zu. Das hat sicher massiv zur Ablehnung von XHTML beigetragen. Denn in reinem HTML hat mal solche Attribute als Schalter verwendet. Ist ein Attribut vorhanden, wird der Wert als wahr betrachtet (in unserem kleinen Beispiel würden also Bedienelemente eines Mediaplayers angezeigt). Fehlt das Attribut, wird der Wert als falsch gesehen (in unserem kleinen Beispiel würden also Bedienelemente eines Mediaplayers nicht angezeigt). Das ist einfach und bequem und wurde von den Webseitenerstellern eindeutig bevorzugt. HTML5 geht nun auf diese Wünsche ein und gestattet wieder die Verwendung von Attributen ohne Wertzuweisung, wenn so eine Situation vorliegt.

Achtung

Wenn man sich die weiteren Schlagwörter auf der Agenda für HTML5 ansieht, fallen Sicherheit17, Konsistenz18, Vereinfachung, Zugänglichkeit (in Hinsicht auf Barrierefreiheit) und Universalität19 auf. Und man sollte im Auge behalten, dass die nativen Implementierungen einiger neuer Features von HTML5 die Performance verschiedener Vorgänge (etwa die Wiedergabe von Videos oder der Aufbau komplexer Interaktionskomponenten) beschleunigen kann. Gerade im Bereich der mobilen Anwendungen wird damit weiter die Übertragung von Web-Technologie stark vereinfacht und verbessert. 14 Was den (!) Schwerpunkt der Neuerungen von HTML5 darstellt. Insbesondere möchte ich noch einmal betonen, dass damit die optischen Auswirkungen vieler Neuerungen von HTML5 eher gering bzw. nebensächlich sind. 15 Wobei das Thema zum Zeitpunkt der Bucherstellung wieder aufgegeben wurde. 16 Aber für den aktuellen Wissenstand im Moment noch zu weit führt. 17 Neue Funktionen müssen Sicherheitsaspekte berücksichtigen. 18 Unter HTML5 sollen XML, XHTML und HTML harmonisch verwendet werden können und einheitlich im DOM abgebildet werden. 19 Keine Abweichungen auf unterschiedlichsten Endgeräten und saubere Darstellung von Inhalt in allen relevanten Sprachen der Welt.

71

Vorbereitende Basics

Kapitel 3

Info

Es ist im Moment zu beobachten, dass gerade die Browser für mobile Endgeräte bei der Unterstützung von HTML5, aber auch CSS3 den Browsern im Desktop-Umfeld meist voraus sind. Sie werden vermutlich viel eher bei mobilen Web-Apps zuverlässig auf HTML5 und CSS3 setzen können als im klassischen Web.

Bemerkenswert ist auch, dass HTML in Zukunft ein sogenannter Living Standard werden soll. Das bedeutet also eine Spezifikation der Sprache, die einer ständigen Korrektur und Erweiterung unterliegt. Mit anderen Worten – in HTML sollen in Zukunft auch neue Elemente und Attribute hinzukommen können, ohne dass dies eine neue Version erzwingt. Dessen ungeachtet gibt es aber andere Bestrebungen innerhalb des W3C, irgendwann eine stabile Momentaufnahme der HTML-Spezifikation »einzufrieren« und diese unter dem Namen HTML5 zu publizieren. Das W3C geht davon aus, dass die vollständige HTML5-Spezifikation bis zum Jahr 201420 auf breiter Front unterstützt wird und damit zum offiziellen Standard im Web erklärt werden kann. Aber bereits zum Zeitpunkt der Bucherstellung hat HTML5 in vielen Bereichen faktisch einen fertigen Zustand erreicht, der auch in vielen modernen Browsern (teilweise) unterstützt wird. Von daher können Webentwickler schon gängige Features von HTML5 bereits mit Vorsicht (und Tests in allen relevanten Zielbrowsern) verwenden (was das W3C sogar empfiehlt).

Achtung

Trotz des zum Zeitpunkt der Bucherstellung nach diversen Quellen faktisch fertigen Zustands kommen unter dem Oberbegriff HTML5 immer noch neue Elemente bzw. Konzepte hinzu und andere fallen dafür weg. das ist aber nicht ganz so schlimm, wie es vielleicht erscheinen mag. Der besagte lebende Standard sieht solche Änderungen ja explizit vor und zwingt HTML5-kompatible Browser zu einem vernünftigen Umgang mit solchen Elementen und Konzepten.

3.5.1 Das neue Vokabular Die Elemente und Attribute von HTML5 bestehen im Kern aus dem Vokabular aller vorangehenden HTML-Spezifikationen. Grundlegend kann man sagen, dass praktisch alle Elemente aus HTML4 auch in HTML5 enthalten sind. HTML4 ist so gesehen eine Teilmenge von HTML5. Allerdings wurden auch explizit einige Elemente und Attribute entfernt oder – besser gesagt – meist als deprecated (missbilligt) eingestuft. Grob gesagt sind in HTML5 alle die Elemente und Attribute nicht mehr gewünscht, für deren Wirkung es in CSS Alternativen gibt, wenn man neutrale HTML-Elemente damit ver20 Zum Zeitpunkt der Bucherstellung steht gerade wieder eine HTML5-Spezifikation als Arbeits- und Vorentwurf zur Prüfung bereit. Aber bis die endgültige Verabschiedung durch sein soll, werden von einigen Kritikern (Pessimisten?) sogar erst die Jahre 2020 bis 2022 genannt – zumindest in Bezug auf die angeblich bisherige Entwicklungsgeschwindigkeit. Das steht voll im Widerspruch zu dem Hype, der gerade um HTML5 gemacht wird. Ich frage mich, ob Theorie, Praxis, Hype und Prognosen je in Einklang zu bringen sind?

72

HTML5 und DOM5

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

bindet, und solche Elemente, die schon lange im Web nicht mehr genommen werden sollen. Das sind im Wesentlichen Anweisungen, die das Layout betreffen (etwa zur Ausrichtung, den Farben oder der Schrift – z.B. acronym, center, oder font), aber auch veraltete Elemente wie frame und das noscript-Element in XHTML5. Dazu gibt es bei einigen Elementen eine geänderte Bedeutung, die sich aber in der Praxis respektive optischen Wirkung meist überhaupt nicht auswirkt. So wurde beispielsweise einigen, vormals nur der Darstellung dienenden Elementen (z.B. b, i, hr oder small) eine semantische und abwärtskompatible Bedeutung gegeben. Und die wirklich umdefinierten Elemente wie cite sind von geringer Bedeutung. Es ist zudem streng definiert, wie ein Browser mit diesen geänderten oder missbilligten Elementen umzugehen hat (was faktisch eine weitere Verwendung gestattet). Dadurch wird die Kompatibilität HTML5-kompatibler Browser zu bestehenden Webseiten sichergestellt. Auf der anderen Seite gibt es in HTML5 einige neue Konzepte, Elemente und Attribute, die zum Teil aus XHTML stammen, zum Teil im Umfeld von JavaScript respektive ECMAScript schon vorgestellt wurden, zum Teil aber auch ganz neu sind. Des Weiteren wurde in HTML5 ein klares Strukturmodell definiert. Es ist sauber festgelegt, wie Elemente ineinander verschachtelt werden dürfen. Das Modell ist stark an dem Strukturmodell von XHTML angelehnt. Aber auch hier gilt, dass in der Praxis HTML5-kompatible Browser weiterhin falsch verschachtelte Strukturen unterstützen werden. Die Neuerungen in HTML5 erfordern einige besondere Fähigkeiten von den neuen HTML-Parsern, die diesen Standard vollständig unterstützen sollen. Ein solcher Parser muss nicht nur das erlaubte Vokabular verstehen, sondern auch alle anderen Elemente, die in früheren Versionen von HTML und XHTML vorhanden waren (Rückwärtskompatibilität). Ebenso sollen auch proprietäre Elemente wie oder unterstützt werden. Und dann muss auch sauber mit neu hinzukommenden Elementen umgegangen werden, sonst könnte kein lebender Standard umgesetzt werden21. Neue Struktur- und Gruppierungselemente In HTML5 gibt es eine ganze Reihe von neuen strukturierenden Elementen. Die sprechend benannten Elemente section, nav, article, aside, hgroup, header und footer sollen eine bessere semantische Strukturierung einer Webseite22 ermöglichen, als es bisher rein auf Basis von div-Elementen

21 Hier zeigte sich beim Internet Explorer in der Vergangenheit immer ein großes Problem, denn er renderte unbekannte Elemente im DOM in leere Knoten und deren Inhalt als neue Kindknoten. Diese Information ist an der Stelle für Sie wahrscheinlich noch nicht sonderlich hilfreich, soll aber deutlich machen, dass der Umgang mit unbekannten Elementen in einer Webseite zu einem Problem wird, wenn ein Browser diese nicht standardisiert verfügbar macht. Und Sie sehen gleich ein praktisches Beispiel, das Ihnen das Problem verständlich machen wird. 22 Es handelt sich ausdrücklich nicht um eine optische Information.

73

Vorbereitende Basics

Kapitel 3

(oder aber Tabellen) möglich war. Denn die Elemente bezeichnen neben einer Struktur auch die Art ihres Inhalts. Zum Beispiel bezeichnet23 section nav

einen Abschnitt eines zusammengehörigen Textes,

enthält eine Navigation (etwa ein Menü),

mit aside wird ein Seitenbereich gekennzeichnet, hgroup

dient zur Gruppierung,

article

Info

bezeichnet einen Artikel,

header

einen Kopfbereich oder

footer

einen Fußbereich.

Nach den Plänen des W3C sollen diese neuen Elemente mittelfristig sogar DIV-Elemente und CSS-Klassen überflüssig machen. Allerdings halte ich das in den nächsten Jahren für nicht praktikabel, insbesondere in Hinsicht auf ältere Internet Explorer, die unbekannte Elemente so rendern, dass man sie mit CSS nicht direkt ansprechen kann. Das besprechen wir gleich. Solange es also noch Anwender gibt, die mit dem Internet Explorer 8 oder älter arbeiten, wird man nicht um DIV-Elemente und CSS-Klassen herumkommen.

Die Elemente können in einer Webseite beliebig oft vorkommen und selbst wieder alle – sinnvollen – klassischen sowie neuen HTML-Elemente enthalten, solange das neue Strukturmodell das nicht verbietet24. Und Sie sollten unbedingt beachten, dass es in keinster Weise vorgegeben ist, dass etwa ein footer-Element im Quellcode einer Webseite unterhalb eines header-Elements oder ein aside-Element auf der Seite zu stehen hat, obwohl die Bezeichner das vielleicht suggerieren. Da es sich um rein strukturelle Informationen handelt, gibt es kein »unterhalb« oder »oberhalb« im Sinne einer optischen Position. Hier wird ganz deutlich, dass eine designorientierte Denkweise in HTML5 oft fehl am Platz ist. Info

Angeblich ergab eine Untersuchung von Google über sehr viele bestehende Webseiten, dass bei der semantischen Strukturierung einer Webseite mit klassischen Elementen aus HTML4 die Namen der neu eingeführten Strukturierungselemente am häufigsten als Klassennamen für klassische Containerelemente wie div vergeben wurden. Deshalb hat man sich angeblich für diese Namen entschieden.

Einige dieser neuen Strukturelemente (section, nav, article und aside) binden ebenso eine logische Funktionalität an die Kombination mit den Überschriften h1 bis h6, wenn solche Elemente darin enthalten sind. Die Hierarchie der Überschriften wird dann nicht mehr nur allein anhand der Elemente bestimmt, sondern auch anhand von deren Position innerhalb der neuen Elemente. Wenn man etwa in einem Dokument direkt eine Überschrift 23 Sofern ein Webseitenersteller diese gedachte Semantik auch einhält. Es hindert nichts und niemand einen Webseitenersteller, in einen nav-Bereich keine Navigationsstruktur, sondern vielleicht einen Artikel zu schreiben. 24 Und wenn doch, dann verhält sich ein Browser meist sehr tolerant.

74

HTML5 und DOM5

0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110 0110 0110 0110 010 010 101

3

erster Ordnung verwendet und zusätzlich eine solche Überschrift in einem article-Element, so ist diese der direkt im Dokument notierten Überschrift untergeordnet. Soweit ist das meines Erachtens nachvollziehbar, aber die Unterordnung der verschachtelten Überschrift gilt selbst dann, wenn die nichtverschachtelte Überschrift niedrigerer Ordnung ist. Und das ist meines Erachtens für erfahrene Webprogrammierer sehr gewöhnungsbedürftig und in komplexeren Webseiten ohne geeignete Tools kaum noch zu erkennen. Schauen wir uns einmal ein vollständiges HTML5-Dokument an, dass die wichtigsten besprochenen Strukturelemente enthält (kap3_3.html): ... 07 08 09 Neue Strukturelemente in HTML5 10 11 12 Home 13 Zu meiner Webseite 14 15 16 17 18 19 Das Programm für den Vormittag