Archive for the ‘Webkit’ Category

Selectors API in Firefox 3.1

Tuesday, July 29th, 2008

Ich war erfreut zu lesen, dass Firefox 3.1 mit Gecko 1.9.1 nun ebenfalls das Selectors API unterstützen wird.

Gleichzeitig ist mir ein Artikel von John Resig vom 10. Juli aufgefallen, der sich ebenfalls mit einer Test Suite für das Selectors API beschäftigt. Im Gegensatz zu den Performance-Tests werden in dieser Test Suite die einzelnen Implementierungen auf ihre Vollständigkeit der Selektoren hin überprüft. Mir waren bei Webkit/Safari schon Fehler bei etwas “exotischeren” Selektoren aufgefallen, was sich hiermit bestätigt hat. Die Implementierung Firefox 3.1 hingegen deckt laut Artikel schon weite Teile (ca. 70%) der Selektoren ab.

Ich werde mir in den nächsten Tagen eine Alpha-Version von Firefox 3.1 besorgen und hier ebenfalls die Performance testen.

Selectors API – mehr Komfort statt Durchlaufen des DOMs

Wednesday, July 9th, 2008

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?

  • In Webkit der Engine z.B. von Apples Safari ist die Selectors API laut einem Blog-Eintrag auf Surfin-Safari bereits implementiert (Stand: Februar 2008)
  • mit der iPhone 2.0-Software wird diese Webkit-Neuerung laut Apple Entwickler-Tutorials auch in den mobilen Safari aufgenommen
  • In Gecko steht eine Implementierung laut der Task List vom 23. April 2008 noch aus, ob dies mittlerweile erfolgt ist geht aus der Seite nicht hervor
  • Auch bei Opera wird an einer Implementierung gearbeitet, laut Opera Core Concerns, dem offiziellen Entwicklerblog wurde es erstmals in ein Acid3-Build eingebaut, ob dieses mittlerweile offiziell ist geht aus dem Eintrag leider auch nicht hervor
  • Im IE 8 Beta 1 Build ist die Selectors API laut einem Blog-Eintrag überraschenderweise ebenfalls bereits eingebaut

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.

Apple “erweitert” Funktionsumfang von CSS

Monday, July 7th, 2008

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.