Hi,
Naja... ähnliches hatte ich in http://aktuell.de.selfhtml.org/weblog/javascript-einsatz auch geäußert.
Danke für den Hinweis. Den Beitrag kannte ich noch nicht. Ich war damals extrem beansprucht ... =:-o
Ich teile deine Aussage so ziemlich vorbehaltlos.
Das Lernen des (einfachen) Registrierens von Event-Handlern via JavaScript ist dagegen nicht sehr zeitraubend.
Ja, aber unobtrusive JavaScript ist *das* ja bei weitem *nicht* allein! UJS ist für mich erstmal "nur" die Manipulation von HTML/CSS zur Laufzeit, ohne daß dies in HTML besonders indiziert werden muß (optimalerweise hat der HTML-Autor also gar nichts zu tun). Das Registrieren von Event-Handler ist da nur ein winziger Teil, den man in Anspruch nimmt, wenn es sinnvoll ist und nicht, wenn die direkte Notation Vorteile bringt (sehe ich vergleichbar zur Verwendung von id/name/class).
Mein "Klassiker" für die Verwendung von Inline-Event-Handlern ist mein Coding: MagicHTML - erweiterbares Grundgerüst - hier habe ich z.B. bewußt auf Inline-Code gesetzt.
Der Sinn dieses Templates ist es ja, dem Autor 6 exakt definierte Punkte zu geben, an denen er per UJS Einfluß aufs Dokument nehmen kann: "GO" im Head, "B4" direkt nach Öffnen des BODYs (z.B. BODY unsichtbar machen), "L8" direkt vor Schließen des BODYs (Manipulation des Codes und Anzeige des Dokuments), "OK" nach dem Laden, "KO" beim Verlassen und "XL" beim Ändern der Größe. Da hier aber zwangsläufig mind. B4 und L8 direkt im Quelltext stehen müssen, erschien mir das plausibler - es ist ja nur eine Vorlage, um beliebigen HTML-Content aufzunehmen, der wiederum durch beliebigen, aber nunmehr externen JS-Code erweitert/verändert werden kann.
Und in der Nutzung fallen mir dann so Klassiker ein wie "Sortierbarkeit einer beliebigen, statischen HTML-Tabelle" oder "verkürzte Darstellung von umfangreichen Daten" (Listen, Textabsätze, Tabellen, FAQ, deren Antworten versteckt sind), oder "Anpassung und/oder Erzeugung von Elementen" (z.B. Links), oder ...
... wobei ich halt prinzipiell solche Manipulationen möglichst objektnah eledigt haben möchte, keinesfalls aber irgendwann mal im Onload-Event! =:-o (Als mich immer wieder aufs neue und am extremsten abstoßende Beispiel sei hier die MSDN-Doku erwähnt, wo mühselig die komplette Seite gerendert wird, um dann im Onload-Event das Frameset nachzuladen. =:-/)
Alles Dinge, die man dezent einem statischen HTML-Code aufoktroyieren kann (inkl. der Registrierung von Event-Handlern ;-)), ohne ihn selbst anzufassen (ggf. also noch nicht mal durch Auszeichnung mit IDs etc.), oder die Seite im Falle abgeschalteten JS' unbrauchbar zu machen. Halt bestes DHTML in Reinkultur.
Aber in welcher Form solche Dinge nun spezifisch gelöst sind (per Inline-Code oder Referenz), sei erstmal dahingestellt (nun ja, ich bin hier ja sicherlich nicht gerade als "Dogmatiker" bekannt ;->). Das hängt sicherlich auch von den Umständen ab (Privatanwender/Firma, CMS/Webeditor mit Templates & Siteverwaltung/..., etc.). Da würde ich nie pauschal sagen: Das muß immer so oder so sein.
Gruß, Cybaer
PS: Ich sehe JS übrigens nicht in einer Krise. Wenn es vorhanden ist, gut. Wenn nicht, auch OK. Und wenn der Surfer mangels JS nicht nur auf "Spielerei" und Komfort, sondern auch auf wichtige Funktionen verzichten muß: Sei's drum. I.d.R. sollte ein Mindestmaß ohne JS nutzbar sein. Aber wenn sich etwas wirklich nur mit JS machen läßt, dann ist es eben so. IMHO besser, als etwas nicht zu tun, nur weil es ein paar nicht nutzen können oder wollen. Daß manche Webdesigner wohl auch aus Bequemlichkeit/Kostendruck auf eine Non-JS-Variante verzichten, obwohl sie möglich wäre (bzw. eigentlich unnötig JS-only coden), ist zwar schade, halt traurige Realität ...
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!