Jacqueline now features a development branch containing the latest changes to check multiple documents in a parallel fashion.
My first performance tests show that this boosts overall performance when checking large amounts of CSS selectors on multiple HTML documents. The next big step will be trunk-integration of this feature.
In the meantime check the dev-branch at http://code.google.com/p/jacqueline/source/browse/#svn/branches/threaded
Kurzes Update:
Auch bei Opera bemüht man sich natürlich die neuen Web Standards zu unterstützen und so gibt es seit Ende März ein Build das eine 100/100-Completion im Acid3-Test erfüllen soll (näheres im Entwicklerblog).
In diesem Build ist auch eine native Implementierung des Selectors API eingebaut. Die mit dem von mir aufgebauten Test-Szenario Ergebnisse zwischen 16 und 32ms erzielt.
Diese Werte lassen sich leider nicht 1:1 mit den anderen ermittelten vergleichen, da sie in unterschiedlichen Test-Umgebungen (Core2Duo 1.8 statt Core2Duo 2.6 – Windows XP statt Mac OS X) entstanden sind.
Seit einiger Zeit (2007 und davor) gibt es die Selectors API als Working Draft des W3C – wem sie noch nicht bekannt ist, hier wird sie nun kurz vorgestellt.
Die großen Neuerungen durch dieses API heißen querySelector() und querySelectorAll(). Mit ihnen kann man sich anstatt den DOM-Tree manuell zu durchlaufen sehr schnell (da im Browser zu implementieren) entweder eines oder alle DOM-Elemente zu einem CSS Selektor zurückliefern lassen. Doch wie sieht es mit der Unterstützung aus?
Da hierdurch in unterstützenden Browsern ein enormer Performance-Gewinn bei derartigen Operationen zu erwarten ist, halte ich dies für eine erfreuliche Entwicklung. Auf Surfin Safari gibt es dabei noch einige Beispiele, was sich damit sehr gut ausnutzen/umsetzen lässt.
Für alle Browser, die die Selectors API noch nicht implementieren (und das sind nach diesem Stand ja noch ein paar) gibt es aber auch einen netten Workaround: base2.DOM von Dean Edwards ist eine offene JavaScript Implementierung der Selectors API, ist somit Cross-Browser tauglich und bietet noch ein paar Fixes für fehlerhafte Selektor-Handhabung durch den Internet Explorer.
Verwundert hat mich nur, dass dieses API (wie schon so Einiges) sehr lange beim W3C liegt und erst jetzt so langsam davon Gebrauch gemacht wird. Bei mir in der Firma war dies ein völliges Novum. Ist es anderen schon länger bekannt?
Gestoßen bin ich auf dieses API während der letzten Frontend-Optimierungsmaßnahmen bei denen sich mir die Frage stellte ob es nicht möglich ist, ungenutztes CSS automatisiert zu erkennen und zu entsorgen. Nun damit geht das allem Anschein nach sehr gut. Ein willkommenes Thema für meine zweite Projektarbeit.
Für alle die es noch nicht wissen: mit der neuen iPhone 2.0 Software nehmen laut Entwickler-Tutorials von Apple auch ein paar neuere CSS-Regeln Einzug – diese werden aus dem bestehenden Webkit-Zweig mit in den mobilen Safari des iPhones übernommen.
So hatte Apple einige Webkit-eigene Techniken für den mobilen Safari entwickelt mit Hilfe derer sich Elemente mittels CSS animieren und transformieren lassen sollen. Es gibt Eigenschaften für Rotate/Skew, aber auch z.B. um Elemente an einem Pfad entlangzuführen.
Vorteil laut Apple dabei: Der Frontend-Entwickler muss kein JavaScript-Coding mehr schreiben um Elemente mittels setTimeOut/setInterval zu animieren. Er gibt nur noch die Animationsparameter über CSS an und für die Anzahl der Zwischenschritte und eine flüssige Animation soll dann der Browser sorgen. Netter Nebeneffekt: aufgrund der Architektur des mobilen Safari (oder genauer: von OS X) kann dies dann sehr einfach von der Grafik-Hardware beschleunigt werden (oder wird es bereits?).
Laut Mark Malone – Apple’s iPhone & Internet Technologies Evangelist, der diese und weitere neue Features vorstellt – sind diese Eigenschaften zur Aufnahme in den offiziellen CSS-Standard beim W3C eingereicht worden.
Es bleibt zu hoffen, dass Apple auf diesem Weg sich trotzdem weiterhin an Standards halten wird. Irgendwie fühle ich mich bei derartigen CSS-Eigenschaften an gewisse mittels CSS einfärbbare Scrollleisten in einem gewissen Internet Explorer erinnert. Natürlich wurde auch damals niemand gezwungen dieses Feature zu verwenden.
Näheres wird sich zeigen wenn in 4 Tagen das iPhone 3G mit der neuen iPhone 2.0 Software erscheint.
Was spricht gegen diese CSS-basierten Animationen? Nun, vom momentanen Standpunkt gehören Animationen dieser Art eher mehr zum “Verhalten” statt zur “Darstellung” eines Elements. CSS ist jedoch eigentlich nur zur Manipulation der Darstellung gedacht, um Verhalten zu beeinflussen gibt es JavaScript.
Ein Vorteil ergibt sich jedoch zwangsweise daraus, und dieser dürfte vielen Entwicklern im ersten Moment sehr gut schmecken: die lästigen JavaScript-Schleifen zum Animieren der Inhalte fallen weg. Die Idee, diese Interpolation den Browser übernehmen zu lassen ist also sicherlich nicht schlecht. Und wenn es nur einmal mehr die “Designfehler” der Plattform namens Web zeigt, für die wir täglich entwickeln.
Auch vor diesem Hintergrund ist es immer ratsam, sich an Standards zu halten und Entwicklungen mit einer gewissen Weitsicht einfließen zu lassen.