Zu den beliebtesten Streitgegenständen in der WebAuthoring-Community gehören Frames und Popups. Nicht etwa diese unverschämten Werbefenster von Portalen oder die Browsergewitter im Rotlicht-Quartier des Webs, sondern die Fenster mit Zusatzinformationen, wie wir sie auch in Artikeln des Webwriting-Magazins gerne einsetzen. Gut, Frames und zusätzliche Fenster können Probleme bereiten - besonders, wenn man nicht richtig damit umgeht. Dann klappt es nicht mit dem Bookmarking von Texten, die in einem eigenen Frame aufgerufen werden, oder ein Popup beansprucht den ganzen Bildschirm und der verwirrte User glaubt plötzlich, ohne "Back"-Button dazustehen.
Vielfach finden solche Auseinandersetzungen in den öffentlichen Mailinglisten des W3C statt - z.B. in der Liste www-html. Der Besuch der Archive ist empfehlenswert.
Die Probleme lassen sich freilich mit mäßigem Aufwand vermeiden, so daß man im konkreten Fall ganz nüchtern über die Vor- und Nachteile des Einsatzes dieser Mittel diskutieren könnte. Trotzdem schlagen Gegner und Befürworter des gleichzeitigen Erscheinens mehrerer Fenster regelmäßig in Heiligen Kriegen aufeinander ein. Es geht nicht um Praktikabilität, sondern um's Prinzip. Und zwar jenes Prinzip, das gebieterisch verlangt, daß der Browser immer nur ein ein Dokument zur gleichen Zeit darstellen soll. Und weil <target> nun einmal das Attribut ist, mit dessen Hilfe sich verschiedene Dokumente so unkeusch vermischen lassen, sind Puristen und Puritaner aller Länder seit Jahren bemüht, <target> aus dem Sprachumfang von (X)HTML herauszudrängen - bislang vergeblich.
Es geht um mehr als Prinzipienreitere - die Auseinandersetzung hat einen realen und durchaus ernstzunehmenden Kern: Es geht um den Dokumentenbegriff, also um die Beschreibung der grundlegenden Eigenschaften, die ein "Webdokument" ausmachen sollen.
Der Dokumentenbegriff des W3C mag nirgendwo explizit dargelegt sein - implizit steckt er in den von HTML zur Verfügung gestellten Dokumentenelementen und kann von daher mit geringer Mühe erschlossen werden. Dokumente im Sinne des W3C haben demnach - unter anderem - folgende Eigenschaften: Sie sind in mehreren (bis zu sechs) Gliederungsebenen hierarchisch strukturiert und dementsprechend oft sehr lang. Sie enthalten kurze <q> und als Absatz alleingestellte <blockquote> Zitate, denen mit <cite> eine Quellenangabe zugeordnet (nicht gelinkt) werden kann. Weitere Elemente erlauben es, verschiedene Arten von Listen <ul>, <ol>, auch mehrstufige, Tabellen <table>, verschiedene Typen von Definitionen <dfn>, <dd>, Code-Auszüge <code> und Beispiele <sam> darzustellen und eigens hervorzuheben. Abkürzungen können auf zweierlei Weise als <abbr> oder <acronym> gekennzeichnet werden... Der hier abgebildete Dokumentenanfang enthält neben Versionsvermerken gleich zwei Inhaltsverzeichnisse - erst dann geht es langsam zur Sache.
Gut, man muß nicht alle diese Elemente benutzen, tatsächlich hat es bei vielen sogar wenig Sinn, weil kein Browser sie berücksichtigt. Die unvollständige Aufzählung macht trotzdem überdeutlich: Die besondere Fürsorge des W3C gilt umfänglichen Abhandlungen, wie sie in der Welt der Wissenschaft gebräuchlich sind, irgendwo zwischen Fachartikel und Doktorarbeit. Auch vielhundert-seitige technische Handbücher fallen in diese Kategorie. Die Erbschaft der Dokumentenbeschreibungssprache SGML ist unübersehbar.
Eine Diskussion, die Ende Januar in der amerikanischen Liste WebDesign-L stattfand, hat hierzu einen interessante Gesichtspunkte erbracht: Viele kommerzielle Webseiten sind weniger "Dokumente", sondern (noch funktionsarme) "Applikationen". Wir werden dem nachgehen. (Feb.03)
Für den Typ von Texten, der heute die meisten Seiten des kommerziellen und populären WWW bestimmt, hat dieser Dokumentenbegriff kaum etwas zu bieten. Er bezeichnet übrigens auch das exakte Gegenteil von dem, was zum Beispiel von Jakob Nielsen und anderen Befürwortern der kurzen und auf einen Blick "überfliegbaren" Web-Schreibe unermüdlich propagiert wird. Doch eine Erweiterung der Sprache um Elemente, die die Praxis des Webs stärker unterstützen könnten, ist nicht in Sicht.
Die einzige Konzession von HTML an die Vernetzungsmöglichkeiten unter TCP/IP ist die Sprungmarke <a>. Diese Erfindung von Tim Berners Lee hat zwar dazu geführt, daß die Sprache als Hypertext Markup Language bezeichnet wurde und trug ganz wesentlich dazu bei, das Internet in seiner heutigen Form hervorzubringen, sie scheint aber ansonsten ohne wesentlichen Einfluß auf den Dokumentebegriff des W3C geblieben zu sein. Nach <a> ist in Richtung "Hyper" nur noch <link> dazu gekommen, womit aber die meisten Browser bis auf den heutigen Tag nicht viel anzufangen wissen.
Besonders "vernetzungsfreundlich" ist HTML jedenfalls nicht. HTML-Dokumente bleiben im Prinzip streng lineare Veranstaltungen, die man am besten von der Einführung 1.1.1 bis zur Schlußbetrachtung unter 7.5.3 Punkt für Punkt durchliest. Man kann innerhalb des Dokuments, vorzugsweise vom Inhaltsverzeichnis aus, zu anderen Punkten im Text springen, oder man wechselt zu einem anderen ebenso aufgefassten Dokument. Jedes steht für sich und ganz allein auf dem Bildschirm - Kontext findet nur im Kopf des Lesers statt.
Hier ist Gelegenheit für eine erste Zusammenfassung, auf deren Grundlage wir uns dann dem Kern der Sache weiter annähern wollen.
Befund 1: Der Dokumentenbegriff des W3C orientiert sich an einer völlig anderen Art von Texten als denjenigen, mit denen Seitenbauer und Webwriter üblicherweise zu tun haben.
Befund 2: Die Sprache des Seitenbaus führt zwar das Wort "Hypertext" im Namen, das heißt aber nicht, daß sie dafür geschaffen wäre, Texte und Dokumente zu vernetzen. Sie wehrt sich im Gegenteil gegen jede Vernetzung in der Fläche und sieht in den Links nicht mehr als ein Vehikel, einigermaßen mühelos von einem Text auf den anderen umzuschalten.
Nur als kleines Beispiel fü die Richtung, in die hier zu denken wäre: Wie wäre es mit Auszeichnungselementen für Dachzeile, Untertitel, Zusammenfassung, Vorspann, Fußnote, Anmerkung usw? Stattdessen bekommen wir in XHTML2 <line> als Ersatz für <br> - das wird uns sehr weiter helfen.
Natürlich kann man diese Elemente mit CSS nachbilden - aber warum stehen sie nicht in der Struktur zur Verfügung?
Der Befund 1 erhält seine Bedeutung für die Praxis der Webarbeit vor allem dann, wenn man ihn im Zusammenhang mit der im Prinzip durchaus berechtigten Forderung betrachtet, Inhalte gefälligst "sauber strukturiert" ins Web zu stellen. Während HTML für wissenschaftliche Dokumente reichlich Strukturierungselemente bereitstellt, hat es für kurze journalistische Texte, Produktvorstellungen, einfache Gebrauchsanweisungen usw. wenig zu bieten - jedenfalls nichts, was auf die besonderen Bedingungen dieser Textsorten ausgerichtet wäre.
Und genau an dieser Stelle macht sich die als Befund 2 dingfest gemachte strikte Linearität von HTML besonders unangenehm bemerkbar: Viele moderne "Dokumente" bestehen nicht mehr aus einem linearen Bandwurmtext wie dieser Artikel hier, sondern aus parallel dargebotenen Informationsatomen, die gleichzeitig im Blickfeld stehen. Sie bürden dem Informationsempfänger in erheblichem Umfang die Last der Auswahl und der Priorisierung auf - und bieten ihm gleichzeitig ungeahnte Möglichkeiten zur Assoziation und zur Entwicklung "lateraler" Denkansätze. Die Dinge vernetzen sich - nicht nur auf der technischen Ebene, sondern in der Wahrnehmung.
Jede Doppelseite eines Magazins - hier ist es der Focus - mit oft kunstvoll arrangierten Headlines und Zwischenüberschriften, Photos, Infografiken und Tabellen, Kästen mit Zusatzinformationen nicht zu vergessen, zeigt es in aller wünschenswerten Deutlichkeit: Der moderne Informationskonsument hat auf Multitasking-Betrieb umgestellt. Und das so gründlich, daß sogar jeder Fernsehsender, der etwas auf sich hält, den Leuten zu besonderen Anlässen neben dem Ton auf dem Bildschirm auch mehrere Fenster bietet, in denen sie das Geschehen aus unterschiedlichen Perspektiven gleichzeitig und den Moderator noch zusätzlich im Blick haben.
Als Kulturkritiker mag mir die darin (möglicherweise) ausgedrückte Unfähigkeit zur Konzentration auf ein Wesentliches mißfallen, aber die Leute scheinen diese Ausweitung ihres Gesichtsfeldes zu mögen, und wer bitteschön sind wir Seitenbauer, daß wir ihnen den pädagogischen Stinkefinger zeigen und sagen: das dürft Ihr aber nicht!
Die Computerzunft ist nicht unschuldig an der Entwicklung, die hierhin geführt hat: Erst die Fenstertechnik, die bekanntlich nicht von Microsoft erfunden, sondern bereits in den 70er Jahren von den Smalltalk-Entwicklern Daniel Ingalls und Adele Goldberg ausgearbeitet worden ist, hat den Computer dazu befähigt, sich vom Werkzeug in der Hand hochqualifizierter Spezialisten zum Arbeits- (und Unterhaltungs-)Gerät für jedermann zu entwickeln. Die Smalltalk-Entwickler wollten alles, was sie für ihre Arbeit (und zum leichteren Verständnis des Computers durch Kinder!) brauchten, gleichzeitig am Bildschirm im Blick haben:
Mein Smalltalk-80 läuft nicht mehr unter Windows. Aber sein aktueller Clone "Squeak" sieht, wenn man die Bonbonfarben wegnimmt, fast ebenso aus wie das Original.
Den Code des Programms, die Werkzeuge zu seiner Bearbeitung, das Ergebnis seines Ablaufs, die Fehlermeldungen - jedes in seinem eigenen Fenster. Das Konzept erwies sich im höchsten Maße als fruchtbar und wirkt in vielem auch da segensreich, wo Anwender wegen unzureichender technischer Ausstattung oder fehlendem Verständnis/Interesse sich darauf beschränken, ihren ganzen Bildschirm nur einer einzigen Anwendung vorzubehalten.
Die bei Smalltalk erstmals für den Computerbildschirm erprobte Arbeitsweise - in Wirklichkeit ist sie natürlich viel älter, wie man an jedem Schreibtisch mit vielen gleichzeitig aufgeschlagenen Büchern sehen kann - ist heute selbstverständliche Grundlage der Arbeit mit zahlreichen Programmen von Adobes Photoshop über Bradsofts Topstyle bis zu Macromedias Dreamweaver. Warum sie ausgerechnet für die Arbeit mit Dokumenten und Informationseinheiten nicht gelten soll, ist absolut nicht einsehbar. Schließlich bietet die Vernetzung technisch ideale Voraussetzungen dafür, dem Informationskonsumenten den Aufruf von Zusatzinformationen, Vergleichsmaterial, Gegenmeinungen usw. zu erleichtern, ohne ihn zu nötigen, sein Ausgangsdokument zu verlassen und den für die Herstellung eines Sinnzusammenhanges so wichtigen Kontext aufzugeben.
Als Vorform solcher Dokumente kann man vielleicht den Random Walk through the twentieth Century des Wiesner-Preojects am MIT betrachten, oder - wesentlich neuer - die multidimensionale Navigation auf einer Infoseite von IBM.
Je mehr sich diese kontextorientierte Wahrnehmungsweise verbreitet, desto stärker werden Textproduzenten und Seitenbauer darauf eingehen müssen und sicher auch von sich aus eingehen wollen. Es werden immer mehr "Hyperdokumente" entstehen - keine labyrinthischen "Hypertexte", in denen man schnell jede Orientierung verliert, sondern eine Art "Kontextgeneratoren", deren Autoren ihren Lesern vorschlagen, zwischen bestimmten selbstverfassten und anderswo vorgefundenen Einzeltexten ein bestimmtes Beziehungsgeflecht herzustellen. Hilfen zur Herstellung von Überblick.
Lineare Dokumente des Typs, für den HTML so freigebig Markup-Elemente bereitstellt, werden damit nicht überflüssig - sie stellen nach wie vor den größten Teil aller Dokumente. Aber es ist an der Zeit, anzuerkennen, daß diese Dokumente nicht der einzige Typ sind, der im Web verbreitet und gesucht wird. Und dieser Anerkennung hätten dann auch praktische Schritte in der Art zu folgen, daß (X)HTML nicht länger gegen Dokumentenelemente und Präsentationsverfahren "abgeschottet" wird, die anderen Typen entsprechen. Und tatsächlich: Es besteht Anlaß zur Hoffnung. Die Weiterentwicklung von XHTML nach Version 1.0 erfolgt auf modularer Basis - das verleiht der Sprache zumindest in der Tendenz (d.h., soweit die Browser es zulassen) höhere Flexibilität. Und nachdem "target" in XHTML 1.0 nur noch "transitional" zur Verfügung stand und in 1.1 ganz ausgeschlossen war, steht es für ein Modul in XHTML2.0 wieder auf der Liste - unter anderem zur Beschickung von Xframes - einer XML-Anwendung, die genau den hier beschriebenen Zweck verfolgt: Die Kombination verschiedener Dokumente unter einer einzigen Präsentsations-Sicht zu erlauben.
Entsprechend der Tradition des W3C ist Xframes allerdings bei den Standard-Entwicklern durchaus umstritten - ob und wieweit es Bestandteil künftiger XHTML-Versionen oder überhaupt jemals praxisreif wird, steht derzeit noch ziemlich in den Sternen. Aber allein die Tatsache, daß in den heiligen Hallen des W3C intensiv über "anwendungsähnliche Sichten auf kombinierte Dokumente" diskutiert wird, unterstreicht, daßdie Verwendung von "target" nicht so abwegig sein kann, wie manchmal behauptet wird. "Hyperdokumente" haben Zukunft. [Januar 2003]
© Claudia Klinger +
Michael Charlier
Alle Rechte bei den Autoren
