Codecandies

Das Weblog von Nico Brünjes.

window.onload, schon wieder

Kann ich nicht mehr hören! Seit Wochen hadere ich ernsthaft mit den typischen Problemen, die auftreten, wenn man Events nicht mit (bösen, bösen, bösen 1) inline-Eventattributen (“onclick”, etc.) zuordnen will (oder eben kann). Der Ladenvorgang eines HTML-Dokuments, vor allem eines sehr großen (hüstel), ist eine wacklige Angelegenheit, soviel kann man schon mal fesstellen. Da kann viel passieren: das DOM ist fertig, da wird vom Adserver noch etwas nachgeladen, huch, hier mal ein Flashlayer, der alles zerballert, der User klickt wild in der Navi herum, die immer noch nicht initialisiert ist, da funzelt noch ein AdBlocker dazwischen…

Konkret: es gibt natürlich verschiedene Lösungsansätze für das Problem, jQuery bedient sich der Methode von Dean Edwards für ihr eigentlich wunderbares jQuery.ready(). Nur, es funktioniert nicht immer. Und: was geht, und was nicht, hängt zu gut 60% von äußeren Umständen ab, also vom Browser, zusätzlich geladenen Skripten auf die man keinen Einfluss hat (Werbung) und wie schon gesagt, auch gerne mal einem Browserplugin. Und manchmal kommt auch ein ambitionierter Kollege und überschreibt alles mit einem fröhlichem onload. ;)

Ich stehe gerade kurz davor das Ganze wieder ganz altmodisch ins <body onload=""> zu verlegen, nur damit endlich Ruhe ist. Nein, da ist mir gerade nochmal Peter Michaux dazwischen gekommen. Er hat die einzelnen Methoden und Lösungen zumindest ordentlich analysiert und kommt zu ähnlichen Ergebnissen wie ich. Und hat eine Lösung.

My suggested solution trades a minor impurity in programmer ideals for an always functional UI. It’s an “if you can’t beat them, join them” solution. It’s a compromise but like Dan Cederholm’s compromise it is fixed string of attributes that is tacked on without any thought. It may be a challenge to build an efficient implementation of this solution but there is no hacking based on brittle browser features and no exposure. This solution depends only on documented browser features and behavior. That’s a compromise I can abide.

peter.michaux.ca

Peter hat eine Methode erdacht, die sozusagen das beste aus beiden Welten zu vereinigen weiss, nämlich jQuery.ready() und das hervorragende LiveQuery Plugin über das ich schon gestern kurz berichtet hatte. Ich werd’s testen.

1: Die Nutzung von inline-Eventattributen steht gegen die Trennung von Inhalt und Präsentation, der ich normalerweise anhängig bin. Ich bin zwar pragmatisch genug mich von soetwas zu kicken, wenn es drauf ankommt, aber da wir mit XML-Dokumenten arbeiten, die per XSLT in HTML gestyled werden, dass mit CSS gestyled wird… da geht das schon irgendwie zum Prozess. ;) Zudem machen unterschiedliche Leute die XSLTs und die Javascripte etc. Da sind solche Trennungen auch für den Arbeitsprozess mehr als praktisch. Wenn’s funzt zumindest.

2 Kommentare

  1. Oh ja, das Problem kenne ich, denn damit hab ich mich neulich auch rumgeärgert. Insbesondere funktioniert es mit jQuery nicht, wenn man Daten in einem iframe nachlädt, denn das ready() von jquery kehrt dann direkt zurück, denn das DOM existiert ja schon. Nur das DOM für den iframe nicht, in dem meine eigentlichen Daten stehen (und die Verwendung von Iframes ist nicht meine Designentscheidung). Ich hab mir jetzt beholfen, indem ich sowohl ready() als auch addLoadEvent (http://simonwillison.net/2004/May/26/addLoadEvent/) nutze. Funktioniert.

    Und an jedes Input-Element noch im HTML direkt einen onfocus und onclick handler zu setzen, das ist mir dann doch zu viel Arbeit und macht den Code zu unübersichtlich.

  2. > und die Verwendung von Iframes ist nicht meine Designentscheidung

    Ja, das kennt man. Mein Beileid. :)

    > an jedes Input-Element noch im HTML direkt einen onfocus und onclick handler zu setzen, das ist mir dann doch zu viel Arbeit und macht den Code zu unübersichtlich.

    Ja… hmhmhm… mit XSLT lässt sich sowas relativ leicht lösen. Macht den Code unübersichtlich stimmt aber natürlich.

    Das ist aber genau der Punkt des “Pragmatismus” den ich angesprochen habe: wenn es nicht anders geht: so what. Wie bei Dan Celderholm und cellspacing (das Beispiel im verlinkten Artikel).