nicht angemeldet
Hallo Felix,
sorry fürs threaddriften und Nicht-Beantworten Deiner Fragen, aber beim Kurzen Überfliegen Deines Artikels ist mir eine Verbesserung eingefallen, die langfristig vielleicht relevant ist oder sich eventuell schon jetzt in einem ausgebautem, nicht nur zu pädagogischen Zwecken genutztem Fader-Framework eignen würde.
Apple hat zwei Erweiterungen von CSS gemacht, das pragmatischere CSS Transitions und das erweiterte CSS Animations. Beide beschäftigen sich mit der Animation der Veränderung von CSS-Eigenschaften über einen definierten Zeitraum, also z.B. die Animation von opacity von 0% bis 100% über einen Zeitraum von ein paar Sekunden. Beide sind wohl schon in Safari/iPhone implementiert, Transitions laufen für viele Eigenschaften schon im aktuellen Safari 3.1. In diesem Blog-Eintrag gibt es drei Beispiele, woanders gibt es eine nette Demo eines OS X Dock Effektes. Denkt man weiterhin darüber nach, gibt es viele nette Möglichkeiten dafür. CSS Transitions und Animations wurden recht gut von der CSS Working Group aufgenommen. Arbeit an den beiden wird wohl in die nächste Charta der CSS-WG geschrieben. Auch bei Mozilla scheint man sich dafür zu interessieren, aber wohl leider erst zu Gecko 2.0 (= c.a. Firefox 4) dazu zu kommen. Aber ich meine langfristig haben diese Ideen wohl eine Chance, zumindest Transitions, und bleiben nicht nur Apple-spezifische Eigenschaften, syntaktische Änderungen mal vorbehalten.
Würde ich so ein Fader-Framework basteln, würde ich durchaus überlegen, das zu integrieren. Der Vorteil liegt auf der Hand: In der normalen Lösung – dem schrittweisen runterzählen der opacity-Wertes – liegt viel Handlung bei Javascript. Dekrementieren und Zuweisen, damit die Rendering Engine neu rendert. Warten. Dekre ... wieder warten. Besonders das ständige Warten dürfte bei vielfältiger, diverser Nutzung von JS in dessen Einzel-Thread-Umgebung ziemlich nerven. Bei CSS Transitions setzt man dagegen einen Start-Wert, einen End-Wert und den Verlauf dazwischen. Den Start der Transition löst man durch eine Veränderung im DOM aus, z.B. durch setzen einer Klasse oder durch Eintreten eines Zustandes wie :hover. Das konkrete In- oder Dektrementieren dagegen wird von der Layout-Engine übernommen, JS ist also frei von vielem nervigen Einzelschritten.
Dies ist natürlich der Idealzustand, in einer Cross-Browser-Umgebung muss man immer noch die nervigere Direktmanipulation für Deppenbrowser machen. Der grundsätzliche Unterschied zwischen beiden Lösungswegen dürfte auch für pädagogische Zwecke nicht wirklich hilfreichen komplizierteren Quellcode sorgen. Dennoch: Es lohnt sich bei einem Browser noch nicht, bei zwei Implementierungen wäre ich aber schon dafür zu haben.
Tim
Gunnar Bittersmann
Struppi