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.

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.

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.

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

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

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.

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.

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