für die Untoten

Seit Jahren dreht sich Frontend-Code nicht mehr um den IE6. Um halbwegs sauber zu coden und für Kunden und ihren IE6 ein vorzeigbares Ergebnis zu haben, empfiehlt es sich zu Dean Edwards IE7.js zu greifen. Im Nachgang sollte man allerdings so weit möglich mit CSS und Conditional Comments nacharbeiten.

Dann ist allerdings das Javascript viel zu fett und wenigstens im IE6 auch viel zu langsam. Und weil das Javascript nichts anderes als DOM-Manipulation macht und jQuery darin auch ganz gut ist, kann man sich ein eigenes IE7.js ganz schnell aus jQuery bauen.

Ich habe lange gerätselt, warum das Script bei komplexen Seiten derartig langsam ist. Der Grund sind imho beinahe ausschließlich Schreibprozesse, also das Hinzufügen von DOM-Nodes, hauptsächlich verursacht von den Pseudoklassen :after und :before. Sie weglassen ist keine Alternative, ich arbeite noch an einer Optimierung. Die Grundsätzliche Funktion des Scripts ist ziemlich einfach:


$.get(stylesheetUrl, function(data){
parsen(data);
});

Anders als die Stylesheets nachzuladen kommt man leider nicht an das komplette Stylesheet heran.


function parsen(data){
var lines = data.match(/[\s\w#,-\.>:]+:[\s\w#,-\.>:]+{[\w\W]+?}/gmi);
$.each(lines, function(i,val){
var style = val.split("}");
$.each(style[0].split(","), function(i,val){
if (val.indexOf(":after")>-1)
$(val.replace(":after", "")).after("<span style='" + style[1].replace("}", "") + "' />");
});
});
}

var line enthält alle Styleanweisungen auf Pseudoklassen. Daraus picken wir uns die :after-pseudoklassen heraus und hängen an die Selektoren ein span-Element mit den Style-Anweisungen. Gibt es eine content Anweisung, empfiehlt es sich, die Zeile umzuschreiben:


$("<span style='" + style[1].replace("}", "") + "' />").insertAfter(val.replace(":after", "")).html(content);

Hier kurz umrissen das weitere Vorgehen. Um wirklich nachhaltig zu arbeiten empfiehlt es sich, in parsen() erstmal ein Style-Object zu erzeugen, über das man dann iteriert.

Ach Menno…

Wenn man sich vorstellt, dass grün gut ist und rot schlecht, dass grüner entsprechend besser und roter schlechter ist, dann wird man folgende Grafik ganz gut interpretieren können:

worst

Erzeugt wird diese Grafik von der Seite wann kann ich …. Hier kann man ganz schnell nachsehen, wann man endlich Schriftarten einbinden oder Layouts mit runden Ecken bauen können wird. Die Grafik fasst das auch ganz gut zusammen: neuere Techniken lassen sich nicht nativ mit dem IE, egal welcher Version bis weit ins Jahr 2010 hinein nutzen – Microsoft schickt also die Webentwicklung in die Warteschleife. Ich hoffe, dass einfach mehr Entwickler den Mut haben, den IE nicht vollständig zu unterstützen.

Andererseits – und das muss man einfach wirklich auch nochmal hervorheben, geht es in dieser Liste um Features aus CSS3 und HTML5. Standardlayouts mit abgehangenen Methoden herkömmlichen Mitteln lassen sich inzwischen und vor allen Dingen dann im IE8 schon ganz gut umsetzen.

Aufhol – äh – Spaziergang

Wer die Blogs der Browser-Entwickler so liest, wird feststellen, dass bei Webkit und Opera unheimlich Gas gegeben wird. CSS3 wird nahezu voll unterstützt, html5 in Teilen – und nebenbei wird immer noch ein Quentchen mehr Geschwindigkeit herausgekitzelt.

Beim IE geht mans gemütlicher an. Klar, lastet auf den Redmondern die Last der Applikationsentwickler, die ihre VB-Scripte im Internet-Explorer laufen lassen. Dabei vergisst man dort aber, dass das Hauptaugenmerk eines Browsers das Internet ist. Und so liest sich auch die Liste der Features für den IE8 sehr konservativ:

  • The target for CSS support in IE8 is full and complete support for CSS2.1.
  • The only CSS3 module in IE8 is writing-mode (for vertical text support). IE has supported this since version 5.x, so it will continue to do so.
  • IE8 will not support CSS‘ border-radius, which is often used to make rounded corners without images. Microsoft’s Chris Wilson confirms that border-radius support is „high on the wish list,“ though, and should make its way into the next release after IE8.
  • There is no official roadmap for IE9, but native SVG support is likely.
  • A new JavaScript engine is likely down the road, too. A user asked: „Almost all others browsers are now considering JavaScript compilation. Safari introduced SquirrelFish and last week SquirrelFish extreme in reaction to V8. Mozilla has also started working on ScreamingMonkey. Will IE9 have a new JavaScript engine?“ The response: „We’re certainly focusing heavily on improving Javascript, in IE8 and beyond. I’d expect to see great things here in the future.“

(via)

Diese Lahmheit des Marktführers spiegelt sich leider immer auch auf die Entwicklung von Webapplikationen wider. Es ist eigentlich richtig, neue Standards, wie CSS3 oder sogar erste html5-Elemente einzusetzen – doch müsste man wieder eine Kompatibilitätsschicht programmieren, damit „der Neue“ aus dem Hause Microsoft die Seite auch halbwegs richtig darzustellen versteht.

Eigentlich allerhöchste Zeit, die Entwicklung der Engine an Webkit, Presto oder Gecko abzugeben. Die IE-Entwickler könnten dann zur eigenen Engine switchen, wenn der Browser im Intranet unterwegs ist – dann würde das Internet in seiner Entwicklung nicht so empfindlich und kostenintensiv ausgebremst durch Microsoft.

Das soll übrigens kein Statement gegen den IE8 sein. Er ist ein großartiger Browser. Besser, schneller, standardisierter als jeder Explorer zuvor – doch wenn er releast wird, kommt er einfach fast vier Jahre zu spät.

Microsoft bewirbt IE8

Beim Stöbern im Windowsupdate bin ich auf die IE-Seite geraten, wo sich mir folgendes Bild bot: Oben riesiges Banner mit dem IE8. Schneller, leichter, sicherer.

Weiter unten erst, als ginge es um orthopädische Unterwäsche, Informationen zum IE7.

getitnow - der neue IE8

getitnow - der neue IE8

Ich setze den Browser nun schon seit Monaten ein – und finde kaum noch einen Grund, nicht zu upgraden.