Als Alternative zur Apptisierung des mobilen Internets wird immer wieder die Webapp genannt. Ebenso oft wird betont, dass native Apps den Webapps in UI und Features überlegen sind. Die Browser holen jedoch langsam auf, z.B. mit der Möglichkeit Geodaten zu lesen, oder auch Zugriff auf eine im Smartphone integrierte Kamera zu erhalten. Und dann ist das noch das Feature der offlinefähigkeit. Im folgenden will ich einige Techniken dazu kurz anreissen, zum einen um (mir) einen Überblick zu verschaffen, zum anderen um feststellen zu können, wie weit wir denn technologisch heute sind, in Sachen offline. Zum über den Onlinezustand hinaus gehenden Speichern von Daten stehen im wesentlichen drei Techniken zur Verfügung.

DOM Storage

Als DOM Storage bezeichnet man einen kleinen, leicht zugänglichen Speicherbereich, auf den vom Browser über eine sehr einfaches Interface zugegriffen werden kann: es werden jeweils Key-Value-Paare gespeichert. Das DOM Storage kommt in zwei Ausführungen: als Localstorage ist der Speicher persistent, als Sessionstorage hält er nur bis zum Sessionende.

DOM Storage besticht vor allem durch die Einfachheit mit der man ihn nutzen kann und ist zudem weit verbreitet. Deswegen wird er wohl vielerorts als das Schweizer Messer der Offlineapplikationen angespriesen; ja, das wäre ja zu schön… die Wahrheit ist: DOM Storage is considered harmful, vor allem wegen seiner grausigen Performance. Zudem ist die Menge an Speicher, die man damit zur Verfügung bekommt ziemlich klein. Unter iOS stehen wohl nicht mehr als 5 MB zur Verfügung, da kann man eh’ keine großen Sprünge machen, auch wenn Androiden und Desktopbrowser mehr Speicher zu lassen.

Application Cache

Die Mutter der Offlinefunktionalitäten dürfte der Application Cache sein. Hier steuert man unter Zuhilfenahme einer Manifest-Datei, welche Dateien der Browser für die eigene Webapp in den Application Cache legt. Der Clou dabei ist, dass im Offlinezustand diese gecachten Dateien völlig transparent zur Verfügung stehen. Ohne die Meldung »Ey Alter, geh’ mal online« werden Bilder aus dem Cache geladen und Scripts interpretiert. So sollte es jedenfalls sein. Hier zeigt sich der Browser called Browser (aka. Android-Webkit) aus Android 3.2 etwas unwillig und beschwert sich per Popup, das man ja nun offline sei, nur um danach alles wie gewünscht zu verarbeiten.

Für den Application Cache gibt es auch etwas Javascript-Interface mit dem man bspw. den Cache leeren kann. Auch gut geeignet zum Debuggen, denn wegen der oben erwähnten Transparenz, sind Fehler manchmal etwas schwierig zu finden. Hilfreich: hier kann man seine Manifest-Datei validieren lassen. Wermutstropfen Nummer eins: auch der AppCache wird durch das störrische iOS auf einer Untergrenze von 5 MB festgenagelt.

Browserdatenbanken

Wer bis hier mit den vorgeschlagenen Möglichkeiten zurecht kommt, oder mit anderen Worten: wer nicht mehr als 5 MB offline zu speichern hat, der hat Glück gehabt, denn er ist nicht auf die DB-Funktionalitäten der modernen Browser angewiesen. Diese stellen zwar wesentlich mehr Speicherplatz zur Verfügung, selbst im mobile Safari kann man, nachdem der Nutzer zugestimmt hat, bis zu 50 MB Daten in Datenbanken speichern und offline wieder abrufen. Trotzdem steht man derzeit vor einem Schlachtfeld.

Auf der einen Seite steht WebSQL, dass zwar in vielen Browsern zur Verfügung steht (Chrome, Opera, Safari, Android Browser…), aber vom W3C letztendlich verschmäht wurde, weil alle Browserhersteller das gleiche Backend nutzten. Stattdessen arbeitet man nun an IndexedDB. Das wäre sicherlich eine genauso gute Lösung, ist aber zumindest zum heutigen Zeitpunkt nicht gerade verbreitet: Firefox kommt seit Version 4 damit, Chrome (ab 12) kann beides, IE 10 wird es haben hat es, eines Tages. Der neue Chrome für Android kommt ebenfalls mit IndexedDB. Momentaner Stand hier ist allerdings, dass sich die Implementierungen doch noch sehr stark unterscheiden, zwischen den Browsern, aber vor allem auch von einer Browserversion zur nächsten, die ja heutzutage praktisch wöchentlich kommen…

Da muss man sich dann natürlich fragen, ab wann sich der Aufwand lohnt, denn um eine Browser-Offline-Datenbank-Anwendung zu schreiben, braucht man schon ein paar ausgewachsene Abstraktionsstufen, um die Daten in allen Browsern ordentlich wegzuschreiben und auch wieder zu finden…

Ein Fazit

Es ist nicht alles Gold, was sich HTML5 nennt. Beim Storage geht es jedenfalls, vor allem bei den Datenbanken noch sehr holprig zu. Somit liegt die Grenze für Offlinedatenspeicherung doch sehr sehr sehr niedrig. Definiert wird diese Untergrenze regelmäßig von den iOS-Geräten, man könnte Apple verdächtigen, den Webapp-Entwicklern Steine in den Weg legen zu wollen, um seine liebgewonnene App-Welt zu schützen, aber andererseits, man will ja auch keine Verschwörungstheorien verbreiten. ;)

<picture>
        <source src="high-res.jpg" media="min-width: 800px" />
        <source src="mobile.jpg" />
        <!-- Fallback content: -->
        <img src="mobile.jpg" />
</picture>

→

→

→

Look up HTML5, CSS3, etc features, know if they are ready for use, and if so find out how you should use them – with polyfills, fallbacks or as they are.

Via Jens Grochtdreis.

→

Bootstrap is a toolkit from Twitter designed to kickstart development of webapps and sites. It includes base CSS and HTML for typography, forms, buttons, tables, grids, navigation, and more.

Via ALA.

→

Heute soll der/die/das Amazon Kindle Fire präsentiert werden. Bei paidContent.org noch schnell nachlesen, was man gestern noch darüber geglaskugelt hat.

Christian Krammer referiert eigentlich über den langen Weg zum Reset-Stylesheet, liefert stattdessen in den Kommentaren eine gute Erklärung, warum man immer noch em Nutzen sollte.

Beim Networking ist das beste Zeitmanagement kein Zeitmanagement, jedenfalls wenn man nicht Madonna treffen will, schreibt Simone Janson. Davon verstehe ich ehrlich gesagt nichts, da ich weder Zeit- noch Networkmanagement betreibe. Immer schön die toDo-Liste pflegen!

Und dann kauft ihr ein T-Shirt und dann geht’s auch mit den Standards.

Screenshot ZEIT ONLINE, Wissen Centerpage, iPad Version, Design: Information Architects

Liest man die gängigen Webdesign-Sites findet man eine Fülle von Tipps, wie man seine Website anpassen kann, damit sie auch auf dem iPad funktioniert. Der Tenor: mit css media queries ein paar zusätzliche Stylesheets für das iPad liefern, im Scriptteil ein wenig die Touch- und Gestureevents einsetzen, Flashvideos raus, Buttons größer: fertig! Das war nicht ganz das, was uns vorschwebte…

Das mit den media queries ist so eine Sache

Kurz gesagt: CSS media queries sind im Moment eine schicke und elegante Lösung, wenn man seine bestehende Website mit ein paar Handgriffen an die Gegebenheiten verschiedener, zumeist kleinerer, Displays anpassen will. Ebenso taugen sie sicherlich dazu, eine Web-App zu bauen, die nur auf Tablets funktioniert und im Desktopbrowser leer oder ungestyled bleibt (aber wer will das schon?). Für eine große Contentwebsite, die zweigleisig unter der gleichen Adresse unterschiedliche Styles an Desktopbrowser und Tablets ausliefert, sind sie jedoch (zumindest im Moment) nicht zu gebrauchen.

Das liegt zunächst einmal daran, dass mit Mediaqueries eingeschränkte Stylesheets zunächst mal allesamt heruntergeladen werden und dann entschieden wird, was angezeigt wird. Für den mobilen Einsatz und auch für den Tableteinsatz kommen sie damit kaum in Frage. Beim ersteren schon allein wegen der Downloadmengen, beim letzteren kommen wie die Erfahrung zeigt noch weitere Datenmengen an Javascript und z.B. größeren Bildern hinzu. Ein Fass ohne Boden.

Die von mir zunächst favorisierte Lösung führte aber dazu, dass nicht nur IEs kleiner Version 9 via conditional comments eigene Stylesheets zugeteilt bekommen mussten, auch Firefox 3.0 und kleiner können mit den mediumabhängigen Styles so gar nichts anfangen.

Ohne Javascript geht’s (derzeit) nicht

Und auf tut sich die böse Tür des user agent switching. Zwar gibt es eine Javascript-Lib, die css media queries gewissermassen emuliert, das ist aber ein weiterer gut 20kB großer Download ist, ein Monster mithin, das zudem nur mit Queries innerhalb von CSS-Dateien, aber nicht innerhalb von <link /> zulässt.

Stehen zusätzlich Anforderungen im Raum, dass auch ein Schalter zur Rückkehr zur klassischen Website eingebaut werden soll, oder wenn man feststellt, dass eben Tablet nicht geleich Tablet ist, man also für verschiedene Tablets noch kleinere Anpassungen vornehmen muss, dann ist man schnell dabei auf den user agent zu schauen. <interlude>Das vereinfacht übrigens auch gewaltig die Entwicklung der Seite, da man sie während des Bauens parallel zum iPad/iPad-Simulator auch im Firefox previewen kann. Das geht natürlich nur mit User Agent Switcher. Dann aber kann man den geliebten Firebug nutzen um wenigestens die Elemente auf der Seite und ihre Styles zu indentifizieren und auch das Scriptdebugging ein wenig zu unterstützen. Dinge die es auf dem iPad nicht oder nur sehr rudimentär gibt.</interlude>

Diese Lösung ist allerdings noch nicht das Endstadium, allein weil wir nach und nach die Site für weitere Tablets fit machen wollen. Im Laufe dieser Zeit werden wir auch das UA-switching wieder entfernen und durch bessere Methoden ersetzen.

Screenshot ZEIT ONLINE, Navigation, iPad Version, Design: Information Architects

Der Spass an der Entwicklung

Eins muss man gleich sagen: Entwicklung für Tablet (speziell das iPad) macht einen Heidenspaß. Zum einen ist die Touchbedienung faszinierend. Ich bin so einer, der ein mouse-over-Menü entwickelt und sich dann stundenlang daran erfreuen kann, wie beim Hovern über den Menüpunkt das Menü animiert ausfährt. Auf dem Tablet kann man solche Lösung praktisch zum Anfassen programmieren (natürlich ohne :hover). Ich habe das Menü bestimmt mehrere tausend Mal ausprobiert. Oder die Bildergalerien (obwohl ich da noch nicht zufrieden bin). Die Möglichkeiten des Webkit sind wirklich hervorragend und das geniesst man natürlich. Obwohl es auch ein wenig zu verführerisch ist, wenn man in die Hölle der Desktopbrowser zurückkehrt und feststellt, dass es da draussen immer noch Internet Explorer gibt… ;)

Kleinere Schlaglöcher

Ein paar Dinge waren allerdings echte Kopfnüsse. Da ist zum Beispiel der Viewport-Tag. Schon bei diesem Blog hier habe ich Probleme damit gehabt. über diesen einen Tag den Viewport und vor allem die Vergrößerung so zu setzen, dass es für iPad und iPhone gleichermaßen funktioniert. Das Design der iPad-Seite erforderte ganz klar ein:

<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">

Das passt allerdings nicht zu unserer Art, das iPhone zu bedienen. iPhone-Nutzer werden beim Besuch gefragt, ob sie die mobile Website besuchen möchten, oder die klassische Seite. Mit dem obigen Meta-Tag kann man diese dann aber auf dem iPhone nicht mehr skalieren. Für das iPhone empfiehlt sich eher:

<meta name="viewport" content="width=device-width">

Will man allerdings (für das iPad) zwei Ansichten für Portrait- und Landscapemodus präsentieren (vs. vergrößerte Portraitansicht im Landscapemodus), dann ist man auf das minimum-scale=1.0, maximum-scale=1.0 festgelegt.

Überraschenderweise kann man aber auch diesen Metatag per Javascript setzen! Es hat allerdings ein wenig gedauert, bis ich das einfach mal ausprobiert habe (hüstel). Außerdem musste dafür ganz schön an unserer Seitenstruktur geschraubt werden.

Wie geht’s weiter?

Zunächst mal kommen jetzt schnell weitere Tablets dazu, mit denen man die Seite betrachten kann. Es war leider schnell klar, dass man mit einem Schlag nicht alle Tablets bedienen kann. Mindestens an den Einstellungen des Viewports müssen Anpassungen gemacht werden, wahrscheinlich auch etwas CSS und Script. Wobei, wir wollen jetzt auch nicht jedes Tablet das neu auf den Markt kommt kaufen (der Gadgetjäger in mir fragt natürlich: »warum eigentlich nicht«). Man wird sehen, was sich am Tabletmarkt noch tut und was sich durchsetzt. Wir räumen zunächst mal dem Galaxy Tab von Samsung gute Chancen ein, und wenn RIM mit einem Tablet kommt, wird’s ja vielleicht auch nochmal interessant.

Abschließend sei gesagt, dass die Sache natürlich ein gutes Stück weit vom Design der Information Architects lebt, Oliver Reichenstein hat dazu einen schönen Artikel geschrieben, der auch die – ich nenne es mal so – medienpolitischen Hintergründe gut erfasst und viel von dem Geist beschreibt, der hinter dieser Webapp steckt.

Noch ein paar Artikel und Stimmen zum Thema: iPadMag, Editors Weblog, iPad Planet NL…

Was Jason Grigsby vor allem kritisiert ist, dass man um eine Anpassung bspw. für mobile Clients zu erreichen, mehr anstatt weniger Code hinzufügt:

The idea of adding more code—adding more to download—in order to optimize for mobile should be the first clue that this isn’t a good solution.

www.cloudfour.com

Das wäre natürlich kontraproduktiv und ist für große Websites, die sowieso schon immer mit ihrem Gewicht zu kämpfen haben auch tatsächlich keine Alternative. Zudem hat man ja auch keine Unterscheidung für die ausgelieferten Medien, bspw. Bilder. Große hochaufgelöste Bilder braucht man bspw. für das iPad, aber nicht für das kleine Display eines Mobiltelefons. Smartphones wie das iPhone4 fallen aus dieser Kritik aber eher heraus, lechzt es doch nach noch höher aufgelösten Bildern als der Desktopwebbrowser. Hier müsste dann je nach Nutzungssituation unterschieden werden.

Allen Lösungen gemein ist im Moment, dass die mit media queries spezialisierten Seiten, nur wenige kleine Effekte anbieten, bspw. schmalere Spalten, verkleinerte Bilder etc. Was aber, wenn die Seiten für das iPad und später auch das iPhone wirklich komplett anders aussehen sollen? Versucht man sämtlichen CSS-Code zu überschreiben, landet man schnell in der Codinghölle und das Gewicht der Seite explodiert. Ich habe mich nun gefragt, mal in Bezug auf das iPad (und andere Tablets) gesehen, deren Nutzung ich weniger als mobile Nutzung betrachte, wie man mit den media queries nun zwar genug, aber eben möglichst wenig CSS-Daten an die Browser schicken kann. Mein derzeitiger Lösungsansatz sieht so aus siehe Update am Ende des Artikels:

<!--[if IE]>
	<link rel="stylesheet" href="css/base.css" type="text/css" />
<![endif]-->
<link media="only screen and (min-device-width: 769px)" rel="stylesheet" href="css/base.css" type="text/css" />
<link rel="stylesheet" media="only screen and (min-device-width: 768px) and (max-device-width: 1024px)" href="css/ipad.css" type="text/css" />

Zur Erklärung: Zunächst mal werden die IEs bedient, die derzeitig nicht in der Lage sind media queries auszuwerten. Der bekommt ganz normal sein CSS geliefert. Die restlichen Stylesheets ignoriert ein IE dann geflissentlich. Alle anderen Browser widerum ignorieren die conditional comments und falls sie eine min-device-width größer 769px haben, laden und zeigen sie das normale base.css. Hernach folgt dann das CSS für das iPad, mit einem Query auf seine Werte abgestimmt.

Soweit zur Theorie. In der Praxis scheint das so zu funktionieren. Lädt man viele verschiedene CSSse, kann das allerdings schnell unübersichtlich werden, da alle nichtmobilen CSSse doppelt aufgeführt werden müssen.

Anregungen und andere Ideen sind mehr als willkommen.

Artikelbild: Some rights reserved by anarchosyn.

Update: Zwei Tatsachen haben inzwischen dazu geführt, dass ich selbst nicht mehr so überzeugt von dieser Lösung bin: 1. werden ob mit media queries oder ohne immer alle Dateien vom Browser gezogen. Man spart aber ggf. durch weniger CSS-Überschreiben, je nach Art und Größe der Styles; 2. wichtige Info: schon Firefox 3.0 kann keine CSS media queries.

Bei Opera gibt es genau zu dieser Frage nun ein ausführliches Tutorial: Building a custom HTML5 video player with CSS3 and jQuery. Ganz großes Kino.

→

Es hat sich längst rumgesprochen, unter dem Buzzword HTML5 hat die Entwicklung kleiner Applikationen im Web mit standardkonformen HTML, CSS3 und Javascript Einzug in die Welt der Webseiten gehalten. Eines Tages wird man wahrscheinlich doch noch davon sprechen können, HTML5-Seiten programmiert zu haben (oh-oh!).

Dabei sind die Apps die man jetzt schon kennt oft schwergewichtige Ungetüme aus HTML und vor allem Javascript. Das muss natürlich nicht so sein. Um all dem Rechnung zu tragen (und ein wenig Werbung zu betreiben) haben MIX (≅ Microsoft) und An Event Apart einen Wettbewerb ausgerufen: gesucht werden kleine HTML5-Apps, kleiner als 10K, wobei die Verwendung von jQuery, Prototype und Typekit als Webservices ausgenommen sind. Laufen sollen die Apps in der IE9 Preview, Firefox und einem Webkit Browser. Na, dann mal los…

Nun kommen natürlich wegen mir alleine zu wenig Teilnehmer zu einem Kongress, deswegen sind weitere hochkarätige Webexperten geladen worden, bspw. Jens Grochtdreis, Vladimir Simovic und Alvar Freude. Übergeordnetes Thema des Kongresses sind Lösungen für barrierefreie Webseiten, soll heissen es geht nicht mehr nur um die Technik und den Prozess, sondern vielmehr um Webangebote, die diese Techniken auch ein- und umsetzen.

Mehr gibt es auf der Homepage des WKE 2010 nachzulesen. Man sieht sich.

Dabei habe ich vor allem darauf Wert gelegt, viel der Techniken auszuprobieren, die ich in den letzten Wochen und Monaten gelernt und an anderen Stellen gelernt habe. Darum ist auch viel mehr unter der Motorhaube passiert, als die Dinge, die man nach aussen sehen kann. Namentlich sind das: Nutzung vieler neuer HTML5-Elemente, Verschlankung des CSS-Codes und Nutzung von CSS media queries um eine angepasste Version für das iPad und Browser mit verkleinertem Fenster anzubieten, Verschlankung des Javascriptcodes, Verbesserung der WordPress-Templates und meiner geliebten functions.php. Aber eins nach dem anderen.

Welcome figure und figcaption

Das neue HTML5-Element figure gehört wirklich zu den sinnvollen Elementen, die schon immer gefehlt haben. Bei figcaption allein bin ich mir nicht so sicher. Der Name zeigt schon, dass man Schwierigkeiten hatte, das neue Element zu integrieren. In einem früheren Stadium war es auch tatsächlich geplant, die Elemente in figure als Definitionslisten zu gestalten. Mit diese Semantik war man schlussendlich aber nicht zufrieden, weshalb man ein eigenes Element erfinden musste und das erhielt den üblen Namen: figcaption. What a word. Ihhhh. Aber sei’s drum, beide Elemente finden sich nun prominent in der Homepage wieder.

Außerdem habe ich die Seite, nicht nur visuell, sondern eben auch im Code, in sections unterteilt. Die HTML5-Elemente header, article , footer und noch ein paar mehr, waren schon vor diesem Relaunch Teil des Codes. Damit bin ich der HTML5fizierung der Seite schon ein ganzes Stück weiter gekommen, ganz abseits der Buzzwordklopperei, rein im Code. Nun müsste man die Elemente nur noch ordentlich in den Artikeln nutzen können, ohne das WordPress anfängt rumzumucken, aber da kümmere ich mich auch noch drum.

Eine neue Brotschrift gibt’s nun auch, hier geht Droid Serif ins Rennen und ersetzt die Georgia, wo sie kann.

CSS Media Queries

Man konnte ja schon vorher lesen, dass ich mich in der Vorbereitung auf das iPad schon ausgiebig mit den praktischen Media-Queries auseinanderhesetzt habe. Nun habe ich auch hier im Blog eine entsprechende Regeln implementiert. Ab sofort bekommen das iPhone im Portraitformat und Browser deren Fensterbreite unter 920px liegt, eine verschmälerte Version der Seite angezeigt. Das kann ja jeder, der mit einem modernen Browser hier vorbeischaut leicht nachvollziehen, sonst hier auch mal ein Beispiel: so sieht’s breit aus:

Und so die schmale Version, 620px-einspaltig. Eigentlich hatte ich die schmale Version im normalen Browser nur zum Testen genutzt, bis mir am Netbook auffiel, dass das natürlich auch für den Firefox durchaus Sinn machen kann.

Der eigentliche Seitencontent ist 940px breit, ich habe 20px Karenz gelassen, weil mir auffiel, dass wenn man bspw. genau 940px nimmt, der Sprung zur schmalen Version auch passiert, wenn er gar nicht nötig ist, zum Beispiel, wenn man das Fentser genau auf Contentbreite bringen will. Insgesamt stört mich der Moment des schwitchens ein wenig, das ist schade, das das so abrupt erfolgt.

@media only screen and (max-width:920px), only screen and (max-device-width: 768px) and (orientation:portrait) { … }

Für das iPad im Landscape-Modus wird übrigens kein spezielles CSS geliefert. Stattdessen habe ich versucht, die normale Seite so iPad gerecht wie möglich zu gestalten.

Zudem werden wohl nicht alle art directed Artikel in die schmale Version passen. Da kann der geneigte iPad-Nutzer ja noch den Landscape-Modus nutzen.

WordPress- und/oder Javascriptcode

Nach längerer Zeit bin ich auch mal dabei gegangen und habe meine functions.php ein wenig aufgeräumt. Da meine Templates immer ziemlich egozentrisch gestaltet sind, habe ich keine Plugins gebaut, sondern alles was ich an zusätzlichen Funktionen benötigte in diese Datei codiert. Kann man machen, ist wie gesagt nicht so freundlich, wenn man das Theme veröffentlichen will. In der genannten Datei hat sich die letzten Jahre über aber auch ziemlich viel Müll angesammelt, den ich ersatzlos entsorgt habe.

Für meine art directed Artikel habe ich mir ja selbst eine kleine Erweiterung geschrieben, mit der man zusätzliche CSS-Sourcen als Meta-Feld an den Artikel hängen kann. Ich habe mir nun das Art Direction Plugin nocheinmal genauer angesehen und es wieder verworfen, nicht nur wegen der dämlichen Zeile Pay your respects to print, get Art Direction. auf der Plugin-Seite, sondern auch weil ich es für überflüssig halte. Stattdessen habe ich meine Lösung erweitert und verbessert, sowie das Silbentrennungsscript als Option auch für andere Artikel zugänglich gemacht.

Womit wir beim Javascript sind, denn auch hier habe ich ein wenig den Hammer kreisen lassen. Früher globale Scripte, die nur auf einigen wenigen Seiten gebraucht wurden, werden nun nur noch an den entsprechenden Orten geladen. Dafür habe ich mit meiner selbstgeschriebenem Artikelgalerie mal wieder echten Betacode auf Euch losgelassen. Das ist wie immer work in progress.

Aber auch sonst hat sich SVG nicht sonderlich im Netz verbreitet: obwohl man beispielsweise in Adobe Illustrator schon lange nach SVG speichern kann, findet man ausser in der Wikipedia im Web nur seltentst SVG-Grafiken, dafür aber viele viele in Flash umgesetzte Vektorbilder. Im Gegenzug ist die Unterstützung des SVG-Standards in Webbrowsern auch nicht gerade vollständig: neueste Opera-Versionen bringen es auf eine Unterstützung von rund 95% des Standards, die Webkit(s) immerhin noch auf rund 83%. Die 3.7er Previewversion von Firefox bringt dagegen nur etwa 72% SVG-Umsetzung mit. Am weitesten hinten liegt natürlich die PLatform Preview von IE9 mit derzeit 29% (Quelle: Wikipedia). Aber da mag ja noch etwas kommen.

Soll man nun Microsoft danken, und sich darauf freuen, dass man in einigen Jahren endlich Vektorgrafiken auf seinen Seiten nutzen kann ohne den User ein Plugin installieren zu lassen? Mich dünkt, M$ setzt nun Jahre zu spät auf den alten SVG-Zopf, einzig um HTML5-Canvas auszulassen und damit einem ähnlichen Schicksal auszuliefern wie es SVG vor Jahren hatte. Denn zur Umsetzung von Canvas schweigt man bei Microsoft ausgerechnet. Noch ist es nicht raus, aber ich sehe das kommen (denkt an meine Worte).

SVG kann dabei zum Glück nicht mehr unter die Räder kommen, es ist längst platt gewalzt und begraben.

→

→

→

→