Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Malen nach Zahlen

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Malen nach Zahlen

Mit dem neuen HTML5-Element <canvas> gesellt sich eine experimentelle Spielwiese zum Markup. Per JavaScript lassen sich Grafiken auf die Webseite zeichnen. Wie das geht und was es bringen kann, beschreibt Olaf Gleba.

Das Element canvas ist sicherlich eines der am interessantesten neuen Elemente der Spezifikation und durch seine vielfältigen Anwendungsbereiche zugleich auch eines der komplexesten. Ehemals eingeführt von Apple und in Safari und MacOS X integriert, hat es schon bald in Gecko-basierten Browsern und dem aktuellen Google-Browser Chrome Einzug gehalten.

Das Element ermöglicht Zeichenoperationen, mit Hilfe derer wir (fast) beliebige geometrische Formen und Pfade zeichnen können. Dies ermöglicht beispielsweise die Erstellung von Charts und/oder Diagrammen, die durch dynamische Werteangaben beim Laden einer Seite unmittelbar erstellt werden. Zum anderen bietet das Element umfangreiche Möglichkeiten zur Komposition, Animation und Manipulation von Bilder und Grafiken und auch Filmen.

Sozusagen zum Leben erweckt wird das initial leere Element durch die DOM Methoden, die das Element in großer Anzahl bereitstellt. Diese sind über eine Script-Schnittstelle (Javascript) ansprechbar.

Die Komplexität der Anwendungsmöglichkeiten bedingt es dann auch, dass in diesem Artikel nur grundlegende Beispiele beschrieben werden und am Ende auf lesens- und sehenswerte Seiten verwiesen wird.

Browser-Unterstützung

Alle Browser mit mind. Gecko 1.8 Engine (Firefox ab 1.5), Safari ab 3.x, Opera ab 9.x und der aktuelle Google-Browser Chrome unterstützen das canvas Element. Der Internet Explorer interpretiert das Element noch nicht. Über eine Javascript Lösung kann man dem IE hier Beine machen.

Einbindung

Quelltext: Einbindung des Element canvas

<canvas id="sample" width="290" height="150">
  Ihr Browser unterstützt das Element
    <code>canvas</code> nicht.
</canvas>

Das Element1 hat lediglich zwei optionale Attribute (width, height). Werden diese nicht gesetzt, wird es mit einer Weite von 300 Pixel und einer Höhe von 150 Pixel initialisiert. Die Definition des globalen Attributes id ist diesem Zusammenhang sinnvoll, um das Element in einem Scriptkontext gezielt ansprechen zu können.

Das Element canvas kann über CSS gestylt werden. Die Deklarationen beziehen sich dabei alleine auf den Element-Container. Die innerhalb des Elementes ausgeführten Operationen bleiben hiervon unberührt. In seinem Standardzustand wird das Element transparent angezeigt.

Wie bei den Elementen video und audio wird ein Fallback unterstützt. Ist einem Browser das Element unbekannt, wird der innerhalb des Start- und End-Tag liegende Inhalt angezeigt. Unterstützt der Browser das Element, wird der alternative Inhalt ignoriert und die Operationen innerhalb des Elementes werden ausgeführt.

Raster und Koordinatensystem

Bevor wir anfangen, uns konkreten Beispielen zuzuwenden, ein paar Worte zum Raster, auf das sich sämtliche Koordinaten unserer späteren Anwendungen beziehen.

Bild: Grafische Darstellung des Rasters/Koordinatensystems

Abbildung: Canvas-Koordinaten

Ausgangspunkt der Positionierung aller Elementen ist immer die obere linke Ecke des Rasters (0,0). So beschreibt X immer den Abstand zum linken, Y den zum oberen Rand des Rasters. Da dies für einige Anwendungen nicht wirklich ausreichend ist, gehe ich zu einem späteren Zeitpunkt auf die Möglichkeit ein, diese relative Fixierung zu umgehen.

Formen und Pfade

Das canvas Element stellt eine oder mehrere pixelbasierte Zeichenebenen bereit, die in einem drei- oder zweidimensionalen Kontext gerendert werden. Hiermit ist es unter anderen möglich, Tabellen und Diagramme dynamisiert zu zeichnen, aber auch einfache Animationen zu erstellen. Aufgrund einer bislang nicht eindeutigen Spezifikation der Schnittstelle für den 3D Kontext, konzentriere ich mich im folgenden auf die Möglichkeiten der zweidimensionalen Darstellung.

Quelltext: Initialisieren des Elementes canvas im Script-Kontext

<script>
var canvas = document.getElementById('sample');
var ctx = canvas.getContext('2d');
}
</script>

Um Operationen auszuführen, muss in einem ersten Schritt über die bereitgestellten DOM Methode getContext() des Elementes canvas der Darstellungskontext definiert werden. Die genannte DOM Methode benötigt als Paramenter den Typ des Darstellungkontextes. Hier setzen wir das Definitionskürzel für den zweidimensionalen Kontext ein.

Rechtecke

canvas unterstützt  – im Gegensatz zu SVG  – nur das Rechteck als unmittelbar zu zeichnende Form. Um daraus ableitende geometrische Formen zu ermöglichen wie Kreise, Dreiecke und komplexe Kombinationen aus beiden, müssen Pfade kombiniert werden. Hierzu weiter unten im Artikel mehr.

Rechtecke werden über folgende DOM Methoden des Elementes canvas erstellt:

Name Beschreibung
fillRect(x,y,width,height) Zeichnet ein Rechteck
clearRect(x,y,width,height) Bezieht sich auf das unmittelbar zuvor definierte Rechteck und überlagert dieses transparent.
strokeRect(x,y,width,height) Zeichnet ein Rechteck mit Kontur

Quelltext Beispiel 1: Rechtecke zeichnen

<!DOCTYPE html>
<head>
<meta charset="UTF-8">
<script type="text/javascript">
function zeichne() {
  var canvas = document.getElementById('sample');
  if (canvas.getContext) {
  var ctx = canvas.getContext('2d');

    ctx.fillStyle = "rgba(30,144,255,0.5)";
    ctx.fillRect (10, 10, 120, 120);

    ctx.fillStyle = "rgba(30,144,255,0.7)";
    ctx.fillRect (70, 30, 120, 120);

    ctx.fillStyle = "#1E90FF";
    ctx.fillRect(230, 10, 120, 120);
    ctx.clearRect(250, 30, 80, 80);
    ctx.strokeRect(255, 35, 70, 70);
  }
}
</script>
</head>

<body onload="zeichne();">

<canvas id="sample" width="460" height="150">
  Ihr Browser unterstützt das Element
  <code>canvas</code> nicht.
</canvas>

</body>
</html>

Beispiel 1: Rechtecke zeichnen

Abbildung: Rechtecke zeichnen

Für die Beispiele des Artikels nutzen wir im head einen Script-Tag. Dort legen wir eine Funktion zeichne() an und überprüfen als Erstes, ob das Element canvas dem Browser bekannt ist, in dem wir stellvertretend das Vorhandensein der Methode getContext() abfragen. Anschließend initialisieren wir das Element canvas mit dem zuvor erwähnten zweidimensionalen Kontext, um als nächstes die Anweisungen der Funktion zu schreiben. Um sie unmittelbar nach dem Laden der Seite auszuführen, nutzen wir das onload Event des Body-Tags. In den nachfolgenden Beispielen wird auf die wiederholte Listung dieses Grundaufbaus verzichtet.

Wie im Quelltext zu sehen, wird zusätzlich noch die Methode fillStyle() einsetzt. Hiermit wird die Füllfarbe des gezeichneten Objektes angegeben. Im Abschnitt Farben und Transparenzen gehe ich näher auf Methoden ein, die sich mit der farblichen Gestaltung der Objekte befassen.

Pfade

Während die Methoden zur Erstellung von Rechtecken das gezeichnete Element ohne weitere, explizite Anweisungen zeichnen, ist es beim Zeichnen von Pfaden erforderlich, dem Element canvas deutlich zu machen, wo ein Pfad beginnt, wo er aufhört und in welcher Art und Weise er schließlich gezeichnet werden soll. Hierzu dienen folgende, parameterlose Funktionaufrufe:

Name Beschreibung
beginPath() Methode zum Beginnen eines neuen Pfades.
closePath() Methode zum Schließen eines Pfades.
stroke() Zeichnet den zuvor definierten Pfad unter Anwendung einer Kontur.
fill() Zeichnet den zuvor definierten Pfad unter Anwendung einer vollflächigen Anzeige.

Mit beginPath() wird ein neuer Pfad eingeleitet. Zu beachten ist hierbei, dass der Pfad zu dem Zeitpunkt noch nicht tatsächlich gezeichnet wird. Hierzu nutzt man im Anschluß die Methode stroke() oder/und fill(). Wird fill() eingesetzt, ist ein dezidiertes Schließen des Pfades über closePath() nicht erforderlich, da die Methode die Zeichenoperationen automatisch beendet.

Zeichnen wir als erstes Beispiel eine einfaches Dreieck.

Quelltext Beispiel 2: Pfad zeichnen (Dreieck)

ctx.beginPath();
ctx.fillStyle = "rgb(30,144,255)";
ctx.moveTo(10,10);
ctx.lineTo(100,10);
ctx.lineTo(10,100);
ctx.fill();

Beispiel 2: Pfad zeichnen (Dreieck)

Abbildung: Pfad zeichnen (Dreieck)

Schauen wir uns das letzte Beispiel an, sehen wir, dass zwei noch unbekannte Methoden verwandt werden:

Name Beschreibung
moveTo(x,y) Ansatzpunkt auf dem Raster der Leinwand.
lineTo(x,y) Methode zum zeichnen einer Linie. Die Parameter (x,y) bestimmen jeweils den Start- und Endpunkt der Linie.

Mit moveTo(x,y) wird festgelegt, an welcher Koordinate (x,y) die nachfolgende Zeichenoperation begonnen werden soll. Der Startpunkt des aktuellen Pfades schließt automatisch an dem Endpunkt des vorherigen Pfades an. Gleichzeitig definiert der Endpunkt des aktuellen Pfades immer auch den Startpunkt eines nachfolgenden Pfades. Mit der Funktion lineTo(x,y) wird die eigentliche Linie gezeichnet.

Neben Linien gibt es dankenswerter Weise auch eine direkte Methode zur Definition von Kreisen (oder besser: gebogenen Linien), die mit arc() benannt ist.

Name Beschreibung
arc(x,y,radius,startAngle, endAngle,anticlockwise) Methode zum zeichnen eines Kreises oder einer gebogenen Linie.

Parameter x und y beschreiben die Koordination des Kreises bezogen auf den Mittelpunkt des Kreis. Der radius bestimmt den Umfang des Kreises, startAngle und endAngle legen den Beginn und das Ende des Kreispfades anhand der X-Koordinate fest. Der boolsche Paramenter anticlockwise bestimmt, ob unser Kreis im oder gegen den Uhrzeigersinn gezeichnet wird.

Quelltext Beispiel 3: Kreis zeichnen

ctx.beginPath();
ctx.fillStyle = "rgba(30,144,255,0.5)";
ctx.strokeStyle = "rgba(30,144,255,1)";
ctx.arc(70,80,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();
ctx.stroke();

Beispiel 3: Kreis zeichnen

Abbildung: Kreis zeichnen

Hinweis: Durch die Parameterangabe Math.PI*2 wird ein geschlossener Kreis erzeugt. Um Teilkreise zu erstellen, kann dieser Parameter angepasst werden.

Auch Bezier-Kurven (quadraticCurveTo(), bezierCurveTo()) können über bereitgestellte Methoden gezeichnet werden. Deren detailierte Anwendung wird hier aber nicht beschrieben, da dieses den Rahmen des Artikels sprengen würde. Details zu Anwendung und Parameter findest du auf den am Ende des Artikels gelisteten Seiten.

Gleiches gilt für weitere, hier nicht erwähnte Methoden, die das Element canvas bereitstellt. Zu erwähnen sind hier besonders die Möglichkeit Verläufe zu definieren, Schatten zu erzeugen und Methoden um Objekte zu transformatieren und skalieren.

Bilder und Grafiken

Spannend ist auch die Fähigkeit des Elementes canvas, Bilder/Grafiken und Zeichenoperationen zu kombinieren und sie zu einer Ansicht zusammenzufügen. Methoden zum Schneiden und Skalieren eines Bildes oder einer Grafik werden ebenfalls bereitgestellt.

Um ein Bild oder eine Grafik innerhalb des canvas zu referenzieren, gibt es verschiedene Methoden. Eine davon ist die Erzeugung eines neues Bildes über das DOM Objekt Image.

Quelltext: Erstellen eines Bildes anhand des DOM Objekt Image

var img = new Image();
img.onload = function(){
  Hier definieren wir später die Funktionen/Methoden
}
img.src = 'koordinaten-hintergrund.png';

Da unsere Funktion nicht vor dem vollständigen Laden des neuen Bildes ausgeführt werden sollen, wird deren Ausführung an den onload Event Handler des Image Elementes gebunden. Die hier genutzte Grafik koordinaten-hintergrund.png ist in dem Fall unsere Bezugsdatei, über die wir unseren Pfad zeichen wollen. Zur Einbindung nutzen wir die Methode drawImage().

Name Beschreibung
drawImage(image,x,y) Referenziert ein Bild oder eine Grafik.

Während die Koordinaten x und y für die Positionierung auf der Leinwand zuständig sind, beinhaltet der Parameter image die Referenz unseres Bildes/unserer Grafik oder eines anderen canvas Objektes.

Zu Beispiel 4: Referenzierte Grafik

Abbildung: Referenzierte Grafik als Hintergrund

Quelltext Beispiel 4: Bild/Grafik und Pfad kombinieren

function zeichne() {
  var canvas = document.getElementById('sample');
  if (canvas.getContext) {
    var ctx = canvas.getContext('2d');
    var img = new Image();
    img.onload = function(){
      ctx.drawImage(img,0,0);
      ctx.beginPath();
      ctx.strokeStyle = "rgb(30,144,255)";
      ctx.moveTo(40,146);
      ctx.lineTo(100,96);
      ctx.lineTo(140,126);
      ctx.lineTo(170,62);
      ctx.lineTo(210,100);
      ctx.lineTo(240,32);
      ctx.stroke();
    }
    img.src = 'koordinaten-hintergrund.png';
  }
}

Beispiel 4: Bild/Grafik und Pfad kombinieren

Abbildung: Bild und Pfad kombinieren

Farben und Transparenzen

In nahezu allen bisherigen Beispielen werden die Methoden fillStyle() oder/und strokeStyle() verwandt. Hiermit geben wir unseren Formen und Pfaden den farblichen Anstrich.

Verschiedene Notationen der Farben sind möglich, die auf der Spezifikation des W3C Farbmoduls basieren. Folgende Notationen sind in Ihrer Ausgabe identisch:

Quelltext: Werteangaben und Notationen für Farben

ctx.fillStyle = "dodgerblue";
ctx.fillStyle = "#1E90FF";
ctx.fillStyle = "rgb(30,144,255)";
ctx.fillStyle = "rgba(30,144,255,1)";

Das W3C Farbmodul erlaubt auch eine Notation im HSL(A) Format. Dieses wird aber bislang nur unzureichend von wichtigen Browsern unterstützt.

Hinweis: Definiert man eine Farbangabe, ist diese für alle Elemente gültig. Möchte man verschiedenfarbige Elemente haben, muss sie explizit für jedes Element überschrieben, respektive neu gesetzt werden.

Über rgba und der canvas Methode globalAlpha haben wir zwei Möglichkeiten, Transparenzen zu nutzen. Schauen wir uns zuerst die rgba Notation an.

Quelltext: Transparenzen über die rgba Notation

ctx.fillStyle = "rgba(30,144,255,0.5)";
ctx.fillStyle = "rgba(30,144,255,1)";

Die Notation innerhalb rgba ist identisch mit der von rgb, hat aber einen zusätzlichen Parameter am Ende der Notation. Der letzte Parameter bestimmt die Sichtbarkeit des Elementes, wobei 1.0 vollständige Deckung, 0.0 vollständige Transparenz bedeutet.

Quelltext Beispiel 5: Transparente Kreise mit rgba Notation

ctx.beginPath();
ctx.fillStyle = "rgba(30,144,255,0.4)";
ctx.arc(70,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

ctx.beginPath();
ctx.fillStyle = "rgba(30,144,255,0.7)";
ctx.arc(120,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

Beispiel 5: Transparente Kreise mit rgba Notation

Abbildung: Transparente Kreise mit rgba Notation

Die zweite Möglichkeit, die elementunabhängige Definition über die Methode globalAlpha(), macht es möglich, übergreifend für alle Elemente der Leinwand einen Standardwert für Transparenzen zu setzen, der alle Farbangaben beeinflußt.

Name Beschreibung
globalAlpha(Wert der Transparenz) Setzt den Standardwert für Transparenzen.

Der Wertebereich liegt auch hier zwischen 1.0 (vollständige Deckung) und 0.0 (vollständige Transparenz).

Quelltext Beispiel 6: Transparente Kreise mit Methode globalAlpha()

ctx.globalAlpha = 0.5;

ctx.beginPath();
ctx.fillStyle = "#1E90FF";
ctx.arc(70,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

ctx.beginPath();
ctx.fillStyle = "#1E90FF";
ctx.arc(120,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

Beispiel 6: Transparente Kreise mit Methode globalAlpha()

Abbildung: Transparente Kreise mit Methode globalAlpha()

Animationen

Durch die Bindung des Elementes canvas an DOM Methoden, die über eine Script-Schnittelle nutzbar sind, ist es grundsätzlich möglich, Objekte zu animieren. Dass das Element nicht konzipiert wurde um komplexer Animations-Software wie Flash oder Silverlight Konkurrenz zu machen, lässt sich an einigen Limitierungen erkennen. Nicht nur aufgrund der Komplexität und der damit notwendigen Ausführlichkeit in der Beschreibung, möchte ich auf die im Anschluß an den Artikel verlinkten Seiten verweisen. Dort findet man detailierte Beschreibungen, Beispiele und vieles mehr.

Zugänglichkeit (Accessibility)

Momentan können Inhalte des Elementes canvas ausschließlich über die Script-API erreicht werden. Auch der Umstand, dass als Fallback beliebige Elemente innerhalb der Element-Tags plaziert werden können, kann dem generierten Inhalt nicht in jeden Fall entsprechen, bzw. ihn nicht alternativ abbilden. Das W3C scheint sich dieses Problems bewusst zu sein und arbeitet an einem Fahrplan, wie eine erhöhte Zugänglichkeit für das Element erreicht werden kann.

Spezifikation
Tutorials und Informationen
Beispiele

Fazit

Meine Bewertung der aktuellen Implementierung des Elementes canvas ist ambivalent. Zum einen bietet es interessante Merkmale und Methoden um Webseiten zukünftig mit neuen, im jeweiligen Kontext sinnvollen Funktionen zu bestücken und zu erweitern. Auf der anderen Seite schaue ich ein wenig sorgenvoll auf die Tatsache, dass der Einsatz des Elementes im Moment vollständig abhängig ist von aktivierten Javascript. Mag man auch der Meinung sein, dass zusätzliche Funktionalität mit zusätzlicher Technik erkauft werden muss, ist die augenblicklich unzureichende Zugänglichkeit der Inhalte für Nutzerkreise, denen diese Technik nicht zur Verfügung steht, in meinen Augen durchaus eine Kritikpunkt.

Erfreulicherweise ist dieses Problem dem W3C bereits bewusst, und es wird an einer Lösung gearbeitet.

1 Während Apple in seiner Implementation des Elementes canvas keinen Endtag vorschreibt, hat die Mozilla Foundation dessen Vorhandensein als zwingend notwendig definiert.

Kommentare

Bernhard H.
am 29.09.2009 - 19:35

Canvas ist zumindest eine Interessante Alternative zu SVG. Zwar hat SVG den Vorteil, dass es ein XML-Format ist (Und damit nicht nur als eigenständige Datei bestehen kann, sondern auch von einer Vielzahl von Software angezeigt und bearbeitet werden kann), auf der anderen Seite ist das Prinzip von Canvas zur Javascript-Programmierung besser geeignet: Einfach überpinseln und keine aufwändigen DOM-Manipulationen. Vor allem wegen letzterem habe ich angefangen mit Canvas zu experimentieren. Wobei ich aus SVG-Zeiten vermisst habe, dass man leicht Event-Handler auf die einzelnen Zeichenelemente legen kann.

Dieser Artikel fasst die Canvas-API meiner Meinung nach übersichtlicher zusammen als die Seiten im MDC.

Auch wenn ich diese Art der fast kleinlichen Kritik normalerweise nicht übe, muss ich mich doch zu Wort melden, da mir beim Lesen 2 irritierende Formulierungen aufgefallen sind:
Bei Rechtecke: "Um daraus ableitende geometrische Formen..." oder: "weitere"
Bei clearRect(): "Bezieht sich auf das unmittelbar zuvor definierte Rechteck und überlagert dieses transparent." Zuvor definiert? Transparent überlagern? Löscht einfach den Inhalt eines Rechtecks.

Zudem ist deine Erklärung zu moveTo() recht seltsam. Schließlich ändert sich der "Ausgangspunkt der Positionierung" nie, also der Ursprung (0|0) aller Koordinaten bleibt immer gleich. Die Funktion setzt eigentlich nur den Ausgangspunkt des nächsten Pfadabschnitts. Man könnte sagen, es zeichnet einen unsichtbaren Pfadabschnitt. Es ist etwas überflüssig, dass du im Abschnitt zum Koordinatensystem darauf verweist, schließlich lernt der Leser zunächst nur das Rechteck kennen, für welches sich der Ausgangspunkt der Positionierung - auch - nie ändert.
Vielleicht ist es möglich du die entsprechenden Passagen etwas zu ändern.

Permanenter Link
Olaf Gleba

Olaf Gleba (Autor)
am 29.09.2009 - 23:23

@Bernhard H.

Bei Rechtecke: "Um daraus ableitende geometrische Formen…"

"ableitende geometrische Formen" ist gewählt worden mangels eines besseren Einfalls zur Formulierung/Beschreibung. In dem Abschnitt sollte ja verdeutlicht werden, das die API als einzige, tatsächliche geometrische Form das Rechteck originär unterstützt. Und andere Formen immer eine Kombination von Pfaden benötigen/sind.

Bei clearRect(): "Bezieht sich auf das unmittelbar zuvor definierte Rechteck und überlagert dieses transparent.

Zumindest beim flüchtigen Lesen des erster Teil des Satzes könnte man in der Tat den Eindruck gewinnen, als ob ein clearRect() abhängig ist von einem vorher gezeichneten Rechteck. Dem ist natürlich nicht so, wird allerdings explizit so auch nicht gesagt. Allerdings macht ein clearRect() aber auch erst dann Sinn, wenn ich dieses in Zusammenhang mit einer anderen, zu überlagernden Flächenform nutze. Deswegen ist die Formulierung so gewählt.

Was den zweiten Teil des Satzes angeht: Ich spreche von einem "transparent überlagern" anstatt eines 'wird gelöscht', da ich hoffe, dass dies vielleicht verständlicher ist. 'Gelöschter Inhalt' erscheint mir hier für Leser, die sicher erstmalig mit dem Element beschäftigen, die abstraktere Formulierung zu sein.

Zudem ist deine Erklärung zu moveTo() recht seltsam. Schließlich ändert sich der "Ausgangspunkt der Positionierung" nie, also der Ursprung (0|0) aller Koordinaten bleibt immer gleich. Die Funktion setzt eigentlich nur den Ausgangspunkt des nächsten Pfadabschnitts. Man könnte sagen, es zeichnet einen unsichtbaren Pfadabschnitt.

Auch hier ist es wieder die Frage der Verständlichkeit, ob eine Formulierung wie "zeichnet einen unsichtbaren Pfadabschnitt" zwangsläufig einleuchtender ist. Du hast aber natürlich recht mit der Kritik an dem "Alternative zur generellen Positionierung". Das ist im formalen Sinne nicht korrekt und sollte geändert werden.

Es ist etwas überflüssig, dass du im Abschnitt zum Koordinatensystem darauf verweist,

Das wiederum sehe ich nicht so, da es hier eine inhaltliche Verlinkung zum einem Abschnitt gibt, an dem der praktische Einsatz der Methode move() deutlich gemacht wird und von daher zum inhaltlichen Zusammenhang beiträgt.

Permanenter Link

Thomas Meinike
am 30.09.2009 - 10:08

Gelungene Einführung in das Thema canvas. Vielleicht lassen sich noch die Texttechniken ergänzen. In meinem aus Daten erzeugten Kreisdiagramm kommen die font-Eigenschaft und die fillText-Methode zum Einsatz.

Permanenter Link

Gunther
am 30.09.2009 - 12:28

Hallo!

Der Artikel ist ohne Frage sehr gut geschrieben und hat die hier gewohnte Qualität, die wir ja auch vom Autor gewohnt sind. Deshalb bezieht sich meine folgende Kritik auch nicht auf den Artikel, sondern vielmehr auf das Element an sich.

Das fängt schon mit der imo unglücklichen Namensgebung an, war uns Canvas doch bisher schon als

"... canvas describes 'the space where the formatting structure is rendered.'"

bekannt.

Desweiteren frage ich mich, was solch ein Element noch mit Hyper Text Markup Language zu tun hat? Mit anderen Worten stellt sich für mich hier die Frage, was in den Bereich der Plugins und was in den der Hyper Text Markup Language fällt?

Aus meiner Sicht ebenfalls fragwürdig ist auch, welchen Sinn ein HTML Element macht, welches letztlich nur dann zur Anzeige gelangt, wenn neben einer geeigneten Rendering-Engine auch zwingend Javascript verfügbar sein muss? Reicht für solche Fälle das bereits vorhandene Script-Element mit seiner Fallback Variante Noscript nicht aus?

Und wenn das W3C schon dabei ist, warum nicht gleich auch noch Elemente wie oder für die native Unterstützung der entsprechenden Dateiformate?

Was mich dann erstaunt, ist die prompte Implementierung dieses Elements seitens der bedeutenden Browserhersteller - zeigen sie sich doch bei vielen anderen Neuerungen (einige davon imo wesentlich sinnvoller und in der täglichen Praxis viel häufiger anwendbar) weitaus weniger fortschrittlich. Man könnte glatt den Eindruck gewinnen, dass man sich irgendwie nur vom gemeinsamen "Widersacher" IE absetzen/ unterscheiden will.

Generell erscheint mir die Entwicklung von HTML 5 (und CSS 3) als der mehr oder weniger klägliche Versuch seitens des W3Cs mit den heutigen Praxisanforderungen einigermaßen Schritt zu halten, was schon aufgrund der imo viel zu langen Entwicklungszeiten nur sehr bedingt gelingt.

Allerdings bin ich davon überzeugt, dass der derzeitige Ansatz (HTML + CSS) nie zu einer für Webdesigner befriedigenden Lösung führen wird, da er dies vom Grundsatz her schon nicht kann.

HTML ist vom Grundkonzept her eine

"... textbasierte Auszeichnungssprache zur Strukturierung von Inhalten wie Texten, Bildern und Hyperlinks in Dokumenten."

. Und es liegt in der Natur einer solchen Datei, dass diese immer linear aufgebaut ist.

CSS wiederum

"... ist eine deklarative Stylesheet-Sprache für strukturierte Dokumente. [...] CSS legt dabei fest, wie ein besonders ausgezeichneter Inhalt oder Bereich dargestellt werden soll."!

Darstellung ist aber nicht gleich Layout! Und das ist imho der alles entscheidende Punkt. Es gibt also einerseits HTML für die Strukturierung der Inhalte und andererseits CSS für deren Art der Darstellung.

Was aber fehlt ist eine Sprache für das jeweilige Layout. Denn das ist vom System her nicht Aufgabe, bzw. Sinn und Zweck von CSS, auch wenn man krampfhaft versucht, es dafür zu verwenden (was ja aber auch nur mit sehr mäßigem Erfolg funktioniert). Und daran wird auch das CSS3 Layout-Modul wenig ändern (genausowenig wie die anderen Neuerungen in CSS3).

À propos "neu": Unter dem Aspekt frage ich mich auch, welche Semantik den anderen neuen Elementen in HTML 5 innewohnt, wie nav, article, header, footer, aside, usw.? Nun gut, jetzt könnte man noch argumentieren, dass sie zur Strukturierung beitragen, aber wenn bspw. ein Nav-Element nur dazu dient, eine UL-Liste einzuschließen, dann muss die Frage erlaubt sein, wo da der Unterschied zu einem umgebenden DIV (welches wenigstens von Hause aus als "inhaltsleer" deklariert ist) mit einer ID oder Klasse "nav" ist?

Welchen Sinn machen solche Elemente, wenn ich für deren Layout (nicht Design!) wieder auf die mangelnden Fähigkeiten von CSS zurückgreifen muss? Diese "blähen" die Sprache doch dann nur unnötig auf, ohne irgendeinen wirklichen Vorteil zu bieten.

Gerade mit Blick auf ihre jeweilige Semantik, die ja eigentlich jedem HTML Element innewohnen sollte (mit den bisherigen Ausnahmen der inhaltsleeren Elemente DIV und SPAN), halte ich fast alle der neuen Elemente in HTML 5 für zumindest "fragwürdig". Und, um die Kurve zum eigentlichen Thema dieses Artikels zu kriegen, genauso sehe ich das Canvas Element, dessen praktische Verwendung ich auch mal eher als sehr gering einstufen würde.

Generell wundert es mich auch ein wenig, dass (scheinbar) die breite Masse der Webdesigner die Entwicklungen des W3Cs so klaglos hinnimmt, und anstatt sich lauthals über seit Jahren fehlende praktische Dinge zu beschweren, jede neue "Spielerei" bejubelt, bzw. feiert, als hätten sie gerade das Rad erfunden?

Dies wäre gleichzeitig auch ein Wunsch meinerseits, hier öfter mal kritische Artikel in dieser Richtung zu lesen. Denn letztlich sollte man sich langfristig gesehen nicht mit irgendwelchen "Notlösungen" oder Hacks und "Würg-arounds" abfinden und begnügen, sondern den verantwortlichen Damen und Herren deutlich klarmachen, was man für die tägliche Arbeit mit dem Medium an "Werkzeugen" haben möchte, bzw. erwartet.

Gruß Gunther

Permanenter Link
Jens Grochtdreis

Jens Grochtdreis (Webkraut)
am 30.09.2009 - 15:26

Gunther, Du hast recht, daß HTML5 ein Versuch des W3C ist, mit der Realität Schritt zu halten. Ich finde ihn aber nicht kläglich. Es wird lange dauern, bis wir HTML5 wirklich guten Gewissens produktiv nutzen können, daran ist das W3C nur bedingt Schuld. Das größte Hemmnis sind die alten Browser und Microsoft.

Im Gegensatz zu den Herstellern moderner Browser verharrt Microsoft in alter Technik. Vielleicht sind sie froh, endlich einen Browser zu haben, der aus der Sicht von 2003 modern und toll ist. Wir haben aber 2009!

Es ist deshalb klasse, daß es Browserhersteller gibt, die neue Elemente implementieren und damit einen Praxistest zulassen. Anders kann man nicht testen, ob etwas funktioniert. Diese Arbeit überläßt Microsoft den anderen.

Und Du hast Recht, daß HTML5 nicht mehr viel mit dem alten HTML und dem Hyptertext zu tun hat. Jedenfalls nicht in allen Aspekten. Das ist auch gut so, denn moderne Seiten haben damit auch nichts zu tun. Oder wie willst Du Google Maps korrekt als Hypertext beschreiben? Das macht keinen Sinn.

Auch die Abhängigkeit von Javascript ist nur auf den ersten Blick schlimm. Wir haben uns daran gewöhnt, daß alles ohne JS funktionieren können soll. Wie soll aber Googel Docs ohne JS funktioneren? JS ist nicht böse! Es wurde als böse angesehen, weil insbesondere der IE eine Sicherheitslücke nach der anderen mit JS hatte. Es ist die Aufgabe der Browserhersteller, das zu korrigieren.

Die Neuigkeiten von HTML5 sind zum großen Teil für andere Anwendungsfälle gedacht, als HTML ursprünglich gedacht war. Unsere Internetrealität ist aber auch um Äonen weiter, als damals bei der Schaffung von HTML gedacht wurde.

Permanenter Link

Gunther
am 30.09.2009 - 17:58

@Jens
Ich möchte mal zwei deiner Aussagen hintereinander stellen:

Es wird lange dauern, bis wir HTML5 wirklich guten Gewissens produktiv nutzen können, daran ist das W3C nur bedingt Schuld. Das größte Hemmnis sind die alten Browser und Microsoft.

Unsere Internetrealität ist aber auch um Äonen weiter, als damals bei der Schaffung von HTML gedacht wurde.

Das bedeutet für mich, wenn man es mal konsequent weiterdenkt, doch nichts anderes, als dass unsere Internetrealität dann bereits wieder Äonen weiter ist. Und das ist doch genau der Punkt: Es gilt doch diesen Teufelskreis des Hinterherhinkens (um Jahre) endlich mal zu durchbrechen. Und ich stimme dir in deiner Aussage:

Die Neuigkeiten von HTML5 sind zum großen Teil für andere Anwendungsfälle gedacht, als HTML ursprünglich gedacht war.

insofern zu, als dass HTML ansich bereits für die heutigen Anwendungsfälle nicht mehr geeignet ist.

Aber anstatt einen sauberen Strich zu ziehen und mit einer gemeinsamen aktuellen Neuentwicklung den o.g. Teufelskreis zu durchbrechen, versucht man den ohnehin uneinholbaren Rückstand durch Flickschusterei an einem lahmen Gaul aufzuholen. Wie erfolgversprechend soll das sein? Noch dazu indem man das bisherige System/ Schema "verwässert" und unnötig "aufbläht". Wie heißt es doch gleich so treffend: "Du kannst aus einem Esel kein Rennpferd machen!".

Gleiches gilt imho im übrigen auch für CSS, welches ich im Bezug auf das Layout mittlerweile als gescheitert ansehe, weil ich nicht glaube, dass es diese Aufgabe jemals zufriedenstellend bewerkstelligen kann.

BTW: Ich halte die Einführung einer völlig neuen Technik außerdem für weitaus unproblematischer, als die jetzige Zielsetzung einer Weiterentwicklung unter Beibehaltung einer Abwärtskompatibilität. Alle mir dazu bekannten Beispiele einer solchen Entwicklungsmaxime endeten alle mit Murx.

Dabei wäre es eigentlich ganz einfach: Man bräuchte den Browsern ja lediglich zwei verschiedene Rendering-Engines verpassen und schon wäre das Ziel, dass auch alle bisherigen Seiten ordentlich dargestellt werden, erreicht.

Oder man stelle sich nur mal vor, jeder Browser würde über ein integriertes Menü verfügen, welches per Datei vom Webautor entsprechend "befüllt" werden könnte. Welch ungemeiner Fortschritt alleine im punkto Usability. So etwas Ähnliches gab es ja bereits über die Meta-Tags. Aber warum sollte man solche praktischen Dinge, die Millionen von Usern betreffen weiter verfolgen oder gar vereinheitlichen und perfektionieren?

Es ist deshalb klasse, daß es Browserhersteller gibt, die neue Elemente implementieren und damit einen Praxistest zulassen.

Das sehe ich etwas anders. In jedem anderen Bereich regt sich Jeder darüber auf, wenn er als Kunde/ Anwender/ Verbraucher vom Hersteller als Beta-Tester missbraucht wird. Nur bei den Browsern sollen wir uns auch noch darüber freuen?

Anders kann man nicht testen, ob etwas funktioniert.

Auch das sehe ich anders. Zumal das größte Problem, welches daraus erwächst, das ist, dass einmal "auf dem Markt" befindliche Techniken eben nicht wieder konsequent von der Bildfläche verschwinden, sondern viel häufiger hinterher doch versucht wird, sie irgendwie in die Standards zu integrieren.

Und wozu bitte ein W3C und "allgemeine Standards", wenn es in der Praxis so abläuft, dass jeder Browserhersteller für sich irgendwelche neuen Features "bastelt", vom User "testen" lässt und diese dann im Nachgang zum Standard erklärt werden? Hier ist doch ein Fehler im System. Natürlich nutzt es auch nichts, am grünen Tisch irgendwelche Standards zu definieren, wenn sich hinterher herausstellt, dass diese nicht umsetzbar sind. Aber immerhin hätte diese Methode den Vorteil, dass sie dann zwar auf dem Papier existieren, nur halt in der Praxis nicht. Das wäre mir allemale lieber als andersherum.

JS ist nicht böse

... kann es aber sein. Und davon unabhängig kann es aber von jedem User in seinem Browser deaktiviert werden. Schon alleine deshalb ist es eben für diverse Zwecke ungeeignet. Außerdem müsstest du das dann auch erstmal Millionen von Usern klar machen.
Dabei bräuchte es gar nicht den vollen Umfang der Möglichkeiten von JS. Ich halte solche Dinge wie bspw. die Viewportgröße des Browsers für keine schützenswerte oder gar zu verheimlichende Information. Warum stellt also nicht jeder Browser diese Informationen bspw. in Form von Konstanten zur Verfügung, sodass man in seinem Layout damit "arbeiten" könnte. Gerade in Zeiten so unterschiedlicher Bildschirmgrößen (bedingt u.a. durch die neuen Smart-Phones, aber auch immer größere TFT-Displays und immer mehr Fernsehern mit zumindest rudimentären Anzeigemöglichkeiten für Internetinhalte) ein imo sehr bedeutendes und wichtiges Thema.

Zwei Dinge sind m.M.n. entscheidend für die weitere Entwicklung:
1. Die Festlegung der Standards muss im Voraus passieren unter Zustimmung aller beteiligten Browserhersteller.
2. Browserhersteller sollten sich von der Idee verabschieden, dass ihr jeweiliges Produkt irgendwelche [1]Alleinstellungsmerkmale aufweisen muss. Stattdessen müssen sie sich strikt an die gemeinsam verabschiedeten Standards halten.

Ferner sollte ein zukünftiges System modular aufgebaut sein (wie aktuell bei CSS 3 angedacht), was allerdings nur dann wirklich funktionabel ist und somit Sinn macht, wenn es vernünftige und brauchbare Möglichkeiten zur Prüfung des Vorhandenseins oder Nicht-Vorhandenseins gibt.

In diesem Zusammenhang fallen mir dann auch gleich wieder Microsofts Conditional Comments ein, die diesbezüglich ein imho sehr praktikabler Ansatz in diese Richtung darstellen. Aber wie vieles Andere eben auch bis heute keinen auch nur irgendwie gearteten Eingang in iregndwelche Standards gefunden haben. Vielleicht liegt es ja daran, dass die Idee von MS stammt!?

Also ich denke, dass man heutzutage sowohl die aktuellen, als auch die zukünftigen Anforderungen an das Web wesentlich besser einschätzen kann, als vor 10, 15 oder gar (knapp) 20 Jahren. Ebenfalls besser einschätzen und beurteilen kann man auch die infrastrukturellen Gegegebenheiten und deren Möglichkeiten (angefangen bei DSL bis hin zur Glasfaser, die wohl für aktuelle Überlegungszeiträume das Ende der Fahnenstange markieren dürfte). Von daher sollte es imho eigentlich möglich sein, ein wesentlich besser auf diese Anforderungen zugeschnittenes Model zu entwerfen und umzusetzen, als das mit den nächsten 5 Nachbesserungen am bisherigen HTML Standard jemals der Fall sein dürfte.

Gruß Gunther

[1] In diesem Zusammenhang sei auf die Probleme verwiesen, wenn Browserhersteller "eigenmächtig" irgendwelche "Features" in ihre Browser einbauen, die nicht in den aktuellen Entwürfen oder den bereits bestehenden Standards vorgesehen/ enthalten sind. Ein Beispiel: Die im CSS3 Entwurf angedachten Media Queries "vertragen" sich aktuell wenig bis gar nicht mit dem proprietären Page-Zoom, den (fast) jeder Browserhersteller anders implementiert hat. Für die Praxis hat das zur Folge, dass man dieses eigentlich sehr sinnvolle Feature aus CSS3 quasi nicht verwenden kann.

Permanenter Link

Martin Gartner
am 30.09.2009 - 22:03

Vielleicht kennt ihr das noch nicht - aber es zeigt was mit "canvas" möglich ist (obs nützlich ist, sei dahingestellt):

http://benfirshman.com/projects/jsnes/

Permanenter Link
Olaf Gleba

Olaf Gleba (Autor)
am 30.09.2009 - 23:09

@Gunther

Zwei Dinge sind m.M.n. entscheidend für die weitere Entwicklung:
1. Die Festlegung der Standards muss im Voraus passieren unter Zustimmung aller beteiligten Browserhersteller.
2. Browserhersteller sollten sich von der Idee verabschieden, dass ihr jeweiliges Produkt irgendwelche [1]Alleinstellungsmerkmale aufweisen muss. Stattdessen müssen sie sich strikt an die gemeinsam verabschiedeten Standards halten.

Deinen Statements für die weitere Entwicklung stimme ich in seinem Inhalt uneingeschränkt zu, gleichwohl ist es eine (leider) arg idealistische Sichtweise auf ein Standardisierung-Gremiums, das aus über 400 Mitgliedern besteht, die sicherlich zum Großteil nicht aus altruistischen Motiven im Konsortium mitarbeiten.

Es interessiert einige, wichtige Mitglieder des Konsortiums nicht - wie man in der realen Vergangenheit erleben durfte und sicherlich zukünftig auch noch darf - dass Eigen-Entwicklungen mit Zielen und Standards des W3C kollidieren. Da hilft auch kein Fingerzeig, dass die selben Mitglieder, die ggf. Standards nicht oder nur unzureichend einhalten/unterstützen, diese im Gremium mit verabschiedet haben.

In der jetzigen Organisationsform des W3C ist es nicht durchsetzbar, Standards praktisch auf dem Papier zu pausen und die Mitglieder zu verpflichten, diese in ihren Produkten verbindlich umzusetzen. Und ich sehe auch keinen gangbaren Weg, dies zukünftig zu ändern ohne die an sich unabhängige Struktur eines W3C zu opfern.

So wird es bei den praktischen Ansatz, wie Jens beschrieben hat, bleiben (müssen).

Aus diesem Patt im Verhältnis W3C und wichtigen Mitgliedern, die nicht ignoriert werden können, erklärt sich meiner Meinung auch die ein oder andere Inkonsequenz in der Entwicklung.

Was wir tun können als Entwickler der Webseiten, die das Netz bevölkern, ist sich in unseren Möglichkeiten zu engagieren. Das bedeutet zum Einen, über Plattformen im Web Öffentlichkeit für Problemstellungen und Meinungen zu schaffen, sich konkret in den durchaus vorhandenen öffentlichen Kanälen des W3C zu involvieren, Aufrufe zu Kommentierung von Specs aktiv zu folgen etc.

gruss
Olaf

Permanenter Link
Olaf Gleba

Olaf Gleba (Autor)
am 30.09.2009 - 23:19

@Thomas Meinike

Dank dir für den Link. Das Thema ist so komplex, das die Möglichkeiten bspw. für Text ebenfalls der (relativen ;)) Kürze des Artikels zum Opfer gefallen sind.

Permanenter Link

ChrisB
am 10.10.2009 - 16:01

Desweiteren frage ich mich, was solch ein Element noch mit Hyper Text Markup Language zu tun hat? Mit anderen Worten stellt sich für mich hier die Frage, was in den Bereich der Plugins und was in den der Hyper Text Markup Language fällt?

Das sehe ich ähnlich.

Mit Canvas habe ich etwas, das - wenn auch noch JavaScript verfügbar ist - vielleicht "funktioniert".
Habe ich kein JavaScript zur Verfügung - dann ist es weitgehend nutzlos.

Nehmen wir Thomas' Kreisdiagramm-Beispiel. Mit aktiviertem JavaScript habe ich da etwas hübsch buntes, dem aber dummerweise in meinem Browser noch die Beschriftungen fehlen - was das ganze ziemlich wertlos macht. Es vermittelt zwar ein Bisschen an Informationen (prozentuale Anteile werden dargestellt) - aber ohne den Bezug sind diese wertlos.
Schaue ich mir das jetzt im FF an, dann sehe ich da Buchstaben und Prozentzahlen in einer Legende. Hätte man diese Informationen in HTML umgesetzt - dann könnte ich damit wenigstens etwas anfangen, auch wenn es grafisch weniger anschaulich gewesen wäre.

Das hätte man sicher "besser" umsetzen können (das soll jetzt keine persönliche Kritik sein @Thomas) - die Informationen erst mal im HTML hinterlegen, und dort mittels JavaScript auslesen und in einem dyanmisch erstellten CANVAS-Element visualisieren. Die simple Text-Legende nach wie vor in HTML und CSS umgesetzt lassen, wenn mein Browser mit der Text-Funktionalität nicht umgehen kann. Und dann hätte es für die "Torte" auch ein dynamisch generiertes Bild oder Flash getan.
Worauf ich hinaus will: Ein echter "Mehrwert" eines neuen Elementes Canvas wird hier noch nicht ersichtlich.
Es macht eher den Eindruck, das man froh ist, jetzt endlich mal eine Alternative zum "bösen" Flash gefunden zu haben - auch wenn die nicht "mehr" kann, und an den gleichen Krankheiten leidet. (Hält mir Informationen vor, wenn die Technik nicht komplett unterstützt wird [Textinhalt]; lässt mich Textinhalt, auch wenn er unterstützt wird, nicht markieren/kopieren, etc.)

Und als Krönung des ganzen - wenn ich JavaScript deaktiviere, bekomme ich nur den "Alternativinhalt" "Der Browser unterstützt die canvas-Technik nicht" zu sehen. "Ihre Browser unterstützt keine Frames" war zu deren Zeiten schon keine brauchbare Alternative. Zugegeben, das ist jetzt schon Kritik, die sich direkt ans Beispiel richtet, denn das hätte man besser machen können. (Auch wenn es nicht Thomas' Absicht dahinter gewesen sein mag, die "optimale" Umsetzung zu liefern, sondern lediglich kurz die Möglichkeiten zu demonstrieren.) Aber wir sehen hier schon mal, dass dieses neue Element das Potential hat, Informationen genauso unzugänglich zu machen, wie Flash.

Und zu der anderen Sache, Weiterentwicklung von CSS - die sehe ich ähnlich "pessimistisch".
Was wir bisher haben, eignet sich als Werkzeug für das, was wir erzeugen wollen, nur sehr bedingt.
Wir haben bspw. gelernt, float als Mittel zur Erzeugung von Spaltenlayouts zu akzeptieren - weil wir einfach nichts besseres haben. Das es nur eine Krücke ist, kann man aber wohl kaum bestreiten. Wir "missbrauchen" die float-Eigenschaft in CSS - und haben dabei eine Menge Wechselwirkungen mit anderen Eigenschaften zu berücksichtigen - damit wir uns besser fühlen können, weil wir jetzt nicht mehr die Tabelle von HTML dafür missbrauchen. Einen wirklichen Fortschritt kann ich darin aber noch nicht erkennen. (Und ob das mit einem an das bestehende Chaos angeflanschten CSS3-Layout-Modul besser wird, vage ich noch zu bezweifeln.)

Wir haben uns mit dem derzeitigen Zustand arrangiert; Kniffe/Hacks/Workarounds entwickelt, mit denen wir erreichen können, was wir umsetzen wollen - "schön" wird es dadurch aber noch lange nicht.

Wenn ich mir nur die Möglichkeiten anschaue, die ich habe, um zu "bestimmen", ob ein Element gefloatete Nachfahrenelemente einschliessen soll oder nicht - wäre da eine simple Eigenschaft, mit der ich das für das Vorfahrenelemet von floats eindeutig angeben kann, zu viel verlangt gewesen?
Aber nein, stattdessen bastle ich mit overflow rum, beschäftige mich damit, was ein Block Formatting Context ist (und wie ich ihn mit möglichst wenig Nebenwirkungen im konkreten Falle erreiche) - das mag ja alles in sich "logisch" sein, wenn man die Spezifikation anlegt. Aber es ist einfach eine wahnwitzige Verkomplizierung einer an sich simplen Angelegenheit. (Oh W3C-Götter, hättet ihr mir eine Eigenschaft incorporate-floats mit Werten true und false gegeben, würde ich nicht mal was sagen - aber so, wie es derzeit geregelt ist ...?)

Und da habe ich auch die starke Befürchtung, dass durch das "Erweitern" des bestehenden Modells, wobei ständig auf Abwärtskompabilität geachtet werden muss, vermutlich nichts besonders "vernünftiges" bei herauskommen wird.

Permanenter Link

Thomas Meinike
am 15.10.2009 - 11:43

@ChrisB: Deine prinzipiellen Einwände gegen rein JS-basierte Techniken teile ich. Mein canvas-Beispiel soll lediglich ein Test der Möglichkeiten und keine "best practice"-Anwendung sein. Ich gehe von reinem Datenmaterial aus, welches dynamisch verarbeitet wird, d. h. auch die prozentualen Anteile werden zunächst berechnet. Insofern wäre hier die Angabe der Rohdaten im canvas-Fallback-Text denkbar (wenig intuitiv) und natürlich könnte man auch alles vorberechnen und im HTML hinterlegen, aber genau das sollte das Beispiel eben nicht zeigen. Alternativ ist auch die Erzeugung des canvas-Elements mittels document.createElement() zu erwägen, dann gibt es canvas nur bei aktivem JS. Dann müssten die relevanten Informationen ebenfalls in anderer Form vorgehalten werden (etwa als Text + Rasterbild).

Ansonsten käme ich prima ohne canvas-Krücke aus, wenn SVG problemlos verwendbar wäre. Das analoge SVG-Kreisdiagramm-Beispiel kommt ohne JS aus, kann aber auch nicht überall problemlos dargestellt werden. Ach ja, es gibt auch noch eine Silverlight-Variante, was ich hier nur der Vollständigkeit halber erwähne.

Permanenter Link

Die Kommentare sind geschlossen.