Hallo,

Problematisch wird es, wenn man sechshundertunddreißig Objekte/Methoden/Eigenschaften mit fingierten und praktisch unsinnigen Beispielen hat, die jeweils ohne jegliche Wertung nur das Feature an sich nüchtern technisch vorstellen, *und* wenn man gleichzeitig keinen Teil der Dokumentation hat, der diese Fragmente zu sinnvollen Anwendungsbeispielen zusammenfügt und den ganzen in sich »dummen« Feature-Beschreibungen einen übergreifenden Sinn gibt.

Das ist sicherlich unwidersprochen richtig. Ich wollte damit auch nur ansprechen, dass das Verständnis eines Funktionsprinzips - zumindest mir persönlich - oftmals leichter fällt, wenn man ein möglichst eingegrenztes Beispiel hat, auch wenn dessen Gebrauch im täglichen Leben eher unwahrscheinlich ist.

Erklärt mir selfHTML eigentlich, dass man mit CSS sehr viel Unsinn machen kann, [...]

Nein, momentan hat SELFHTML in dem Punkt Lücken.

Was aber nicht heißt, dass SELFHTML nicht auf diese Problematiken hinweisen sollte. Wenn wir Gestaltung mit CSS vorstellen, ist es nur sinnvoll, dass wir auch ansprechen, was eine gute Gestaltung ausmacht  [...]

Auch hier gebe ich dir recht. Was aber im Zusammenhang mit JS auffällt, dass hier immer direkt auf dessen unsinnigen Gebrauch hingewiesen wird, andere Bereiche wie CSS diesen Reflex aber nicht auslösen. Ich kann mich noch sehr wohl an ein Blink-Tag erinnern (HTML!), das einfach nur als furchterregend zu bezeichnen war. Was heißen soll, dass man natürlich mit JS viel Unsinn machen kann, dies aber mehr an dem Script-Autoren liegt, als an der Sprache selbst. So wie ich dich verstanden habe, würdest du mir da aber wohl auch zustimmen.

Eine einfache, unpolemische Darstellung standardkonformer Techniken wäre angebracht.

Die wertfreie Darstellung von netten Zeitgenossen wie window.status und window.open hat wunderbaren JavaScript-Missbrauch in die Welt hinausgetragen, der uns auch noch übermorgen auf Webseiten nerven wird.

'window.status' war definitiv ein bereits in der Sprache angelegter Fehler; 'window.open' wurde missbraucht. Aber da haben sich moderne Browser ja gegen zu wehren gewusst. Möchte ich heute ein PopUp-Fenster öffnen, muss dies schon einen gehörigen Nutzen haben, damit ich dem Anwender erklären kann, dass er dies zulässt. Firefox unterbindet hier auf Wunsch auch das Ausblenden der Statusleiste. IE7 soll wohl demnächst auch die Adressleiste stets eingeblendet lassen. Dass JS für Werbung genutzt wird, kann nicht generell als negativ für aktive Inhalte ausgelegt werden. Zum einen finanziert sich ein Großteil des Netzes durch Werbung (auch wenn sie nervt) und zum anderen kann man auch bei einer MarkUp-Sprache serverseitig sagen, dass beispielsweise bei jedem dritten Anklicken eines Links einer Seite statt dem eigentliche Ziel zunächst eine HTML-Seite mit Werbung übertragen wird. Eine solche zwischengeschaltete HTML-Seite wäre nicht weniger nervig als ein PopUp-Fenster.

Wir wollen nicht positivistisch und wertfrei Techniken vorstellen. Das wollte SELFHTML noch nie, und das macht SELFHTML auch momentan nicht. Wieso sollte sich SELFHTML darauf begrenzen, Techniken vorzustellen, ohne die Sinnfrage zu stellen? Ich finde, das widerspricht unseren grundsätzlichen Auffassungen. SELFHTML will für einen kritischen und selbstbewussten Umgang mit Technik (»Energie des Verstehens«) stehen. [...]

Hier stimme ich dir durchaus zu, würde aber analog zum journalistischen Grundsatz Meldung und Kommentar voneinander trennen. Also zunächst wie gehabt die Funktionalität erklären und im folgenden Text, genauso wie hier auch auf unterschiedliche Browserfähigkeiten eingegangen wird, bei bekannten 'problematischen' Aspekten einer Funktionalität darauf hinweisen. Wenn der Leser die Technik verstanden hat, dann kann er sie und ihren Einsatz auch besser beurteilen.

Es gibt nun einmal eine (Pseudo-)Wissenschaft, die sich über die nutzbringende und effiziente Technikverwendung Gedanken macht. Ein Lehrbuch, das die Erkenntnisse dieser Wissenschaft nicht der nüchternen Technik, für die es weder sinnhaft noch sinnwidrig gibt, entgegenstellt, bildet meiner Meinung nach keine kompetenten Anwender aus. Selbstbestimmt handelt höchstens derjenige, der sich wissentlich, aber nicht naiv, über Bedenken und Empfehlungen hinwegsetzt.

Dies sind jedoch eher Überlegungen grundsätzlicher Natur und gehören m.E. an den Anfang oder das Ende eines technischen Textes. Hier müsste man sicherlich auf die Problematik von Textreadern und Suchmaschinenlesbarkeit eingehen. Auch der sinnhafte Einsatz aktiver Seiteninhalte gehört m.E. hier besprochen.

Die meisten der Punkte zum 'Unobtrusive JavaScript' halte ich übrigens für ein Script für selbstverständlich. Andernfalls funktioniert es nicht fehlerfrei.

zu Punkt 1: Man darf sich im Web für elementare Dinge nicht ausschließlich auf JS verlassen. Insbesondere nicht bei der Erreichbarkeit von Seiteninhalten. (Hier sind aus wirtschaftlichen Überlegungen die Suchmaschinen sicherlich noch das wichtigste Argument.)

zu Punkt 2: Scripte, die fortwährend Fehlermeldungen erzeugen, funktionieren nicht, auch wenn diese nicht mehr defaultmäßig angezeigt werden. Ein Testen auf die Verfügbarkeit eines Objektes sollte auf die 'Unsicheren' begrenzt sein.

zu Punkt 3 (auch zu deiner Bemerkung zu Standards): Da man sich nach dem Schreiben nicht tottesten kann, sind Standards die einzige Möglichkeit, 'robuste' Scripte zu schreiben. Es ist schier nicht möglich, auf allen Browsern, Rendering-Engines oder allen Betriebssystemen mit all ihren jeweiligen Updates zu testen.

zu Punkt 4: Aus wirtschaftlichen Erwägungen bei vielen Anwendungen oftmals nicht möglich. Man sollte sich bewusst sein, dass (zumindest bei gewerblichen Einsatz) dies auch immer irgend ein Auftraggeber bezahlen muss. Und der durchschnittliche Privatanwender (natürlich mit Ausnahmen) fürchte ich, wird sich über solche 'philosophische' Aspekte leider überhaupt keine Gedanken machen.

zu Punkt 5: Technisch sehr aufwendig und für die Meisten wahrscheinlich gar nicht umsetzbar.

Was nun den Zusatz »standardkonforme Techniken« angeht, so verstehe ich ihn nicht. Standardisierung heißt noch längst nicht, dass man diese Techniken unreflektiert benutzen kann. Die Frage, wie und wozu man sie benutzen, stellt sich ebenso.

s.oben.

Was die Darstellung von DOM Events angeht, so stimme ich dir zu, möchte aber einwenden, dass gerade in diesem Bereich Standardisierung ein Witz ist.

Ja, man wird das Gefühl nicht ganz los, die wüssten selbst nicht genau, was die da wollen ...

[...] Die Dokumentation der Event-Eigenschaften halte ich auch ohne Bezugnahme auf DOM Events für eine der besten - weil wir eben den Browser-Quirks detailliert untersucht haben. Es fehlen natürlich gewisse Methoden und Eigenschaften, die du wahrscheinlich meintest.

Das an diesem Kapitel mittlerweile der Zahn der Zeit genagt hat, liegt aber auch an der 'standardlosen' Zeit. Auch dies ist ein Vorteil von Standards (auch wenn sie für sich unsinnig sein sollten), dass technische Beschreibungen nicht andauernd umgeschrieben werden müssen.

Ciao
Heinzelhund

P.S.: Mir ist übrigens klar, dass du nichts generell gegen Standards gesagt hast ;-)