SVG - Flash-Killer oder Totgeburt?

Einfhrung

Glaubt man einigen Ideologen, macht SVG, das Vektor-Format fr das Web, zurzeit Furore; hin und wieder ist sogar davon zu lesen, es handle sich hierbei um "The Next Big Thing". Glaubt man jedoch unabh舅gigen Statistiken und Berichten, so stockt die Verbreitung des Formats. Liegt es am berm臘htigen, propriet舐en Konkurrenten SWF? Wo liegen die Unterschiede? Fragen, die in diesem Beitrag zumindest ann臧ernd gekl舐t werden sollen.

Der Lebenszyklus vieler neuerer Technologien verl舫ft h舫fig mehrstufig. Zun臘hst wird die Technologie ber den Klee gelobt, teils ideologisch getrieben ("es ist Open Source, also per definitionem gut" oder auch "es ist teuer, das brgt fr Qualit舩"), teils aufgrund einer Nachrichtenflaute verschiedener Publikationen, teils sogar gerechtfertigt. Nach einiger Zeit ist jedoch kommt es zu einer kritischen Phase. Der Hype legt sich, die breite Masse fordert nach echten Vorteilen einer Technologie und realit舩snahe Anwendungen, die weit ber einen anf舅glichen "Proof-of-Concept" hinausgehen. Gelingt dies, hat die Technologie eine Chance, ein Misslingen hat oftmals den Tod des Konzepts zur Folge. Ein Beispiel fr ein Scheitern ist WAP, das Wireless Application Protocol. In den Jahren 1999 bis 2001 stets in den Medien, scheiterte es zun臘hst an den nur sp舐lich vorhandenen Mobiltelefonen und sp舩er an den sagenhaft schlechten ﾜbertragungsraten. Trotz einer wirklich guten Technologie ist WAP heute nur eine Randnotiz der Internetgeschichte und dient nur noch als traische Anekdote fr eine Mischung aus vorschneller, undifferenzierter Begeisterung und unzureichender Untersttzung sowohl von Hersteller- als auch von Anwenderseite.

Einige Stimmen befrchten, dass SVG, dem Scalable Vector Format, ein 臧nliches Schicksal bevorstehen knte. Das vom W3C abgesegnete Format fr Vektoranimationen im World Wide Web hat eine technologisch gute Grundlage. Die Frage ist nur, wie der n臘hste Schritt aussieht: Gibt es demn臘hst sinnvolle und berzeugende SVG-Anwendungen? Wann wird das Format auch auf wirklich groﾟen Websites eingesetzt, wann wird das Stadium der reinen Demos wirklich verlassen?

Eine gute Messlatte sind die verschiedenen Publikationen zu diesem Thema. Nur eine Handvoll Autoren besch臟tigt sich mit der Technologie. Die Reaktion auf Artikel ist zahlenm葹ig allerdings mau. In vielen F舁len melden sich lediglich vermeintliche "Mitstreiter", bedanken sich fr die "Untersttzung" (sic) und bem臾eln jedes kritische Wort. So wird sich das Format sicherlich nie durchsetzen, das steht zweifelsohne fest.

Dieser Beitrag zeigt an einigen Beispielen, wozu SVG f臧ig ist. Dabei wird h舫fig ein Vergleich zum SWF, dem Small Web Format gezogen. Dieses halbpropriet舐e Format wird von der Firma Macromedia entwickelt; deren Flaggschiff-Editor "Macromedia Flash" diese so genannten Flash-Filme erzeugen kann. Halbpropriet舐 ist das Format deswegen, weil Macromedia die Formatspezifikation zwar verfentlicht, allerdings das Format unter der eigenen, strikten Kontrolle hat. Zun臘hst als stumpfes Format fr nervige, zappelnde Website-Intros verpt, ist der Feature-Umfang mittlerweile stark angewachsen und nicht nur Spiele, sondern auch professionelle Anwendungen mlich. Das Versprechen, dass die verschiedenen Browser-(In)kompatibilit舩en durch das SWF-Format umgangen werden knen, ist sehr verlockend. Hier verspricht SVG ﾄhnliches - sowohl SWF als auch SVG werden durch ein eigenes Plugin im Browser dargestellt; Browser-Bugs sind somit in der Regel nicht entscheidend, da sich alles innerhalb des eingebetteten Bereichs abspielt.

SVG-Elemente

Als Vektorgrafikformat untersttzt SVG alle primitiven geometrischen Figuren und bietet so maximale Flexibilit舩, da sich alles auf Basis dieser Formen darstellen l舖st. Ebenfalls sind zahlreiche Filter mlich. Dritte groﾟe St舐ke sind die Animationsmlichkeiten, welche auch ohne Programmierkenntnisse erstaunliche Effekte ermlichen. Hier ein illustratives Beispiel:

<?xml version="1.0" ?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

<svg width="200px" height="200px">
  <defs>
    <radialGradient id="orange" cx="60%" cy="60%" r="80%" fx="60%" fy="65%">
      <stop offset="0%" style="stop-color:rgb(234,152,55)" />
      <stop offset="100%" style="stop-color:rgb(0,0,25)" />
    </radialGradient>
  </defs>
  <circle id="ball" cx="100" cy="-50" r="50" style="fill:url(#orange)">
    <animateMotion dur="5s" path="M0 0 Q10 400 50 -50" />
  </circle>
</svg>

SVG-Scripting

Statische Animationen alleine knen nicht dafr sorgen, den Platzhirschen Flash auch nur ansatzweise zu verdr舅gen; Dynamik muss her. SVG setzt hier auf einen weiteren W3C-Standard, ECMAScript. Durch das eigene DOM eines SVG-Dokuments ist es mlich, auf jedes Element in der SVG-Datei per Skript zuzugreifen und zu modifizieren. Ein klarer Vorteil gegenber Flash, wo der Film nicht in einer hierarchischen Baumstruktur zur Verfgung steht. Somit sind - entsprechende Programmierkenntnisse vorausgesetzt - den Bemhungen, dynamische SVG-Applikationen zu erstellen, kaum Grenzen gesetzt.

In diesem Vorteil liegt allerdings auch gleichzeitig ein groﾟer Nachteil begrndet: So flexibel die Animationen auch sein men, Nicht-Programmierer haben hier kaum eine Chance, ansprechende Ergebnisse zu erzielen. Da die Editoren-Situation zurzeit eher trist ist, ist fr die meisten Grafiker zurzeit ein Umstieg auf SVG nicht attraktiv genug. Der Flash-Editor ermlicht es dagegen sogar, bestimmte Befehlsabl舫fe innerhalb eines Flash-Films "zusammenzuklicken".

Ein weiteres groﾟes Manko von SVG sind Tastatureingaben. Die Behandlung von Tastatur-Ereignissen ist im DOM-2-Standard, der von SVG untersttzt wird, nicht vorgesehen. Der Adobe SVG Viewer untersttzt dennoch Keyboard-Events, allerdings ist dies ein Entgegenkommen der ASV-Entwickler, nicht Teil des SVG-Standards. Eine weitere sinnvolle, aber nicht standardgem葹e Erweiterung des ASV ist die Mlichkeit, im Hintergrund serverseitig Daten auszutauschen und somit eine Interaktion mit dem Webserver durchzufhren, ohne dass die HTML-Seite, die das SVG-Dokument enth舁t, neu geladen werden muss. Dies ist in Flash schon seit L舅gerem mlich, bei SVG jedoch nur mit dem ASV - noch.

Hier ein einfacheres Scripting-Beispiel: Auf den animierten Ball wird die aktuelle Uhrzeit geschrieben:

<?xml version="1.0" ?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">

<svg width="200px" height="200px" onload="init(evt);">
  <defs>
    <radialGradient id="orange" cx="60%" cy="60%" r="80%" fx="60%" fy="65%">
      <stop offset="0%" style="stop-color:rgb(234,152,55)" />
      <stop offset="100%" style="stop-color:rgb(0,0,25)" />
    </radialGradient>
    <script type="text/ecmascript"><![CDATA[
      var svgdoc;

      function init(evt) {
        svgdoc = evt.getTarget().getOwnerDocument();
        setInterval("update()", 1000);
      }

      function update() {
        var d1 = svgdoc.getElementById("datum");
        var d2 = (new Date()).toLocaleString();
        d1.getFirstChild().setData(d2);
      }
    ]] ></script>
  </defs>
  <circle id="ball" cx="100" cy="-50" r="50" style="fill:url(#orange)">
    <animateMotion dur="5s" path="M0 0 Q10 400 50 -50" />
  </circle>
  <text id="datum" x="10" y="60"> </text>
</svg>

Serverseitiges SVG

Wenngleich die serverseitige Interaktion von SVG nur mit Schwierigkeiten mlich ist, die XML-Basis des Formats bringen hier deutliche Vorteile. Flash-Filme lassen sich nur mhsam und eingeschr舅kt von einem serverseitigen Skript erstellen, die Ming-Bibliothek ist ein Beispiel hierfr. Bei SVG sieht es natrlich komplett anders aus. Das Skript muss nur Text ausgeben, schon wurde SVG erzeugt. Fr diverse Programmiersprachen gibt es fest stehende Module, mit denen SVG noch bequemer erstellt werden kann. Ein Beispiel hierfr ist SVG.pm von Ronan Oger, ein Perl-Modul das einen objektorientierten Zugriff auf ein SVG-Dokument bietet.

Das einzige, was hierbei beachtet werden muss, ist dass der korrekte MIME-Typ fr das SVG-Dokument angegeben wird. Wird das unterlassen, geht der Browser davon aus, dass es sich um ein HTML-Dokument handelt; das Plugin kann dann die Inhalte zumeist nicht korrekt darstellen. Um den MIME-Typ an den Browser zu schicken, muss im HTTP-Header der folgende Eintrag integriert werden:

Content-type: image/svg+xml

Mit PHP geht das beispielsweise folgendermaﾟen:

header("Content-type: image/svg+xml");

Hier ein komplettes PHP-Beispiel, das ein bewusst simpel gehaltenes SVG-Dokument ausgibt:

<?php
header("Content-type: text/svg+xml");
echo("<?xml version=\"1.0\" ?>\n");
?>
<svg width="250px" height="100px">
  <text x="10" y="60">SVG @ Linuxtag 2003</text>
</svg>

Plugin-Situation

Entscheidend fr den Erfolg oder Misserfolg einer Technologie ist, wie die Geschichte zeigt, nicht immer die Qualit舩, sondern letztendlich die Verbreitung. Hier hat Macromedia Flash zurzeit deutlich das Plus auf seiner Seite. Laut unabh舅gigen Erhebungen haben 98% aller Web-Clients einen Flash-Player installiert; bei der neuesten Version 6 des Plugins sind es immerhin ber 60%. W臧rend es fr SWF nur ein Plugin gibt - das offizielle von Macromedia - sieht es fr SVG zumindest zahlenm葹ig besser aus. Flaggschiff ist der Adobe SVG Viewer (kurz: ASV), aktuell in Version 3 erh舁tlich, Version 4 angeblich im Beta-Stadium. Seit einiger Zeit hat auch Corel mit dem Corel SVG Viewer nachgezogen. Ebenfalls relativ bekannt ist Squiggle, der SVG-Browser des Batik-Apache-Projekts. Allerdings ist lediglich der ASV relevant. Corel hat bis dato erst eine einzige Vorab-Version verfentlicht; Squiggle ist ein Standalone-Programm, das zudem noch eine Java-Laufzeitumgebung benigt, als fr den Massen-Web-Markt untauglich ist.

Zu diesem SVG-Plugin gibt es noch keine aussagekr臟tigen Verbreitungsstatistiken, Adobe und Corel verfentlichen auch keine exakten Download-Zahlen. Es ist allerdings davon auszugehen, dass der Anteil noch im einstelligen Bereich vor sich hin dmpelt. Da noch keine groﾟe Website auf das SVG-Plugin setzt, ist die Bereitschaft der groﾟen Masse, 3 MB herunter zu laden, nicht sonderlich groﾟ; es sind also haupts臘hlich Entwickler und "Early Adopters", die das Anzeigeprogramm einsetzen. Die teilweise kolportierte Behauptung, bei der Installation des Adobe Acrobat Readers (Verbreitung brigens zwischen 50% und 60%) wrde das SVG-Modul automatisch in den Browser integriert werden, ist schlichtweg falsch, wie ein einfacher Test beweist.

Aber es gibt weiter Grnde fr die verheerende Plugin-Situation. Die einzigen offiziell untersttzten Plattformen sind der Netscape Navigator 4 (auf General-Interest-Sites immer noch en par mit Netscape 6, 7, Mozilla und Abkmlingen) und der Internet Explorer - unter Windows und Mac. Neuere Mozilla-Derivate lassen sich mit etwas Tricksen zumindest zur allgemeinen Kooperation bewegen - was jedoch sicherlich nicht Massenmarkt-kompatibel ist. Schlimmer noch: Sobald versucht wird, zwischen HTML-Seite (und eingebettetem JavaScript-Code) und integriertem SVG-Dokument eine Kommunikation aufzubauen, scheitert dies - h舫fig strzt der Browser mit Bravour ab. In diesem Zusammenhang gibt es eine traurige Anekdote, die in einer Diskussion zwischen Adobe-und Mozilla-Entwicklern kumuliert. Fr die experimentelle Anpassung des Plugins auf Mozilla wurden die aktuellen, aber noch nicht als "frozen" gekennzeichneten APIs des Open-Source-Browsers genutzt. Diese APIs wurden sp舩er jedoch ge舅dert. Viel schlimmer noch: Laut Aussage von Adobe machen die neuen APIs eine Zusammenarbeit mit dem Adobe SVG Viewer auch in Zukunft sehr unwahrscheinlich. Corel geht noch einen Schritt weiter als Adobe. Statt einer "experimentellen Untersttzung" werden neue Netscape-Versionen (offiziell) schlicht berhaupt nicht untersttzt.

Auch aus diesem Grund wird bei Mozilla zurzeit daran gearbeitet, dass eine der n臘hsten Versionen eine komplette, native SVG-Untersttzung mit sich bringt. Die ersten Frchte dieser Bemhungen sind bereits sichtbar, knen sich aber noch nicht mit dem messen, was ASV vorgelegt hat - die Messlatte liegt hoch.

Editoren-Situation

Weiterhin von groﾟer Bedeutung in Hinblick auf die Durchsetzung eines Formats ist die Qualit舩 geeigneter Editoren. SVG hat hier zun臘hst den Vorteil aufzuweisen, dass berhaupt kein spezieller Editor nig ist. SVG ist als Plain-Text-XML mit vi oder Emacs komplett zu erstellen. Dies ist allerdings nur auf den ersten Blick ein Vorzug des Formats. Sp舩estens, wenn komplexere Animationen erstellt oder Elemente pixelgenau positioniert werden mssen, ist ohne einen Editor kaum etwas zu machen. Einer der wenigen wirklich ernst zu nehmenden Vertreter in diesem Gebiet ist Jasc WebDraw. Dieser bietet unter anderem eine Zeitleiste, ein Muss beim Erstellen von Animationen. Allerdings ist die Scripting-Untesttzung noch als ausbauf臧ig zu betrachten. Mit Spannung erwartet wurde auﾟerdem die neue Version von LiveMotion, dem Animationstool von dem Hersteller des ASV. Als schlieﾟlich die zugehige Pressemitteilung erschienen ist, folgte die groﾟe Ernchterung: SVG wurde mit keinem einzigen Wort erw臧nt.

Auf der Flash-Seite sieht es wiederum ganz anders aus. Macromedia Flash MX ist mittlerweile eine ausgereifte Entwicklungsumgebung, mit der die Erstellung von Flash-Filmen wirklich sehr einfach f舁lt. Natrlich liegt das auch daran, dass an der Software schon seit mehreren Versionen gearbeitet wird - die interne Versionsnummer von Flash MX ist 6. Hier besteht fr SVG noch groﾟer Aufholbedarf.

Fazit

SVG muss seinen Open-Source-Elfenbeinturm verlassen, um mit Flash ernsthaft konkurrieren zu knen. Untersttzung von Standards ist eine tolle Sache, dies allein jedoch gengt nicht. Die Plugin-Situation muss sich verbessern, hier ist Adobe am Zug. Auﾟerdem sind gute Editoren gefragt, um der breiten Masse das Erstellen von SVG schmackhaft zu machen. Der Vorsprung von SWF ist enorm, aber die Vergangenheit hat mehrfach gezeigt dass das Internet ein schnelllebiges Medium ist. Als Fazit fr SVG bleibt festzuhalten: Eine interessante, zukunftstr臘htige Technologie? Auf jeden Fall. The Next Big Thing? Keineswegs.