Mögliche Modelle und Theorien für den JavaScript-Einsatz in SELFHTML 9

Im Folgenden möchte ich einige Fragen rund um das neue JavaScript-Kapitel in SELFHTML 9 zur Diskussion stellen. Von vielen verschiedenen JavaScript-Themen, die zu diskutieren sind, sollen erst einmal zwei angesprochen werden.

Was ist sinnvoller JavaScript-Einsatz und welche Auffassung vertritt SELFHTML?

Eine der offenen Fragen ist die grundsätzliche Aufgabe und Rolle, die JavaScript in der Webgestaltung spielen soll und wie SELFHTML 9 dies vermitteln soll.

Wenn man sich das jetzige JavaScript-Kapitel ansieht, so fehlt ein klarer theoretischer Unterbau, der dem Leser sinnvolle Anwendungsgebiete nennt und entsprechende konkrete Beispiele vorstellt. Es gibt freilich verschiedene Äußerungen, die nicht ohne Schärfe und Polemik vor dem Missbrauch von JavaScript warnen. Bereits direkt in der Einführung wird davor gewarnt, JavaScript zur Gängelung des Anwenders zu missbrauchen. Wer JavaScript einsetzt, sollte (…) die Möglichkeiten der Sprache so einsetzen, dass der Anwender einen Mehrwert davon hat, und nicht so, dass ihm etwas genommen wird. Ebenso wird ein verbreiteter Ethos vieler JavaScript-Programmierer hochgehalten: Für Web-Seiten, bei denen Information im Vordergrund steht, und die auch von Suchmaschinen-Robots und Benutzerrandgruppen wie Sehbehinderten erfasst werden sollen, müssen Sie darauf achten, JavaScript nur so einzusetzen, dass die Web-Seiten auch ohne eingeschaltetes JavaScript ordentlich angezeigt werden.

Dem widerspricht die Auffassung über den richtigen JavaScript-Gebrauch, die SELFHTML durch seine Code-Beispiele implizit vermittelt. Denn SELFHTML enthält zahlreiche gestellte, zum Teil irreführende, in der Praxis nur bedingt nützliche Beispielscripte. Oft sind bessere, praxisorientierte Beispiele denkbar. Die meisten Anwendungsbeispiele sind aus heutiger Sicht unpraktikabel, wenig nutzbringend oder sogar der Benutzbarkeit und Zugänglichkeit abträglich. Manche Aufgaben sind mittlerweile mit CSS einfacher lösbar. Trotzdem tragen fast alle Scripte Elemente in sich, die bewahrt und weiterentwickelt werden sollten, da sie auf sinnvolle Anwendungsbereiche von JavaScript hinweisen.

Nun steckt JavaScript in einer schweren Krise, wenn man den gängigen JavaScript-Gebrauch auf Benutzerfreundlichkeit, Zugänglichkeit und Abwärtskompatibilität abklopft. Nicht wenige fordern sogar den kompletten Verzicht auf jegliche aktive Inhalte. JavaScript bietet tatsächlich eine Fülle von Möglichkeiten, die unter dem Dogma »Javascript nur für vernachlässigbare Effekte mit handfestem Mehrwert« längst nicht genutzt werden.

Ein mögliches neues JavaScript-Konzept

In der Vergangenheit versuchten verschiedene Webentwickler der Krise zu entrinnen, indem sie ein neues theoretisches Fundament erdachten, das die Rolle von JavaScript neu definiert. Einige der einflussreichsten Theorien, die für SELFHTML 9 zur Rate gezogen werden könnten, möchte ich kurz diskutieren.

Das Schichtenmodell und der Behaviour Layer

Seit wir CSS für das Layouten von Webseiten benutzen, ist uns die Trennung von strukturiertem Inhalt (Text mit Markup) und der Präsentationslogik (CSS) in Fleisch und Blut übergangen. Die Informationen zur Präsentation werden aus dem Markup ausgelagert in ein zentrales Stylesheet, das möglichst effizient und vielseitig dutzenden ähnlich aufgebauten Dokumenten ein konsistentes Layout verleiht. Das Stylesheet baut auf dem Markup auf und ergänzt es, das HTML-Dokument soll aber auch ohne das Stylesheet möglichst zugänglich sein. So entsteht das Schichtenmodell. HTML bietet die grundlegende Schicht, darüber liegt die CSS-Schicht. Im Code sind beide Schichten voneinander getrennt, um optimale Wartbarkeit, Ausbaubarkeit und Flexibilität zu gewährleisten. Zu dem Modell gehört eine genaue Definition, welche natürliche Rolle den jeweiligen Techniken in diesem System zukommt.

Der Clou ist nun, JavaScript ebenfalls als eine solche Schicht zu begreifen, genannt Behaviour Layer, Verhaltens-Schicht. Mit »Verhalten« ist Interaktivität gemeint: If the user does something, JavaScript can make the page (or the whole site) behave in a certain way. Wie CSS fügt JavaScript dem Dokument einen gewissen eigentümlichen Mehrwert hinzu. CSS und JavaScript sollen mit dem Ziel eingesetzt werden, die Benutzbarkeit zu verbessern. Dieses Credo, das wir in Ansätzen schon in SELFHTML 8 fanden, wiederholt auch Peter-Paul Koch: If you're not sure what your script is good for, don't use it. This especially goes for complicated and pointless DHTML interfaces.

Die drei Schichten HTML, CSS und JavaScript arbeiten Hand in Hand, aber außer der HTML-Schicht ist keine für das grundlegende Funktionieren notwendig. Insbesondere funktioniert die Präsentation auch dann, wenn JavaScript nicht zur Verfügung steht. Das »Verhalten« funktioniert seinerseits soweit wie möglich, wenn das Stylesheet nicht angewendet wird. Peter-Paul Koch hat dabei gewisse Sonderfälle im Kopf, er denkt an Uralt-Browser wie Netscape 3. Sehbehinderte Anwender mit Screenreadern sind ein realistischeres Beispiel. Die möglichen Fälle, in denen CSS und JavaScript zur Verfügung stehen oder nicht, nennt Koch views (Ansichten).

Dieses Modell lässt sich zunächst in einem einfachen Diagramm veranschaulichen:

Mit einem komplexeren Diagramm erläutert Russ Weakley in seinem Webstandards-Workshop (deutsche Übersetzung) die ideale Seitenstruktur:

Mit den Outcomes meint Weakley die besagten »Ansichten«.

Unobtrusive JavaScript

Das Schichtenmodell inspirierte Christian Heilmann zu einem Regelkatalog für eine richtige JavaScript-Anwendung, gepackt in ein Tutorial. Diesen zeitgemäßen JavaScript-Einsatz nennt er Unobtrusive JavaScript. »Unobtrusive« bedeutet erst einmal unaufdringlich, unauffällig und dezent. Heilmann wählte als Übersetzung allerdings Barrierefreies JavaScript. Meiner Meinung nach eine unglückliche Übersetzung eines sowieso schwierigen Begriffs. Unobtrusive JavaScript bedeutet jedenfalls:

• JavaScript ist eine optionale Erweiterung, auf die man sich nicht verlassen sollte.
• Ein Script ist möglichst robust. Es bringt immer die Verfügbarkeit von Objekten in Erfahrung, die es zu nutzen gedenkt. Das Script geht souverän mit den Fällen um, in denen etwas Ungewöhnliches passiert. Es treten somit keine kritischen Fehler auf. Ein Script arbeitet rationalisiert und möglichst effizient.
• Konsequenter Einsatz von standardisierten Techniken wie dem W3C-DOM. Verzicht auf den Einsatz browserspezifischer Objekte, soweit standardisierte Alternativen existieren (meine Lesart)
• JavaScript-»Verhalten« (Interaktivität) wird unabhängig vom verwendeten Eingabegerät definiert, so dass eine gleichwertige Nutzung über Maus, Tastatur usw. möglich ist
• Die Logik aller Schichten wird im Code voneinander getrennt: HTML, CSS und JavaScript werden in separaten Dateien untergebracht. Im HTML-Code wird kein JavaScript-Code mittels Event-Handler-Attributen untergebracht. Stattdessen wird über das W3C-DOM auf die Elemente zugegriffen. Das »Verhalten« wird erst nach dem Laden des Dokuments (onload) dynamisch hinzugefügt. Ferner wird im JavaScript-Code kein direkter CSS-Code untergebracht (.style.eigenschaft = "wert"), stattdessen werden die Klassen gewisser Elemente geändert, so dass andere, vordefinierte CSS-Regeln greifen.

Für und Wider Unobtrusive JavaScript

Das Konzept des Unobtrusive JavaScript löste einen regelrechten Erdrutsch in der Szene aus. Es bildete schließlich die Leitidee für das Manifest der DOM scripting task force des prominenten Web Standards Projects und wird als Inbegriff moderner JavaScript-Anwendung zitiert. Man muss sich fragen, welche Substanz hinter dem Rummel um Unobtrusive JavaScript steckt. Es gehen ständig Trends in der abgehobenen Szene der Webstandards-Jünger um. Je mehr ein technisches Konzept als Segensbringer hochgelobt wird, desto mehr Skepsis ist angebracht. Vor allem steht in Frage, ob diese Theorien universell gültig sind.

SELFHTML und sein Publikum scheint mir traditionell bodenständiger. SELFHTML steht nicht für Techniken ein, die vornehmlich die Arbeit von professionellen Webworkern weiterbringen, die hochkomplexe dynamische Webseiten entwickeln. SELFHTML soll (auch) für Nicht-Programmierer und Fachfremde verständlich sein, die ihre kleinen Webprojekte mit JavaScript verbessern wollen. Dass Unobtrusive JavaScript unter bestimmten Voraussetzungen bestechende Vorteile entfaltet, mag stimmen, hilft uns aber nur bedingt weiter.

Das bedeutet konkret: Obwohl sich die Konzeption Unobtrusive JavaScript praktisch rechtfertigen lässt, steht z.B. in Frage, ob der Verzicht auf Inline-Event-Handler in jedem Fall nennenswerte Vorteile nach sich zieht (siehe auch: Inline JavaScript: What's the Problem?). Inline-Event-Handler sollten überall dort gestrichen werden, wo man Event-Handler effizienter automatisiert vergeben kann. Aber nicht immer ist die Auslagerung mit Arbeitsersparnis und Codeverschlankung verbunden. Für Anfänger scheint es mir umständlich, JavaScript nur auf diese Weise einzubinden. (Ich denke auch aus Webstandards-Sicht unorthodox und pragmatisch über den Einsatz von Tabellenlayout, ohne die Sinnhaftigkeit des generellen Verzichts auf Tabellenlayout anzuzweifeln.)

Es stellte sich zudem heraus, dass das Hinzufügen von Interaktivität ohne Eingriff in den HTML-Code alles andere als trivial ist. Zum einen ist die DOM-Events-Spezifikation nicht ausgereift genug (Stichwort DOMContentLoaded), zum anderen unterstützt der Internet Explorer nicht einmal deren Grundlagen. Die noch Anfang und Mitte des Jahres hochgelobten essentiellen Scripte, die Unobtrusive JavaScript erst effizient machen, werden mittlerweile als problematisch angesehen (Stichwort addEvent). Zu einem Abschluss ist die Diskussion über diese Grundlagenscripte noch lange nicht gekommen.

Ajax – ein Sonderfall der JavaScript-Anwendung?

Vor dem Hintergrund dieser Theorien stellt sich die Frage, welche Rolle Ajax (Asynchronous JavaScript and XML) spielt. Ajax scheint zunächst überhaupt nicht mit den besagten Konzeptionen vereinbar, denn zumeist sind heutige Ajax-Anwendungen ohne JavaScript nicht funktionsfähig und die Zugänglichkeit ist nur selten gewährleistet. Für Ajax ist zunächst nur die »Ansicht« maßgeblich, bei der die CSS-Präsentation und das JavaScript-»Verhalten« unabkömmlich sind.

Die Grundlagen hinter Unobtrusive JavaScript lassen sich jedoch auf Ajax-Anwendungen übertragen. In diesem Sinne plädiert Jeremy Keith für Progressive Enhancement, die schrittweise Verbesserung einer Webseite ausgehend von der Basisschicht hin zu einer komfortablen Ajax-Anwendung. Die serverseitige Programmierung soll mit verschiedenen möglichen Benutzer-Interfaces zusammenarbeiten können, das heißt mit einer clientseitigen Ajax-Anwendung und einer klassischen serverseitigen Webanwendung (siehe auch). »Graceful degradation« bedeutet dementsprechend eine Abwärtskompatibilität, die leistungsschwache und besondere Zugangstechniken berücksicht und gleichzeitig die Fähigkeiten von Ajax-kompatiblen Systemen ausschöpft.

Andere argumentieren, dass Ajax ein Sonderfall ist, auf den das Dogma der Graceful Degradation nur bedingt anwendbar ist. Ajax ermöglicht es nicht nur, traditionelle Webanwendungen komfortabler umzusetzen, sondern bietet Möglichkeiten, die traditionell nicht oder nur extrem umständlich umsetzbar waren. Eine Alternativ-Version ohne Ajax ergibt bei einem solchen Ajax-Einsatz wenig Sinn.

Ajax in SELFHTML 9

Abschließend möchte ich auf den mehrfach geäußerten Wunsch eingehen, dass sich SELFHTML 9 mit Ajax beschäftigen soll. Nun, um Tim zu zitieren, wir sind uns natürlich dieses Themenkomplexes bewusst und schätzen ihn als recht wichtig ein. Ajax ist in aller Munde, viele SELFHTML-Leser haben ein Bedürfnis nach Informationen zum Thema. Wir arbeiten deshalb bereits an einem Feature-Artikel zu XMLHttpRequest.

Die aktuellen Nachfragen weisen auch darauf hin, dass Ajax momentan mächtig hochgespielt wird. Der Vorwurf des Hypes wurde oft geäußert. Tatsächlich fehlen neben Ajax zahlreiche, vielleicht sogar wichtigere JavaScript-Themen in SELFHTML – eines davon habe ich oben angesprochen.

Grundsätzlich gilt, dass eine Dokumentation wie SELFHTML, die höchstens alle paar Jahre grundlegend erneuert wird, schwer auf hochaktuelle Entwicklungen und unausgegorene Zukunftstechniken eingehen kann. Dafür sind eher die besagten Feature-Artikel oder eben dieses Weblog gedacht. Nichtsdestoweniger werden wir das Thema Ajax und allgemein die Nutzung von JavaScript im Zusammenhang mit Webanwendungen in SELFHTML 9 gebührend behandeln, denn dahinter steckt mehr Substanz, als der Hype darum vermuten ließe.

Wie helfen uns die Theorien für SELFHTML 9 weiter?

Unzweifelhaft stellt das Aufkommen von Ajax und das stärkere Interesse an zugänglichen, flexiblen Webseiten die JavaScript-Frage neu. Doch welche Erkenntnisse lassen sich aus den besagten Theorien im Hinblick auf SELFHTML 9 ziehen? Inwiefern bringen sie uns weiter als die übliche Faustregel, JavaScript als optionalen Zusatz zu begreifen, der durch gezielte Interaktivität den Bedienkomfort verbessert?

Eine weitere entscheidende Frage wurde hier nur kurz angerissen: Welche konkreten Anwendungsbereiche von JavaScript gibt es? Wie kann sich dies im Aufbau des JavaScript-Kapitels niederschlagen? Welche JavaScript-Anwendungen geben ein gutes Beispiel ab und sollten in SELFHTML 9 vorgestellt werden?

Wir bitten um Kommentare und Vorschläge zu diesen Fragen. Da dieser Weblog-Eintrag reichlich lang ist und das Thema entsprechend komplex, haben wir in unserem Forum eine Diskussion gestartet:

Forumsdiskussion: Der sinnvolle Einsatz von JavaScript