Posts Tagged ‘Webkit’

Google Wave and IE-Support

Friday, September 25th, 2009

So after all Google has developed its Chrome Frame plugin for Internet Explorer for a good reason: enabling the majority of users – which are unfortunately still using Internet Explorer (6,7 AND 8) to have a better experience with HTML5-based websites.

Lars Rasmussen posted on the Google Wave Developer Blog that Wave will inform Internet Explorer users to install Chrome Frame for a better user experience. Reason being that Internet Explorer is just too slow at interpreting JavaScript and DOM Manipulations – features Wave heavily relies on. IE’s support of modern web standards such as HTML5 is pretty poor, too.

I’ve been experiencing the same issues with IE over and over for myself – yet in a smaller dimension: Every hour (and it have been many hours) a developer spends on the specific quirks on IE (which of course are different per each version) and to fix them for their application is not spent on adding cool new features or bug fixes which affect general issues.

Since this has been a problem for so a long time I hope this finally helps to fix this issue.

Firefox 3.1a testet Selectors API

Saturday, August 9th, 2008

Laut John Resig wird in Firefox 3.1 mit der nächsten Gecko-Version ebenfalls eine native Unterstützung für das Selectors API eingebaut sein. Ich habe mir eine Nightly-Version von Firefox 3.1 (Minefield 3.1a2pre) für Mac OSX geholt und sie über meinen kleinen Test-Parcour geschickt. Die Ergebnisse sprechen für sich. Im Vergleich zur Javascript-Implementierung via Base2.DOM zeigt sich hier ein Bild ähnlich dem in Safari 3.1:

  • beim Test mit querySelectorAll fällt die Zeit von 235ms im Mittel auf 25ms
  • bei querySelector sind es nun 17ms statt vorher 151ms

Damit erreicht Firefox 3.1a zwar nicht ganz die bisherigen Spitzenwerte von Safari 3.1 (11ms/8ms) holt aber mächtig auf.

Auch bei Opera schläft man nicht und so gibt es seit Ende März ein Acid3 build von Opera das ebenfalls eine native Implementierung des Selectors API besitzt. Auch dafür werde ich die Performance testen, sobald ich dazu komme.

Gleichzeitig arbeite ich an einer neuen Version des Benchmarks um alltagstaugliche Testergebnisse zu erbringen. Die Arbeit an meinem eigenen kleinen Tool zur Nutzung des Selectors API steht momentan ein bischen hinten an.

YUI Selectors, base2.DOM und Webkit im Vergleich

Monday, July 21st, 2008

Über das Selectors API wurde hier schon mehrfach berichtet. Nun hat mich Daniel Wiegand auf etwas hingewiesen: in der YUI gibt es ebenfalls etwas zum Überprüfen von CSS-Selektoren auf den DOM-Tree: das Selector Utility, das zwar eine ähnliche Funktionalität bietet, streng genommen aber keine Implementierung des Selectors API darstellt.

Ein Blick auf die Performance: Wie schlagen sich hier die beiden Javascript-Lösungen im Vergleich zur nativ in den Browser eingebauten Variante von Webkit? Und wie schnell sind verschiedene Browser bei den einzelnen Disziplinen im Vergleich?

Angetreten sind hierbei drei Kandidaten in vier Disziplinen:

  • Mozilla Firefox 3.0.1
  • Opera 9.51 und
  • Safari 3.1.2

werden getestet in

  • 1. Selectors API – find all (alle DOM-Elemente finden)
  • 2. Selectors API – find first (nur das erste DOM-Element finden)
  • 3. YUI selector – find all (analog zu 1.)
  • 4. YUI selector – find first (analog zu 2.)

In allen Diagrammen gilt: kürzer heißt schneller heißt besser.

In diesen Tests wird die Performance-Überlegenheit des nativ in Webkit eingebauten Selectors API gegenüber einer Javascript-Implementierung mittels base2.DOM deutlich. So musste die Anzahl der Iterationen von ursprünglich 10 auf 100 erhöht werden um in Safari messbare Ergebnisse zu erhalten. Firefox 3 und Opera 9.5 hinken hier gewaltig hinterher.

Die nächsten Diagramme zeigen die Ergebnisse von Test 3.) und 4.):

Auch hier kann sich der Safari klar von Firefox und Opera absetzen, allerdings ist der Firefox diesmal etwas schneller als der Opera. Der Safari profitiert deutlich von seiner sehr schnellen Javascript-Engine.

Am Ende ein Vergleich aller Performance-Daten:

Nach diesen Zahlen ist die Implementierung des Selectors API mittels base2.DOM meist schneller als die Nutzung des Selector Utility der YUI. Unerwartet deutlich sind dagegen die Vorteile einer nativ eingebauten Implementierung, bei dieser Verarbeitungsleistung steht einem Einsatz der Selectors API eigentlich nichts mehr im Wege.

Das Test-Senario: Auf ein simples Test-XHTML-Dokument verschiedene CSS-Selektoren überprüft, nicht alle sind im Dokument vertreten, einige dagegen mehrfach. Ein Durchlauf besteht aus 100 Iterationen über das Testarray bestehend aus 10 Selektoren. Aus den Ergebnissen von 5 Testdurchläufen wird jeweils das arithmetische Mittel gebildet.

In den Tests der Selectors API nutzen Firefox und Opera die base2.DOM Implementierung (da sie keine native Unterstützung bieten) – Safari macht von der in Webkit eingebauten Version Gebrauch. Alle Entwickler-Erweiterungen und Tools wie Firebug für Firefox oder Dragonfly für Opera waren deaktiviert.

Als Testsystem diente ein Apple MacBook Pro (2.5 GHz Intel Core 2 Duo Prozessor und 4 GB RAM) mit Mac OS X 10.5.4.

Die Testdokumente sowie ein PDF mit allen Ergebnissen sind hier zu finden:

Einen Test auf Microsofts Internet Explorer konnte ich leider nicht durchführen da ich kein natives Windows mehr besitze.

Außerdem ist noch anzumerken dass dieser Test keinen Anspruch auf wissenschaftliche Korrektheit, noch auf Vollständigkeit oder Alltagstauglichkeit erhebt. Er dient nur zum einfachen Überblick über die mir bekannten Methoden anhand von CSS-Selektoren Elemente innerhalb eines DOM-Trees zu finden.

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.