nicht angemeldet
Hallo Thomas,
Ich faende es gescheiter, wenn man sich wahlweise fuer CSS bzw. DOM-Scripting entscheiden kann und das auf einer soliden Basis, d. h. einheitliche CSS-Eigenschaften und DOM-Methoden, die in nahezu jedem (X[HT]ML-)Kontext funktionieren.
Klingt vernuenftig ;-)
Eigentlich frage ich mich ja auch nach dem tieferen Sinn der konkurrierenden Event-Binding-Techniken. Schliesslich hindert einen doch niemand daran, Handler-Funktionen in ein externes .js-Script auszulagern, um dokumentuebergreifende Wiederverwendbarkeit zu erreichen. Wo es IMHO tatsaechlich noch ein wenig hakt, ist die Schnittstelle zwischen Event-Ausloesern und Event-Handler-Code. CSS und seine Selektoren als Schnittstelle zu benutzen finde ich da durchaus eine gelungene Loesung. Um die Events, die ein CSS-Selektor ausloest, zu behandeln, reicht aber doch eigentlich ein identifizierbarer Scriptbereich (<script id=...>) oder eben eine externe js-Datei, wo die gewuenschten Event-Listener und Handler-Funktionen nach DOM-Standard definiert werden. Der ganze XML-Overhead sowohl im MS-Behavior-Konzept als auch im XBL-Konzept will mir dagegen nicht so recht einleuchten, wenn ich ehrlich bin (kann aber auch sein, dass ich einfach noch zu wenig verstehe davon).
viele Gruesse
Stefan Muenz