Browser
Montag01. Februar 2010

Die Frage stellt sich bei jedem neuen Webprojekt: Welche Browser/Browsergenerationen sollen unterstützt werden? Grenzt man die Fragestellung auf unser aller Lieblingsproblem, den Internet Explorer, ein, so lässt sich die Frage darauf reduzieren, wie man mit dem Internet Explorer 6 umgeht. Schleppt man ihn irgendwie mit (wird bei den meisten Projekten nach wie vor gemacht) oder ignoriert man ihn. Pfiffige CSS-Entwickler setzen auf Graceful Degradation oder Progressive Enhancement, um neben der schwarz/weiß Option (ja/nein) noch ein paar argumentative Graustufen einfügen zu können.

Doch so gern und trefflich die Blogosphäre sich auch über den IE6 und dessen Schwächen auslässt so gründlich wird in der Diskussion meist außer acht gelassen, dass auch andere Browser einem Alterungsprozess unterliegen. Wer testet denn heute noch ernsthaft seine Projekte gegen den Firefox 1, Safari 2 oder Opera 8? Der Firefox 1.0 beispielsweise stammt aus dem Jahre 2004 und hat damit ebenfalls bereits 5+ Jahre auf dem Buckel. Schon mal drüber nachgedacht?

In den Focus rückt diese Fragestellung bei mir durch Googles aktuelle Ankündigung, den IE6 bei den eigenen Applikationen nicht mehr zu unterstützen - worüber auch sofort wieder reichlich berichtet wird. Nur steht in Googles Ankündigung weit mehr als das Ende des IE6-Supports. Auch die nächste Generation der “Guten” - Firefox 2.x, Opera 9, Chrome 2.x usw. nähert sich dem Ende ihrer Unterstützung. Zwar findet man diese Aussage in dieser Deutlichkeit nicht in diesem Google-Blogpost, dafür beispielsweise bei Yahoo’s Aufstellung für den abgestuften Browsersupport der YUI Library.

Interessant an der Yahoo-Tabelle ist beispielsweise, dass selbst der Firefox 3.0 unter Windows Vista/7 bereits den A-Grade Status verloren hat. Von Opera ist generell nur die aktuelle Version 10 in der Liste vertreten und auch der Safari unter Mac nur in der aktuellen Version 4 gelistet wird. Alle älteren Versionen werden aktuell als B-Grade eingestuft. Sie werden selbstverständlich weiterhin unterstützt werden - jedoch bereits heute mit geringerer Priorität. Nun dreht es sich sowohl bei Google als auch bei Yahoo in allererster Linie um die JavaScript-Unterstützung/-Performance. In Sachen CSS ist es vor allem der Internet Explorer 6, der mit zahlreichen Bugs gesegnet ist, die Webentwicklern bei den immer komplexer werdenden Applikationen mehr und mehr zu schaffen machen. Doch auch bei den modernen Browsern werden die Unterschiede momentan eher größer als kleiner. Konkretes Beispiel: Die JavaScript-Performance des aktuellen Firefox 3.6 ist nicht einmal halb so gut wie die des Chrome 4. 

Abgestufter Browsersupport bei HTML5 & CSS3?

Die Frage, die ich deshalb in den Raum stellen möchte lautet: Wie geht man mit den älteren Generationen der “guten” Browser um? Ich klammere hier bewusst den IE 6 und 7 aus, mir geht es um Firefox 1.x,2.x,3.0.x, den Opera 8.x,9.x, den Chrome 1,2 oder auch Safari 1,2. Was die immer weiter wachsende Unterstützung für beispielsweise CSS3 und HTML5 angeht, so gibt es mit den älteren Generationen sicherlich weniger Probleme. Doch was ist mit waschechten CSS-Bugs?

Der Firefox 3.6 ist beispielsweise der erste Firefox überhaupt, der CSS-Tabellen endlich fehlerfrei darstellt. Alle seine Vorgänger hatten da so ihrer Schwierigkeiten. Der Firefox 2.x ließ teilweise Labels hinter Formularelementen verschwinden. Im Gegensatz zum Internet Explorer 6, der neben seinen zahlreichen CSS-Bugs ebenso zahlreiche Parser-Bugs mitlieferte, über deren Ausnutzung viele Probleme gefixt werden konnten, steht man bei den “guten” Browsern meist im Regen. Bugfixes für deren CSS-Probleme sind Mangelware. Mit der wachsenden Verbreitung von Firefox und Co. und den immer neuen Versionen/Generationen wird auch die Streubreite bei den Anwendern zunehmen und damit wird es zwangsläufig dazu kommen, dass diese Bugs “sichtbar” werden, wenn aktuelle Webtechnologien vermehrt Anwendung finden.

Wir beginnen gerade erst, die ersten graphischen Spielereien von CSS3 in unsere Projekte einzubauen. Ein falscher Schatten oder eine runde Ecke stellen in der Regel kein Problem dar. Doch wie sieht es aus, wenn wir damit beginnen, die neuen Layout-Module zu verwenden (Mehrspaltigkeit, Alternative Box-Modells, ect)? Das sind layoutkritische Elemente, was wenn hier Bugs auftreten, weil die ersten Implementationen noch nicht ausgereift waren - aber noch nicht vom Browsermarkt verschwunden sind?

Thema HTML5: Auch hier hat die Entwicklung deutlich an Fahrt gewonnen. Im letzten Jahr gab es reichlich Tutorials, wie HTML5 schon heute angewandt werden kann. Doch auch hier werden wir bei der aktuellen Geschwindigkeit Mühe haben, dass ältere Browsergenerationen von FF und Co. bereits aus den Statistiken verschwunden sind, bevor wir damit richtig anfangen zu arbeiten - oder wir warten bis 2020 (das will niemand wirklich, oder?). Dem Firefox 2 kann man nur sehr mühevoll den Umgang mit den neuen Elementen beibringen, vernünftiges Styling ist fast unmöglich. Für den IE7 und 8 gilt das gleiche, doch beide werden uns vermutlich noch eine ganze Weile begleiten.

Es bleibt spannend und unberechenbar ...

In die Browserwelt ist sichtlich Bewegung gekommen. HTML5 und CSS3 nehmen Woche für Woche weiter Fahrt auf. Die Performance-Entwicklung der JavaSript-Engines von Google, Safari und Opera (v10.5) eröffnet Möglichkeiten, die vor 1..2 Jahren noch völlig undenkbar waren - ganz unabhängig von den zahlreichen neuen Features, die uns durch jedes Browserupdate beschert werden. Jetzt also, wo der IE6 so langsam von der Bildfläche verschwindet, haben wir nicht zwingend Eitel Sonnenschein. Stattdessen wird sich der Focus einfach etwas verschieben, weg von dem einen zentralen Problembrowser hin zu den zahlreichen alten Browsergenerationen, welche die neuen Webtechnologien unzureichend oder fehlerhaft implementiert haben.

Nach so vielen vagen Gedanken würde mich Eure Meinung interessieren:

  • Wie geht mit der wachsenden Versionsvielfalt und den damit verbundenen Leistungsunterschieden um?
  • Wie reagiert Ihr auf Browserbugs, die sich nicht mehr so leicht fixen lassen, wie im guten alten Internet Explorer 6?
  • Wie handhabt Ihr die unterschiedliche Unterstützung von Standards (HTML5, CSS3)?

Entfernen wir uns wieder von “Graceful Degradation” und “Progessive Enhancement” weil die Leistungsunterschiede im Vergleich zu heute tendentiell geringer werden oder bleiben wir als Webentwickler so tolerant wie bisher und sorgen uns in Zukunft auch um die älteren Guten, auch wenn deren Aufkommen in der Statistik geringer sein wird als es der IE6 momentan noch ist?


Samstag07. März 2009

Im letzten Sommer habe ich in meinem Essay zu flexiblen Layouts (deutsch / englisch) ja für einigen Diskussionsstoff gesorgt. Im Rahmen dieses Beitrags hatte ich mir die Display-Statistiken von w3schools.com herangezogen, um darauf hinzuweisen, dass eine “Optimierung” von Webseiten auf eine feste Breite von 1024 Pixel Breite nicht wirklich Sinn macht, denn die absoluten Auflösungen und die damit verbundene Vielfalt steigen immer weiter an. Auf Basis der Statistik hatte ich damals eine Prognose für die Verteilung im Januar 2009 vorgestellt und diese gilt es nun, da die aktuellen Zahlen verfügbar sind, zu überprüfen.

Das Diagramm zeigt drei Graphen für Auflösungen von 800x600, 1024x768 Pixeln und alle darüberliegenden Auflösungen (Higher) als Volllinien. Die gestrichelten Linien entsprechen meiner Prognose für die Entwicklung bis Januar 2009 vom Juni letzten Jahres.

Wie man sieht, liege ich ganz schön daneben – im positiven Sinne. Denn der Anteil der höheren Auflösungen hat exponentiell zugelegt, während ich damals vorsichtig herangegangen war und damals nur eine lineare Zunahme angenommen habe. Dementsprechend ist auch der Anteil für die 1024x768 Auflösung kräftiger gefallen als vermutet. Während ich eine Abnahme auf ca. 42% geschätzt hatte, weist die Statistik aktuell nur noch 36% aus.

Das Gesamtbild verdeutlicht, wie vielfältig und nicht vorhersagbar die Randbedingungen sind, mit der Webseiten im Browser betrachtet werden. Zumal noch hinzukommt, dass der Browser selten im Vollbildmodus betrieben wird, sodass die noch ein weiterer Unsicherheitsfaktor (die Größe des Viewports) hinzu kommt. Ich selbst arbeite mittlerweile sowohl dienstlich als auch privat nur noch in Auflösungen von 1680x1080 oder darüber, der Brower lasse ich ausschließlich in einem Fenster laufen, ziehe jedoch das Fenster meist sehr weit auf, um beim Surfen nicht von anderen Applikationan abgelenkt zu werden. Die Viewportbreite meines Browserfensters liegt daher gewohnheitsmäßig (je nach dem, an welchem Rechner ich gerade sitze) zwischen 1400 und 1600 Pixeln. Das war auch der Grund, weshalb ich das Layout dieser Seite flexibel gestaltet und für große Auflösungen entwickelt habe.

In diesem Zusammenhang auch spannend, die aktuelle Display-Statisik von YAML.de, eine Seite mit recht ordentlichem internationalen Besucherverkehr. Wie man sieht, ist der Anteil der 1024er Auflösung mit 12% bereits deutlich niedriger. Den größten Einzelposten kann die 1280er Auflösung für sich beanspruchen mit 43%. Zusammen mit der 1024er sind das knapp über die Hälfte aller User. Das zeigt zum einen, dass der allgemeine Focus für die Breite einer Webseite sich in diesem Bereich bewegen sollte (alles andere hätte auch verwundert). Aber man sieht auch wie kräftig 1440, 1680 und die HD-Auflösung mit 1920 Pixeln Breite mittlerweile vertreten sind. Und für diese drei Auflösungen prognostiziere ich für Januar 2010 einen weiteren deutlichen Anstieg, während die kleineren Auflösungen, einschließlich der 1280er Breite stark federn lassen werden.

Egal, für welche Breite man letztlich sein Layout auslegt. In jedem Fall sollte die Zentrierung einer linksbündigen Anordnung vorgezogen werden. Denn bei einer fixen Breite von 760px bedeutet das schon bei der 1280er Auflösung, dass 40 Prozent der Viewportbreite ungenutzt bleiben. Steigt die Auflösung beim User - oder werden Inhalte innerhalb des Layout nicht über die volle Breite darsgestellt (typisch für Mehrspaltenlayouts), verschiebt sich das Verhältnis im Regelfall noch weiter in die Richtung, dass der ungenutzte Raum dominiert.
 


Mittwoch25. Februar 2009

Seit gestern macht die Heise-Meldung über die Fa. Xenocode und ihre virtualisierten Webrowser, welche in einer Sandbox laufen und somit keine lokale Installation benötigen, die Runde in diversen Blogs und bei Twitter. Zitat aus der Heise-Meldung:

“Auf der Website des Herstellers Xenocode stehen sieben verschiedene Browser zum Download bereit, die in ausführbare .exe-Dateien verpackt sind. Damit können etwa Webentwickler ihre Kreationen direkt in einem Internet Explorer der Versionen 6, 7 und 8 sowie in Chrome, Safari, Firefox und Opera testen.”

Ich habe heute morgen die IE-Varianten kurz getestet und kann nur ausdrücklich davon abraten, diese Pseudo-Sandbox-Tools zu verwenden. Auf meinem XP Rechner war nach einem einminütigen Test des Sandbox-IE6 mein lokal installierter IE7 unbenutzbar und musste vollständig neu installiert werden (auch ein Reboot zuvor hatte keine Besserung gebracht). Im selben Atemzug, in dem ich das Dilemma bemerkte, flatterten bereits ähnlich klingende Problemmeldungen von Freunden (Jens Grochtdreis, Tom Klingenberg) bei mir ein, leider in beiden Fällen für mich ca. 10min zu spät.

Die Kommentare unter dem Heise-Newsartikel füllen sich übrigens auch zunehmend mit Problemmeldungen, die darauf schließen lassen, dass es sich hier um alles andere als eine saubere und vollständig gekapselte Sandbox-Lösung handelt.

Deshalb: Finger weg von den Dingern!

Für den Test des Internet Explorers ist der IETester nach wie vor die empfehlenswerte und sicherere Alternative, von Firefox gibt es portable Versionen bei portableapps.com. Für Opera, Safari und Chrome ist mir zwar momentan nichts gleichwertiges bekannt, jedoch lassen sich diese Browser leicht installieren und auch wieder rückstandsfrei aus dem System entfernen. Weiterhin gibt es von Microsoft aus Basis von VirtualPC kostenfreie virtuelle Maschinen für IE6 und IE7, auf denen man ebenfalls beliebig viele Browser störungsfrei nachinstallieren und ausprobieren kann. Und zum Abschluss wären dann noch VMWare oder VirtualBox als weitere, zuverlässige Virtualisierungslösungen zu nennen.


Montag03. November 2008

Wer Webseiten auf möglichst schnelle Ladegeschwindigkeit hin optimieren will, benötigt spezielle Tools, um die Ladereihenfolge und die Ladezeiten zu protokollieren, denn diese bilden die Grundlage für die Suche nach Performance-Stellschrauben bzw. sie geben Hinweise auf die Ursachen bei Performance-Problemen.

Für den Firefox gibt es den Netzwerk-Reiter in der Firebug-Extension (v1.2.1), welche eben diese Auskünfte liefert. In einem Balkendiagramm werden vertikal die einzelnen Objekte entsprechend der Reihenfolge ihrer Anforderung beim Server aufgelistet, horizontal verläuft die Zeitachse, welche Aufschluss über den Start des Requests und die Zeit bis zum erfolgreichen Abschluss des Ladevorgangs gibt. Nach dem erfolgreichen Seitenaufruf lassen sich für jedes geladene Element Detailinformationen ausgeben, wie etwa den Cache-Status des Objektes, Lebensdauer im Cache ect. abrufen. Kleiner Nachteil: Firebug stellt den Zeitraum zwischen der Serveranfrage und dem erfolgreichen Abschluss des Ladevorgangs undifferenziert dar und gibt keine Auskunft über Latenzzeiten und effektive Ladezeiten.

Für den Safari 3.x übernimmt die Netzwerk-Timeline des Web Inspectors (dem im Safari eingebauten Developer-Tool) diese Aufgabe und unterscheidet farblich zwischen Stylesheets, Grafiken und JavaScript-Dateien. Die Anzeige differenziert aktuell jedoch auch noch nicht zwischen Warte- und effektiven Ladezeiten (Die akutellen Nighty-Builds der Webkit-Engine sind wohl hier schon besser). Wie auch beim Firefox bringt ein Klick auf das jeweilige Objekt weitere Detailinformationen hervor.

Für den Opera-Browser habe ich leider bisher kein solches Tool ausfindig machen können, dafür jedoch – man höre und staune – für den Internet Explorer 6 und 7 ... von AOL. Das Tool nennt sich AOL Pagetest und kann sowohl unter XP als auch unter Vista einfach installiert werden und steht dann im Browser über das Extras-Menü zur Verfügung.

Und bei dem AOL Tool habe ich dann wirklich gestaunt, dieses weist ausgesprochen ausführlich in Zahlen und mit Farbkodierung im Diagramm Latenzzeiten und Ladezeiten gesondert aus - Respekt. Und weil das noch nicht reicht, gibts das Tool gleich noch als Webdienst, der neben dem IE7 und der aktuellen Beta2 des IE8 dem Nutzer auch die Wahl zwischen einem einmaligen Seitenaufruf und wiederholten Aufrufen ermöglicht, um die Auswirkung des clientseitigen Cachings zu berücksichtigen. Ganz großes Kino von AOL.


Dienstag02. September 2008

Die Meldung schlug gestern ein wie eine Bombe. Lange wurde darüber spekuliert – nie wurde es bestätigt. Seit gestern weiß die Welt – Google geht mit einem eigenen Browserprojekt an den Start. Näheres verraten die Entwickler im offiziellen Google Blog.

Chrome soll er heissen und gleich für heute, den 2. September verspricht Google eine erste öffentlich zugängliche Testversion für Windows-Systeme. Wir dürfen also gespannt sein, sobald es Neuigkeiten gibt, werde ich diesen Beitrag updaten.

Wer sich vorab schon etwas über die Intentionen, die zu diesem Schritt führten, schlau machen will, für den haben die Entwickler ein recht umfangreiches Comic aufgelegt. Natürlich im typischen blaß-blauen Ton.

Auch der Spiegel widmet sich bereits heute morgen dem Thema mit einem längeren Beitrag (waren die etwa schneller als Heise?). Es ist nicht unbedingt so, dass die Welt zwingend eine Alternative zu Firefox, Safari, Opera & Co. benötigt. Was man von Chrome zu halten hat, wird sich in den nächsten Wochen zeigen. Ich für meinen Teil hoffe auf frische Ideen und ein frisches Konzept für die Neuentwicklung.

Update: Der Browser steht mittlerweile in einer Betaversion für Windows XP und Vista zum Download zur Verfügung. Dank der Webkit-Engine ist die Rendering-Qualität exzellent, die JavaScript Engine erscheint nach einem kurzen Test relativ schnell zu sein und Dank der Übernahme des Firefox-Nutzerprofils kann man sofort mit den eigenen Bookmarks mit dem Surfen starten. Es sind erst 10 Minuten aber Chrome fühlt sich unter Vista nach dem ersten Eindruck recht knuffig und schnell an. Wir werden sehen, ob das Gefühl anhält ...


Seite 1 von 5 Seiten

 1 2 3 >  Letzte »