spacer
spacerwebwriting-magazin.despacer Newsletterspacer Forumspacerspacer Kontaktspacer
spacer
spacer spacer Zur Startseite Webwriting: Text, Design, Usability.... Tipps, Tricks, Tutorials Lob, Kritik, Rezensionen Was das Netz bewegt... Software, Tools Für Euch gelesen Surftipps, Knowhow-Quellen spacer
Logo

Webwriting News
- der Newsletter des Webwriting-Magazins meldet neue Beiträge und Interessantes rund ums Webpublishing - was wir halt so finden in den unendlichen Weiten.

zum BestellfensterAnfordern ?

spacer



Lies auch:

Seiten gestalten ohne Tabellen - Einführung in die Arbeit mit CSS-Layern
 
Erste Schritte mit CSS - Gleiches Schriftbild in (fast) allen Browsern
 
Was Betriebssystem und Browser alles mit Schriften anstellen
 

Webwriting-Magazin > So geht's


Keine Angst vor XHTML

Mit 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

gelber Punkt Diesen Beitrag kommentieren?
Spacer Hier geht's ins Forum »»»

Webwriting-Magazinspacer
spacer spacer zur Startseite Webwriting: Text, Design, Usability.... Tipps, Tricke, Tutorials Lob, Kritik, Rezensionen Was das Netz bewegt... Software, Tools Für Euch gelesen Surftipps, Knowhow-Quellen spacer
spacer
spacerwebwriting-magazin.despacer Newsletterspacer Forumspacerspacer Kontaktspacer
spacer