Übersetzt bedeutet das HTML5 Element CANVAS “Leinwand”, und damit beschreibt dieser Tag seine Aufgabe recht genau. Canvas ist eine Leinwand, auf der sich 2D Formen (Kreise, Vierecke, Polygone, Kurven und Linien) und Bitmap Grafiken mit Hilfe von JavaScript “malen” und animieren kann. Damit nicht genug, in neueren Browserversionen kann Canvas sogar mit Video und Audio Dateien umgehen. Ursprünglich von Apple eingeführt wird Canvas mittlerweile von Mozilla Firefox, Google Chrome, Safari und Opera unterstützt. Eine native Implementierung für den Internet Explorer gibt es nicht, allerdings bietet die Javascript Bibliothek ExplorerCanvas eine Möglichkeit das Canvas Objekt über die im IE eingebaute VML Unterstützung nachzubilden (mit einigen Einschränkungen). Der “Hype” um das Canvas Element hat längst begonnen und alles dreht sich um die Frage, ob Canvas in der Lage ist Technologien wie Flash oder Silverlight abzulösen.
Canvas versus Flash
Canvas versus Flash (oder auch Silverlight), dass ist meiner Meinung nach ein wenig so, als ob man Äpfel mit Birnen vergleicht. Bei Canvas “malt” man direkt auf die Leinwand, eine einmal erstellte Form lässt sich (als Einzelelement) nachträglich nicht mehr bewegen oder skalieren. Animationen in Canvas entstehen nur dadurch, dass die gesamte Leinwand in einem definierten Intervall neu “gemalt” wird. Canvas ist ein ein gerastertes Bitmap Objekt, Flash hingegen ein Vektor Animations Werkzeug. Es liegt auf der Hand, dass eine solche Bild für Bild Animation auf die Performance geht (bzw. gehen kann), denn je mehr Objekte sich auf der Leinwand befinden, desto mehr Leistung wird bei jedem Malvorgang abgefordert.
Auch in Sachen Schrift und Text hinkt Canvas den “Konkurrenten” (noch) hinterher. HTML-Fragmente lassen sich bspw. nicht mit dem Canvas Element rendern. So heißt es in der Spezifikation:
A future version of the 2D context API may provide a way to render fragments of documents, rendered using CSS, straight to the canvas.
Wann das soweit sein wird, ist unklar und bis dahin muß man andere Lösungen finden. Auch einen Text innerhalb einer vorgegebenen Box umzubrechen ist nur über eigenen JavaScript Code möglich, eine native Unterstützung ist nicht gegeben.
Und Schriftarten – in Flash können Schriften direkt eingebunden werden, diese werden unabhängig vom Browser, unabhängig vom Client korrekt dargestellt – Bei Canvas ist man weiterhin abhängig von den Möglichkeiten, die einem Browser und Client liefern. Die Darstellung von Schrift am Bildschirm kann sich dabei zum Teil von Client zu Client drastisch unterscheiden. Ein Weg, um diese Schwäche zum umgehen, ist die Verwendung von Bitmap-Fonts, also einer Grafik, die schlicht alle darzustellenden Buchstaben enthält. Einen entsprechenden Konverter findet man u.a. bei Ben Joffe. Nachteil: Es bedarf ein Bild für jede Schriftgröße, und dass ist nicht gerade flexibel. Weitaus flexibler ist da schon der Einsatz von Vektoren-Schriften (TrueType). Damit das funktioniert, müssen diese Schriften ebenfalls konvertiert werden, auch dafür gibt es die erforderlichen Werkzeuge. Allerdings sind die entstehenden Dateien zum Teil recht groß und ziehen damit entsprechende Ladezeiten nach sich. Je komplexer eine zugrunde liegende TrueType Schrift, desto aufwändiger wäre es, diese Schriften “realtime” mit JavaScript zu parsen. Ein vorgefertigtes properitäres “canvas” Format wäre folglich wesentlich effizienter. Bibliotheken wie Cufon, oder Typeface arbeiten mit solchen Schriftbibliotheken. Die Verwendung dieser Bibliotheken trennt sich in zwei Teile: Einem Font-Generator, der Schriftarten in ein solches proprietäres Format konvertiert sowie einer in JavaScript geschriebenen Render-Engine, die dann die Schriften darstellt. Zur Zeit sicher eine der eleganteren Methoden, um Webseiten mit einer größeren Schriftvielfalt auszustatten. Aber selbst in dieser Form erhöhen sich Ladezeiten merklich und dass ein so “generierte” Schriftzug nicht mehr selektierbar ist, ist auch nicht von Vorteil.
Es gibt noch ein Argument, das bei einem solchen Vergleich Flash versus Canvas gegen Canvas spricht. Flash Anwendungen sind browserunabhängig. Man arbeitet bei der Entwicklung auf einer eindeutigen Grundlage, auf der von Adobe. Die Canvas Implementation basiert auf JavaScript und damit sind alle Interpretations- und Funktionsunterschiede der Browser auch Bestandteil einer jeden Canvas Entwicklung. Ein Umstand, der Frontend Entwickler sicher nicht mehr aus der Fassung bringt, aber von Vorteil sind diese Unterschiede auch nie gewesen.
Was spricht für das Canvas Element?
Gab es bei der Einführung von SVG (Scalable Vector Graphics) nicht schon eine ähnliche Diskussion wie momentan? SVG als Grundlage für die nächste Generation von Rich-media und Animation im Internet, und damit als eine Art “Flash-Killer” Anwendung. Auch mit SVG konnte (kann) man aufwändige interaktive Vektorgrafiken erzeugen, Schriften und Bilder implementieren, JavaScript als Schnittstelle nutzen, aber eine ernsthafte Konkurrenz zu Flash ist SVG nie geworden.
Considering that ActionScript is really just Javascript with some rendering APIs, once SVG is ubiquitous (effectively taking care of the rendering API), will there be much point to Flash?
Schrieb Steve Dekorte in seinem Blog, aber in der Realität ist SVG eher eine Nischentechnik geblieben. Es ist nicht so, dass SVG keinen Einzug ins World Wide Web gefunden hat (und mit HTML5 vielleicht auch noch mal an Bedeutung gewinnen kann), aber zum “Flash Killer” hat es nicht gereicht. Ein Grund dafür mag allein schon sein, dass der Technik ein geeignetes Werkzeug fehlte.
Indeed, until SVG can be created visually with designer-friendly tools that are widely available, it may remain more of academic than public interest.
Heißt es in einem Artikel von Craig Kirkwood. Ein Werkzeug, dass bei der Erstellung interaktiver Grafiken unterstützen kann, eine visuelle Entwicklungsoberfläche – etwas, was man auch bei Canvas andenken sollte, so sieht es auch Jonathan Snook in seinem Canvas Artikel.
Canvas hat es von einem prioritären Apple Format zu einem Bestandteil der offiziellen HTML5 Spezifikation geschafft. Treibende Kraft dahinter ist die WHATWG, ein Verbund in dem u.a. Vertreter von Apple Inc., Mozilla Foundation und Opera Software ASA vertreten sind. Da das W3C die Arbeiten an XHTML2 eingestellt hat, wird HTML5 der nächste “große Standard” werden (auch wenn der der Fertigstellungstermin der Spezifikation erst im Jahr 2022 liegt, ist HTML5 bereits jetzt Realität). Schon aufgrund dieser Tatsachen ist Canvas ernst zu nehmen. Im Gegensatz zu Flash erfordert Canvas kein Plugin, und mit immer mehr mobilen Geräten und Betriebssystemen steigt die Zahl von Systemen, die nicht mit Flash umgehen können oder wollen (so wurde beim IPad auf die Unterstützung von Flash verzichtet). Hier öffnet sich eine Lücke, die Canvas schließen kann.
Canvas basiert auf JavaScript, und es gibt zweifelsfrei mehr Entwickler, die mit dieser Sprache umgehen können als mit ActionScript. Auch das spricht dafür, dass der Einsatz von Canvas zunehmen wird. Je komplexer ActionScript wird, desto mehr Entwickler werden einfachere Animationen und Effekte in JavaScript umsetzen, und dafür eignet sich Canvas hervorragend. Vor ein paar Jahren waren Bildergalerien und “Slideshows” ausschließlich in Flash umgesetzt. Diese Flash-basierten Lösungen sind heute von JavaScript Bibliotheken wie prototype.js oder JQuery mit ihren entsprechenden Plugins weitgehend abgelöst worden. Die Kombination von CSS3, neuen JavaScript Erweiterungen (Geolocation. Webworkers etc.) und Canvas ermöglicht heute (bald) vieles, was vorher ausschließlich in Flash zu realisieren war. Brauchte man vorab einen “Flash-Designer”, so erledigt der “Frontend-Programmierer” solche Arbeiten jetzt (demnächst) gleich mit. Das spart Zeit und Geld – ob es in allen Fällen optimal ist, den “Designer” außen vor zu lassen, sei dahingestellt.
Canvas wird über kurz oder lang sicher einige Anwendungsbereiche von Flash übernehmen. Überall dort, wo Flash nur deshalb zum Einsatz kam, weil (X)HTML, CSS2 und Javascript keine ausreichende Darstellungsqualität erreichten. Einfache Verformungen, Rundungen, Wellen – der Bedarf war schon lange da, mit Canvas wurde ein Weg geschaffen diese einfacher bzw. systemnäher in eine Webseite zu integrieren als mit Flash oder über einen enormen Bitmapgrafik Anteil.
Flash versus Canvas ist Ideologie, kein sinnvoller Vergleich
Viele der Canvas Beispiele sind zweifelsfrei beeindruckend, schöne Spielereien, aber wenn Sie Flash imitieren, dann hinken Sie der Entwicklung 10 Jahre hinterher. Ein Jump & Run Spiel mit Canvas zu realsieren mag als Showcase reizvoll sein, an die Qualität einer (gut) gemachten Flash Version wird es nicht herankommen. Vieles von dem, was zur Zeit mit Canvas gemacht wird, erinnert an die Anfangszeiten von Flash, schaut – ich kann einen Würfel drehen, oder Partikel fliegen lassen (aber nicht zu viele). Canvas ist kein Ersatz für Flash und sollte auch so nicht eingesetzt werden. Das Element kommt mit HTML5, im Verbund mit WebSQL, WebSockets, Webworker, GeoLocation und semantischen Tags, in diesem Verbund kann und sollte es seine Stärken ausspielen. Hier liegen über die gemeinsame Basis JavaScript Möglichkeiten, die in Flash nicht so einfach und performant zu integrieren sind.
Beide Technologien haben ihre Daseinsberechtigung, Flash sicher eher in der Richtung von Rich Media Applications oder als plattformübergreifende Publikationstechnologie (über AIR), Canvas als unterstützende Technik, um Webseiten mit mehr (sinnvoller) Dynamik auszustatten. Canvas kann sicher auch dazu dienen, animierte Hintergründe, Banner u.ä. zu realisieren, aber über die Sinnhaftigkeit solcher Elemente lässt sich ohnehin streiten – Flash Intros gehören zum Glück auch immer mehr der Vergangenheit an.
Fazit
Dem Druck der WHATWG kann sich auch Microsoft mit seinem Internet Explorer auf Dauer sicher nicht verweigern und wird eine native Integration von Canvas anbieten, bis dahin gilt in den meisten Projekten ohnehin Vorsicht mit all den schönen neuen HTML Elementen und Techniken, denn noch ist das Flash Plugin verbreiteter als die Unterstützung von CSS3, Canvas und co. Wo man nach kleinen, schnellen Lösungen sucht oder notfalls auf eine breite Browserunterstützung verzichten kann bietet Canvas schon jetzt eine Möglichkeit den allzu starren Rahmen von HTML aufzubrechen, ohne sich in die Tiefen von ActionScript einzuarbeiten (was nicht heißt, dass die Canvas Logik leicht verständlich ist).
Canvas kann einiges, aber ein Ersatz für Flash wird es – zumindest in den nächsten drei, vier Jahren nicht sein. HTML5 kann vieles Neues und manches ist vielleicht noch spannender als das Canvas Element. Dennoch lohnt sich eine intensive Beschäftigung mit den Möglichkeiten, die diese neuen Technik bietet. John Reisig, der Initiator von Jquery liefert mit processing.js eine Bibliothek zur standardisierten Arbeit mit Canvas. Und unter Box2DJS findet man eine Bibliothek für physikalische Grundlagen, die Basis vieler Spiele und Animationen. Beide Bibliotheken können eine Basis sein für die ersten eigenen Schritte in Sachen Canvas, und wo so etwas dann hinführen kann, zeigt bspw. Canvasmol in dem sich chemische Moleküle dreidimensional rotieren lassen, oder man schaut mal bei Chrome Experiments vorbei und lässt sich inspirieren – damit aus den Experimenten sinnvolle Anwendungen entstehen, die nachweisen, dass das Canvas Element etwas kann.
Canvas wird auch zukünftig Flash nicht ersetzen können, so wie es im letzten Abschnitt anders heißt. Im Gegensatz zu Flash, kann ich beim Canvas-Element leider keine Formular-Elemente wie input-Felder aufnehmen (ohne sie zu emulieren). Damit bleibt das Canvas-Zeugs Spielerei (auch wenn schöne Effekte möglich sind).