Webwriting-Magazin > So geht's
Keine Angst vor XHTMLMit etwas Umdenken zu großen Vorteilen
Nun haben wir uns alle mit Glück an HTML 4.01 gewöhnt - und jetzt sollen wir schon wieder umlernen. XML und XHTML stehen auf dem Programm, und mancher fürchtet, daß uns da wer ein X für ein U vormachen will.
Wenn man sich etwas näher damit beschäftigt, was eigentlich hinter dem großen "X" steht, sieht das alles schon nicht mehr so gefährlich aus. XML (Extended Markup Language) ist keine Sprache, mit der sich Webseitenbauer normalerweise befassen müssen. Genaugenommen ist XML überhaupt keine Sprache, sondern ein umfassendes Regelwerk zur Formulierung von Sprachen zur Datenstrukturierung. Wer nicht gerade webgestützte Warenwirtschaftssysteme entwickelt, wird wahrscheinlich nie damit in Berührung kommen. Und XHTML 1.0 ist nichts anderes als eine nach den Regeln von XML umformulierte Version von HTML 4.01. Da aber HTML und XML auf gemeinsame Vorfahren zurückgehen, mußte HTML dazu nicht völlig neu geschrieben werden. Auf den ersten Blick sieht ein XHTML-Dokument - von ein paar Pingelkeiten wie den zwingend vorgeschriebenen Schluß-Tags für alles und jedes einmal abgesehen - gerade so aus wie der HTML-Vorgänger auch.
Ein Blick hinter die Oberfläche
Womit sich sogleich die Frage stellt, wofür dann der ganze Aufwand, wenn sowieso alles beim Alten bleibt. Die Antwort ist hinter der Oberfläche zu suchen, wo sich eine ganze Menge getan hat. Um das in seiner ganzen Bedeutung zu verstehen, muß man aber doch noch einmal kurz und sehr stark vereinfachend auf XML eingehen. Als Regelwerk für Strukturierungssprachen erlaubt XML, beliebige Elemente zu definieren - also z.B. in einem Dokument nicht nur <titel> und <body> zu unterscheiden, sondern auch Elemente wie z.B. <name>, <adresse>, <telefon> einzuführen - alles, was in einem bestimmten Zusammenhang benötigt wird. Natürlich muß man dann auch irgendwo festlegen, was die in einem Dokument vorkommenden Elemente bedeuten und wie die Software damit umgehen soll - und dazu sind in XML die sogenannten "Document-Type-Definitions" (DTD) vorgesehen. Auch mit diesen DTDs wird der Nicht-Entwickler normalerweise nie in Berührung kommen - außer an einer einzigen gerne übersehenen Stelle: Ganz am Anfang jedes HTML-Dokumentes findet sich schon heute eine Zeile wie: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">. Sie sagt der Browsersoftware, nach welcher Document Type Definition sie das Dokument zu verarbeiten hat - und wo sie sie findet, sollte sie nicht bereits fest eingebaut sein.
Dieses Konzept verleiht XML seine große Flexibilität und daher
auch seine hohe Anziehungskraft für Entwickler auf den verschiedensten
Gebieten. Die DTDs beschreiben die Schnittstellen, über die
Dokumente der unterschiedlichsten Art in XML ihren gemeinsamen
Nenner finden. In der Theorie - die Praxis ist dann doch immer
wieder etwas hakeliger - können XML-basierte Anwendungen Datenbestände
und Dokumentenstrukturen jeder Art verarbeiten - wenn diese
Dokumente XML-konform sind und wenn eine geeignete DTD zur
Verfügung steht. Für Webseitenbauer steckt darin die erfreuliche
Nachricht, daß Seiten, die sie heute nach HTML 4.01 (oder
einer anderen Version von HTML) schreiben, auch in Zukunft
auf allen Browsern dargestellt werden, die eine entsprechende
DTD mitbringen. Daß die Browser trotzdem jede Menge Fehler
machen, steht auf einem anderen Blatt. Diese Fehler und Abweichungen
bleiben uns auch in Zukunft erhalten.
Alle reden mit allen
Im Prinzip gilt, daß Daten, die erst einmal in XML vorliegen,
verlustfrei per Software in jedes beliebige andere XML-konforme
Format umgewandelt werden können. Deshalb speichern moderne
Office-Programme ihre Dateien inzwischen in  XML-basierten
Formaten ab. XML erleichtert aber nicht nur die Konvertierung
von Textinformationen. Genausogut und vielleicht noch besser
eignet sich XML dazu, die Verbindung zwischen Registrierkasse
im Verkaufsraum, Lagern bei Händlern und Herstellern, Clearingstellen
von Kreditkartengesellschaften usw. zu optimieren - plötzlich
können alle mit allen. Tatsächlich sind Textinformationen
unter allen Datenarten wohl noch am wenigsten leicht per DTD
nach Belieben zu konvertieren, da stets ein "menschlicher
Faktor" zu berücksichtigen ist: Natürlich könnte man das Webwriting-Magazin
nach WAP konvertieren - aber wer wollte das lesen? Natürlich
könnte man die Konvertierung auch so steuern, daß z.B. nur
Überschriften und Vorspänne für WAP erfaßt werden - aber wie
formuliert man Überschriften, die sowohl dem Informationsbedürfnis
des Menschen am Normal-Monitor und der Platznot des WAP-Displays
genügen?
Einmal schreiben - überall sehen
Für Web-Writer besonders interessant ist die Möglichkeit,
XHTML-konforme Dokumente so auszuzeichnen, daß sie auf verschiedenen
Ausgabegeräten wie Monitor, Drucker, Lesemaschine oder Braille-Zeile
jeweils optimal dargestellt werden können. Dafür braucht man
sich nicht mit verschiedenen DTDs herumzuplagen, denn diese
Auszeichnungsfragen sind nicht Sache der Document Type Definition,
sondern des Stylesheets. CSS 2 hat schon einen sehr brauchbaren
Vorrat an solchen Auszeichnungsvarianten vorgesehen - leider
werden viele davon von den aktuellen Browsern heute noch nicht
berücksichtigt. Hier ist noch ein Wort zum Verhältnis von
DTD und Stylesheets angebracht. DTDs haben die Aufgabe, eine
Datenstruktur und ihre Elemente so zu beschreiben, daß die
Daten im Bezugsrahmen von XML weiterverarbeitet werden können.
Bei XHTML wird also durch die DTD festgelegt, daß es
in einem Dokumententyp Absätze <p>,
Tabellen <table>, Bereiche
<div> usw. geben soll. Wie
diese Elemente dargestellt werden sollen, wird durch die Stylesheets
beschrieben.
Wer für seine Daten Strukturelemente benötigt, die in XHTML nicht vorgesehen sind, muß in den saueren Apfel beißen, XML lernen und sich eigene DTDs schreiben. Wer mit den Elementen auskommt, die ihm bisher von HTML 4.01 und künftig von XHTML geboten werden, braucht sich mit XML nicht näher zu befassen. Aber wenn er die vorhandenen Elemente anders darstellen will, als es die sehr rudimentären eingebauten Styles vorsehen, hat dazu mit CSS (und im Rahmen von deren Umsetzung durch die Browserhersteller) reichhaltige Möglichkeiten, seine Styles selbst zu gestalten. In einem Satz: Mit CSS sollte sich jeder Webwriter intensiv vertraut machen - DTDs kann man demgegenüber getrost den Anwendungsentwicklern überlassen.
Nichts ist umsonst
Leider sind die Vorteile, die XHTML und CSS bieten, nicht umsonst zu haben. Man kann zwar bis auf weiteres seine Seiten so weiter bauen wie bisher, und es ist auch nicht zu befürchten, daß kommende Browsergenerationen heutige Seiten nicht mehr darstellen können. Aber wer die zusätzlichen Möglichkeiten nutzen will, muß notwendigerweise eine Menge dazu lernen und sich hier und da auch von liebgewordenen Angewohnheiten trennen.
In zwei Bereichen ist Umdenken oder zumindest verstärktes Nachdenken angesagt: Bei der Arbeit mit Tabellen, und beim Einsatz von Frames.
Selbstverständlich werden in XHTML Tabellen weiterhin zur
Verfügung stehen, sogar mit erweiterter Funktionalität für
datenbanknahe Anwendungsfelder. Aber: Tabellen sind, Überraschung,
dazu gedacht, Tabellen wiederzugeben - ihre Verwendung als
Hilfsmittel zur Positionierung von Grafiken und Textelementen
ist eine kreative, aber letztlich eher mißbräuchliche Umnutzung
des Konzeptes. HTML stellt ursprünglich nur äußerst unzureichende
Mittel zur Positionierung bereit. Dieser Mangel läßt sich
mit ineinander verschachtelten Tabellen ausgleichen - womit
man sich freilich eine Menge Nachteile einhandelt. Die Browser
haben so ihre Eigenheiten im Umgang mit Tabellen, und vor
allem: Tabellenpositionierte Inhalte erscheinen in Textbrowsern
und bei Lesegeräten meistens an den Stellen, an denen man
sie am wenigsten brauchen kann. Um den Inhalt auch für Anwender
solcher Geräte zugänglich zu machen, muß man vielfach eine
eigene Textversion erstellen und anbieten. (X)HTML und CSS
enthalten reichhaltige Möglichkeiten zur direkten Positionierung
von Bereichen und Objekten und machen den zweckentfremdeten
Einsatz von Tabellen für das Layout entbehrlich.
Weniger deutlich escheint mir die Zukunft von Frames. Frames
(samt Inline-Frames) sind Bestandteil von "XHTML 1.0 frameset"
- aber XHTML 1.1 kommt nur noch in der Geschmacksrichtung
"strict" - und dort sind Frames und das Target-Tag <target>
nicht vorgesehen. Das hindert bis auf weiteres niemanden daran,
XHTML 1.0 frameset zu verwenden - schließlich sind auch die
alten HTML-Versionen bis zurück zu HTML 2.0 nie "außer Kraft
gesetzt" worden. Aber mit der Eliminierung von <target>
wird man in "reinem" XHTML 1.1 Dokumente, die in
anderen Dateien liegen, nicht mehr einfach so in vorhandene
Seiten einblenden können. Stattdessen muß man, - ähnlich
wie das heute bei Tabellenlayouts auch gemacht wird - einen
Bereich mit dem neuen Inhalt samt seinem ganzen bestehenden
Umfeld neu laden. Allerdings läßt sich damit der Hauptvorteil
von Frames nicht erreichen: Daß nur ein Teil des Bildschirms
scrollt, während ein anderer Teil stehen bleibt und so die
Verbindung zum Kontext sicherstellt. Das wird sich erst dann
ändern, wenn die wesentlichen Browser auch mit dem Positionierungsattribut
"fixed"
umgehen können. Aus der Sicht des W3C sind Frames also nur
geduldete Gestaltungselemente - aber wer nicht durch anderweitige
Vorgaben auf "XHTML strict" festgelegt ist kann sie weiterhin
einsetzen.
Sauberer Code
Mit dem Konzept der strikten Unterscheidung von Dokumentinhalt
und Darstellungsform in der Kombination XHTML/CSS - und zumindest
CSS 1 wird inzwischen von allen "großen" Browsern weitestgehend
unterstützt - ist es nicht mehr erforderlich, den Dokumentencode
durch Layoutanweisungen zu belasten. Jedes Element kann so
dargestellt und so positioniert werden, wie man es haben will,
und zwar weitestgehend unabhängig davon, an welcher Stelle
im (X)HTML-Code es steht. Damit eröffnet sich die Möglichkeit
- überlegte inhaltliche Strukturierung vorausgesetzt - den
Text in der logischen Anordnung zu codieren, die einer linearen
Wiedergabe am besten entspricht, und ihn auf dem Bildschirm
so darzustellen, wie er dort am wirkungsvollsten zur Geltung
kommt. (Näheres und Verweis auf ein kleines Beispiel
hier) Durch entsprechende Auszeichnung lassen sich zusätzliche
Optimierungen für weitere Ausgabegeräte wie Sprachgeneratoren
oder Drucker erreichen - alles auf der Grundlage ein- und
desselben Ausgangsdokumentes. Damit vergrößert sich die Reichweite
von XHTML-Dokumenten ganz erheblich. Davon werden neben reisenden
Geschäftsleuten mit ihren PDAs insbesondere auch Sehbehinderte
profitieren, die zur Zeit von vielen Webangeboten ausgeschlossen
sind.
Michael Charlier
 Diesen Beitrag kommentieren?
 Hier geht's ins Forum »»»
|
Anfordern ?
Seiten gestalten ohne Tabellen - Einführung in die Arbeit mit CSS-Layern