nicht angemeldet
hi,
Denke objektorientiert. Die onclick-Eigenschaft eines Links ist die onclick-Eigenschaft eines Links, nicht eine onclick-Eigenschaft der Seite. Warum also sollte sie außerhalb des einen Links existieren?
if(objHandlerElement[i].target == strTarget){
// Hat dieses Element bereits eine onclick-Funktion?
// dann schreibe sie in das Array:Nein, dann rette sie in eine von Dir definierte Eigenschaft des selben Elements.
Wo du das gerade ansprichst - in der Diskussion zur von mir verlinkten Herangehensweise spricht ein Kommentierer diesbezüglich von "Polluting the DOM":
"Why I like this version better than the one above? Well, all adapted functions (the event handlers) are stored in one central place. No more polluting the DOM."
Ich konnte das als Pro-Argument für eine zentrale Verwaltung aller Handler-Funktionen bisher nicht nachvollziehen.
Das DOM ist doch schon per se "polluted" - HTML-Elemente haben zahlreiche (/-lose) Eigenschaften, die in ihrer DOM-Repräsentation eh an ihnen aufgehängt sind.
Deshalb sehe ich nicht, wo das Problem liegen soll, wenn man für ein eigenes Eventhandling oder auch andere Zwecke Element-spezifische Werte nicht auch am Element ablegen sollte.
Höchstens einen potentiellen Namenskonflikt mit aktuellen, mir als Scriptersteller aber unbekannten, oder zukünftigen, Browser-eigenen oder in späteren Javascript-/ECMA-/DOM-Versionen noch definierten werdenden [HTML-]Objekt-Eigenschaften könnte ich mir als Argument für diese Sichtweise noch vorstellen.
Aber dann dürfte ich nicht mal mehr eigene Funktionen oder Objekte im Kontext von window anlegen - window könnte ja auch zukünftig mit einer gleichnamigen Methode/Eigenschaft erweitert werden, die mir dann des gleiche Problem bereitet.
gruß,
wahsaga
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }