
Wann immer ich Klagen höre, eine HTML5-API sei unzureichend in Browsern implementiert oder wäre einfach nur schlimm, denke ich mir: ändere es doch! Man muss kein Browserhersteller sein um HTML5 zu verbessern und man muss sich auch nicht auf Mailinglists von den hohen Herren abwatschen lassen – ein paar Zeilen JavaScript zu schreiben reicht. So ist etwa das HTML5-Element Canvas ein recht unhandliches Teil. Dank seiner etwas web-fremden Low-Level-Konzeption kann man mit einem normalen 2D-Context eigentlich so gut wie gar nichts anfangen, da die API viel zu rudimentär und benutzerunfreundlich ist. Um etwa das oben rechts abgebildete Strichmännchen darzustellen, müsste man das folgende Monstrum konstruieren:
var context = canvas.getContext('2d');
// Pfad beginnen
context.beginPath();
// Körper
context.moveTo(240, 100);
context.lineTo(240, 200);
// Beine
context.lineTo(190, 250);
context.moveTo(240, 200);
context.lineTo(290, 250);
// Arme
context.moveTo(240, 150);
context.lineTo(190, 150);
context.moveTo(240, 150);
context.lineTo(290, 150);
// Linie ziehen
context.lineWidth = 4;
context.strokeStyle = '#CC0000';
context.stroke();
context.closePath();
// Kopf
context.beginPath();
context.arc(240, 80, 35, 0, 6.28318531, false);
// Kopf zeichnen
context.fillStyle = context.strokeStyle;
context.fill();
context.stroke();
context.closePath();
Das ist dann doch recht mühsam. Aber das Canvas-Element ist auch gar nicht dafür gemacht, so direkt eingesetzt zu werden, es ist vielmehr eine Steilvorlage für JavaScript-Bibliotheken. Diese können dann spezialisiertere und/oder etwas leichter zu nutzende APIs umsetzen. So wäre der obrige Code-Brocken doch gleich schon viel angenehmer zu scheiben und zu lesen, wenn die Methoden jQuery-artig verkettet wären:
var context = CanvasQuery('test');
// Körper
context.moveTo(240, 100).lineTo(240, 200);
// Beine
context.lineTo(190, 250).moveTo(240, 200).lineTo(290, 250);
// Arme
context.moveTo(240, 150).lineTo(190, 150).moveTo(240, 150).lineTo(290, 150);
// Linien ziehen
context.set({'lineWidth': 4, 'strokeStyle': '#CC0000'}).stroke().closePath();
// Kopf
context.beginPath().arc(240, 80, 35, context.deg2rad(0), context.deg2rad(360), false);
// Linien ziehen
context.set('fillStyle', context.get('strokeStyle')).fill().stroke().closePath();
Die Canvas-API entsprechend umzubauen ist keine Herkulesaufgabe, nur knappe 60 Zeilen Code sind dafür nötig. Sowas kann jeder halbwegs fähige JavaScript-Nerd schreiben und es könnten auf diese Weise viele nicht nativ in Browsern implementierte HTML5-APIs nachgebaut oder ausgebessert werden, wie etwa die gruselige Drag-&-Drop-API oder die in den meisten Browsern nicht vorhandene API für data-*
-Attribute. Ein perfektes Beispiel hierfür ist jStorage, eine kleine JS-Bibliothek, die dafür sorgt, dass eine Website clientseitig Daten speichern kann und sich um die Macken der diversen Browser kümmert.
Von genau dieser Sorte Script braucht die Welt mehr. Die Schlacht um ein besseres HTML5 muss nicht nur in den Arbeitsgruppen von W3C und WHATWG geschlagen werden sondern auch draußen im Web, von uns Webworkern. Wenn den großen Entscheidern mal eine Schnittstelle missrät oder wenn einfach mal etwas nur unzureichend implementiert ist, haben wir selbst es in der Hand, mit etwas JavaScript für eine De-facto-Reparatur zu sorgen. Also frisch ans Werk!
Kommentare (14)
Serophos ¶
7. September 2010, 10:00 Uhr
Hier ist ein "ist" zuviel: "So ist etwa das HTML5-Element Canvas ist ein"
und nachfolgend ist sicherlich nicht ein 2D-Contest gemeint ;o)
Inhaltlich stimme ich vollkommen zu :o)
Peter ¶
7. September 2010, 10:19 Uhr
Doppel-Ups. Danke für die Hinweise.
Chris ¶
7. September 2010, 10:33 Uhr
Ich finde es ok, dass du diese Thema ansprichst und zu Diskussion sowie Aktion aufrufst.
Allerdings glaube ich nicht, dass jeder Webentwickler Zeit und Lust hat, sich mit halbfertigen und schlecht funktionierenden API's zu beschäftigen und eine "Workarround" zu bauen, damit es vorübergehend - bis zur nächsten Änderung / Down..äh Upgrade - funktioniert.
Sicherlich gibt es dann solche Frameworks wie JQuery, MooTools & Co die schon Lösungen anbieten, aber diese müssen auch up to date gehalten werden.
Ich bin der Meinung, dass Browserhersteller, als auch die Arbeitsgruppen ihrer Arbeit nachgehen sollten und langsam aber sicher zu einen "Punkt" kommen sollten. Mir wird es schier übel wenn ich jedesmal - auch wenn ich FireFox-Fan bin - den Mozilla-Blog ( http://hacks.mozilla.org/ ) lese und wieder ein tolles -moz und mozIrgendwas - Feature lese. Fast schon schlimmer wie die CSS-/JS-Hacks für unseren Freund aus Remondis.
Gruß
Chris
Peter ¶
7. September 2010, 10:50 Uhr
Die Browserhersteller und Arbeitsgruppen werden zumindest bei HTML5 nie zu einem „Punkt“ kommen. Ein fertiges HTML5 oder gar HTML6 wird's nach heutigem Stand nie geben. Da kann man lange drauf warten :)
lordrost ¶
7. September 2010, 11:23 Uhr
ist man als webworker tatsächlich dafür zuständig mistige browser zu verbessern?
:( anscheinend bleibt einem nichts anderes über...
ausser man schreibt selbst einen browser-.-
Chris ¶
7. September 2010, 11:34 Uhr
Sicherlich, weil sie sich einfach übernommen haben. :-)
FrankyBoy ¶
7. September 2010, 11:57 Uhr
wieso gibts überhaupt ne moveto anweisung? klingt ja fast als würd man turtles in netlogo rumschicken die dann ne spur ziehn. ich mein, warum nimmt man ned normale funktionen wie sie alle anderen toolkits auch haben im Sinne von drawLine(x1, y1, xlen, ylen) oder für kreise/Rechtecke sowas wie draw/fillCircle/Rect(x, y, width, height[, rotation]) ...
KLaus ¶
7. September 2010, 12:21 Uhr
HTML5 mit Javascript nachzurüsten kann doch wohl nicht die Lösung sein. Wie wollt ihr denn dann die Funktionalität für Browser nachrüsten, die Javascript ausgeschaltet haben?
Peter ¶
7. September 2010, 12:31 Uhr
Zitat FrankyBoy:
Die
moveTo()
-Methode ist da, damit wir darauf so etwas wie einedrawLine()
-Funktion aufsatteln können. Klingt doof, ist aber so.Zitat KLaus:
Es geht hier doch vorrangig um Javascript-APIs selbst. Da macht es keinen Unterschied, ob bei abgeschaltetem JS die eingebaute oder die nachgebaute API ausfällt.
cmi ¶
7. September 2010, 14:24 Uhr
Sorry für (m)einen unqualifizierten Beitrag, aber der verlinkte Comicstrip ist göttlich. Danke dafür!
non ¶
7. September 2010, 16:45 Uhr
HTML5 seinen eigenen Bedürfnissen entsprechend anpassen? Das ist hochgradiger Unsinn und nein kein Webworker selbst der Otto Normalwebworker sollte diesen Schwachsinn tatsächlich betreiben!
Sonst führt das noch irgendwann dazu, dass jeder sein eigenes HTML schreibt und keiner mehr den Code des anderen versteht weil dieser mit Javascript sein eigenes HTML geschaffen hat. Richtig bunt wird es dann wenn mehrere solcher Pappenheimer zufällig ähnliches verändern und im Nahinein wo beides verwendet wird gar nichts mehr funktioniert...
Hinzu kommt, dass es einfach nicht sein kann, dass man JavaScript für das Betrachten einer Webseite voraussetzt.
Sorry, aber du hattest schon deutlich besser Beiträge, das hier ist einfach nur Müll!
WebDude ¶
7. September 2010, 17:50 Uhr
Guter Artikel.
@KLaus, non
Es geht um Fixes für JavaScript-API's und um die Gewährleistung einheitlicher Kompatibelität in verschiedenen Browsern. Wenn die Hersteller das nicht hinkriegen, muss das eben von unten kommen. Libs wie jQuery, MooTools haben das vorgemacht.
Davon abgesehen ist JavaScript heute absoluter Standart und kann (mindestens in Webapps, aber eigentlich auch auf jeder Seite) vorausgesetzt werden.
Peter ¶
7. September 2010, 19:45 Uhr
Zitat non:
APIs aus- und verbessern. So wie es jQuery macht. Es sei denn auch das ist für dich Teufelszeug …
Sven ¶
12. September 2010, 12:13 Uhr
"Die ersten ie-hacks waren die Schlimmsten,
die zweiten ie-hacks waren auch die Schlimmsten,
die dritten ie-Hacks haben mir überhaupt keinen Spaß gemacht und
beim ie7 hab ich etwas die Lust verloren..."
Marvin, depressiver WebworkingRoboter
(irgendwann mach ich mir ein T-Shirt draus...)