blog.formatvorlage » JavaScript

Hack: Unbekannte Elemente im IE stylen

Claus — Wed, 13 Feb 2008 13:22:15 +0000

Gerade beim Aufräumen auf dem Schreibtisch einen Clip gefunden, den ich vor ein paar Wochen in einem Blog gefunden habe (ich glaube bei Simon Willison) und hiermit zum Freudenspender-Tip des Monats erkläre:

“If you want CSS rules to apply to unknown elements in IE, you just have to do document.createElement(elementName). This somehow lets the CSS engine know that elements with that name exist.”

- Sjoerd Visscher

Genau dieses Problem hat mich beim IE vor ein paar Jahren beim Versuch, eigenes Markup für ein Projekt zu entwickeln, so dermaßen angekotzt, dass ich es dann anders gelöst habe. Schlechter als geplant. Danke Sjoerd!

Firefox 3: Gran Paradiso Beta 7 mit Cross Site Access

Claus — Mon, 06 Aug 2007 09:38:03 +0000

Mozilla hat die siebte Beta Version von Gran Paradiso vorgestellt. Neben einem Haufen interessanter Änderungen ist das die aufregendste Neuigkeit: der W3C Draft “Enabling Read Access for Web Resources” wurde implementiert. Das bedeutet nicht mehr und nicht weniger als den Beginn einer Revolution im Web. Konnte man seit Beginn des Web zwischen Frames aus unterschiedlichen Domains nicht kommunizieren – außer mit dem zwar etwas merkwürdigen, aber funktionierenden Trick des Dojo Toolkit – und auch keine XMLHttpRequests auf eine fremde Domain absetzen, ist das mit dieser Spezifikation jetzt möglich. Möglich gemacht wird das durch einen Access Control Mechanism, der entweder als HTTP-Header oder XML Processing Instruction funktioniert.

Ein solcher HTTP-Header sieht folgendermaßen aus (Beispiel aus dem Draft):

Content-Access-Control: allow <*.example.org> exclude <*.public.example.org> Content-Access-Control: allow

Der erste Header erlaubt Cross Site Access aus allen Subdomains von example.org außer den Subdomains von public.example.org. Der zweite erlaubt den Zugriff explizit aus der Domain webmaster.public.example.org.

Beispiele von XML Processing Instructions:

Ich bin gespannt wie sich die noch nicht endgültige Fassung der Spezifikation weiter entwickeln wird und vor allem wann die ersten Sites und HTTP-Server diesen Mechanismus implementieren werden. Wie auch immer: das Web ist heute wieder ein Stückchen aufregender geworden

JavaScript Performance: Rhino vs. Spidermonkey

Claus — Fri, 13 Jul 2007 08:47:20 +0000

In den letzten Wochen hat sich einiges getan in Sachen JavaScript auf dem Server, siehe zum Beispiel John Resigs Posting “Bringing the Browser to the Server” oder mod_js. Die Idee ist mir schon seit einer Weile im Kopf rumgegangen: JavaScript eignet sich für Rapid Development und das Coding des Presentation Tier. In dem Maß, wie Web Applikationen zu “echten” Applikationen werden, sollte die Grenze zwischen Client und Server durchlässiger werden. Ganz abgesehen davon, dass JavaScript sexy ist. Die mit JavaScript 1.6 und 1.7 eingeführten Sprachfeatures wie Iteratoren, Generatoren und vor allem E4X haben es zu einer extrem interessanten Alternative zu etablierten Sprachen wie Java oder PHP werden lassen. Das größte Problem habe ich im Bereich der Performance erwartet, weswegen ich einige Testcases für einen kleinen Battle PHP vs. JavaScript geschrieben habe. Die Ergebnisse waren teilweise extrem überraschend, aber anders, als ich es erwartet habe.

Ich habe PHP 5.2.0, Spidermonkey JS 1.6.0 Final und Rhino 1.6R5 verwendet. Die beiden ersteren habe ich selber gebaut und Rhino als fertiges JAR verwendet. Als Java VM kam Java HotSpot (build 1.5.0_07-87, mixed mode, sharing) zum Einsatz. Getestet wurde das ganze auf einem 2 Ghz MacBook auf der Shell, indem ich meine Testfiles mit der Option -f spezifiziert habe. Die Zeitmessung wurde mit dem Kommando time durchgeführt, die angegebenen Werte sind jeweils die User Time. Die Testfiles wurden so identisch wie möglich implementiert, d.h. es kamen keine sprachspezifischen Erweiterungen zum Einsatz (für Test 2 hätte sich in JavaScript z.B. die Verwendung von Generatoren/Iteratoren angeboten).

Test	PHP 5.2.0	Rhino	Spidermonkey
Test 1: 10^8 mal ein wenig Arithmetik in einer Schleife	0m25.427s	1m33.396s	1m7.248s
Test 2: Berechnung der Fibonacci Reihe von 10, 10^6 Wiederholungen, rekursiv implementiert	0m30.410s	*0m7.376s*	*0m16.689s*
Test 3: 2 Klassen definiert, eine abgeleitete, 10^6 Wiederholungen: Instanz erzeugt, Superklassen Konstruktur aufgerufen, danach ein Boolscher Test und eine String-Verkettung.	0m9.451s	*0m4.061s*	*0m9.992s*

Ich muss sagen, dass ich von den Ergebnissen extrem überrascht bin. Ganz besonders bei Test 2 und 3 im Vergleich zu Spidermonkey und Rhino. Um das nochmal zu verdeutlichen: für Rhino muss eine Java VM initialisiert, das JAR eingelesen und die JavaScript Engine gestartet werden. Und trotzdem ist die Ausführungszeit für die Tests um mehr als Faktor 2 kleiner als für die in C implementierte Engine?! Auch wenn die verwendete Java VM einen Just-In-Time compiled, kann das doch wohl kaum schneller sein. Das muss mir mal bitte jemand erklären. Übersehe ich was?