Ich dachte html5 soll immer html5 bleiben und einfach immer weiter entwickelt werden

Nein es soll nur noch html geben.

Es gibt wiedermal 2 Ansätze, die der (viel zu kurze) Artikel nicht erklärt. Vielleicht hätte der Autor in diesem Falle doch mal abschreiben sollen. Hier bei Golem wird es genauer erklärt:

Golem.de: "HTML5 soll erst 2014 fertig werden":

Das W3C hält an Versionsnummern für HTML fest, daher HTML 5 und HTML 6 …

Die WHATWG will keine Versionsnummern und stattdessen stetige Weiterentwicklung von HTML im "laufenden Betrieb". Außerdem gibt es in dieser Gruppe bereits Unterstützung für HTML-Elemente, die das W3C gar nicht auf ihrer Liste hat.

Freut euch also wiedermal auf ein Durcheinander beim Webdesign! Eine Einigung und Verbesserung des jetzigen Chaos' ist also erneut nicht in Sicht …

Das wird dann aber knapp einen Video Standard festzuschreiben. Und wenn das nicht passiert, bleibt es beim Flash Plugin das ja auch h.264 kann

Und wieder einmal ist eine Nichtmeldung zur Meldung geworden und geistert falsch interpretiert um die Welt. Und wieder einmal ist nicht verstanden worden, wie die internen, formalen Prozesse und Abläufe beim W3C sind. Und dass die formalen Abläufe und Stati und Stationen bis hin zur REC nichts über deren Inhalte aussagen.

Und wieder einmal hat mit o.wunder einer überhaupt nicht verstanden und in den falschen Hals bekommen, worum es geht und worüber er spricht...

Echt traurig.

o.wunder:

Schreibt Dir irgendeine Spezifikation des W3C vor, welches Bildformat Du zu nehmen hast, wenn Du <img> verwendest? Nein. Und bei <audio> und <video> ist es genauso! Schon mal was von Fallback gehört? Welchen Zweck soll ein Fallback erfüllen? Sollte man sich da einig sein bzgl. eines Fallbacks, einer "last line"?
Das, was Du ansprichst, ist ein möglicher Fallback-Codec! Also einer, den man stets NEHMEN KÖNNEN SOLLTE. Aber NICHT MUSS! Ist es dafür sinnvoll sich zu einigen auf einen Codec? JA!
Verhindert das Nichtdefiniertsein eines solchen Fallback-Codecs den Einsatz von <audio> und <video>? Nein!
Es darf als refernzierter Codec für das src-Attribut JEDER Codec genommen werden, der da draußen rumschwirrt! Es war nie anders gedacht! Und wird nie anders sein! Bei Bildern darf man doch auch selber frei wählen, in welchem Format ein Bild referenziert wird. Und hier ist es nicht anders, war nie anders, wird nie anders sein.
Es dreht sich allein und nur um die Definition oder Nicht-Definition eines Fallback-Codecs. Eines Codecs als "last line", falls der gewünschte Codec auf dem Zielsystem aus irgendwelchen Gründen nicht vorhaqnden ist oder nicht genommen werden darf, weil dessen Lizenz das z.B. nicht erlaubt (was bei H.264 ganz schnell der Fall sein kann, wo aus privatem Gebrauch plötzlich ein kommerzieller Gebrauch wird und von der Lizenz nicht mehr abgedeckt ist).

Welchen Zweck erfüllt denn das alt-Attribut bei <img>? Welchen Zweck erfüllt denn die Angabe "serif" oder "non-serif" bei CSS?

Stati status (mit langem u gesprochen)

@sirkb

also kann man das so verstehen, da der Codec ja "nur" eine Untermenge des video-tags ist dass damit die Frist bis Mai 2011 nicht für den Codec gilt. Es ist schliesslich nichts "neues" was dem HTML5 Standard hinzugefügt werden soll. Das neue ist das "video-tag" und das ist ja schon enthalten.

Stattdessen "will man die eingereichten Anmerkungen und Vorschläge durchgehen und eine Implementierung des Standards ausarbeiten."

Das liest sich für mich so, als ob in dieser mehrjährigen Phase auch der Fallback Video Codec seinen Raum zur Diskussion und Festlegung bekommen wird.

Dann haben Google und die MPEG ja noch genug Gelegenheit sich auf einen Codec zu einigen...

2014 vool lahm für all die Promotion, die der Apfel da gemacht hat... Die W3C sollte mal sich mal einen schnelleren Prozessor zulegen. Vieleicht dauerts dann nicht immer bis zum Jahre Schnee

Retrax:

Jein. Ich störe mich an dem von Dir gewählten Begriff "Untermenge". Schau in die Spezifikation rein, da ist kein Codec festgeschrieben. Da sind lediglich beispielhaft alle möglichen Codecs aufgeführt und benannt, die man da draußen in freier Wildbahn trifft. U.a. auch H.264. Es ist zwar nicht besonders klug und schlau, als einzigen und allerersten Codec als Source für sein angebotetens Video zu nehmen, aber es ist von der Spezifikation voll gedeckt und völlig in Ordnung. Apple liefert seine Videos auf seinen Webseiten, die Apple inzwischen alle als HTML5 darbietet, übrigens als H.264-Dateien via <video> und <source> aus. Von der Spezifikation her völlig in Ordnung. Nur macht Apple das leider nur für Safari, und für andere Browser liefert Apple die Videos als in Quicktime gekapselte H.264-Videos (.mov) via aus. Sinnvoll und schlau wäre es, wenn Apple den anderen Browsern nicht in Quicktime gekapselte H.264-Videos anbieten würde, sondern zum Beispiel diesen dieselben Videos als WebM- oder Theora-variante anbieten würde (sie machen sich ja sowieso die Mühe und bieten zweierlei an, da könnten sie dann auch den anderen Browsern ebenfalls via <video>-Element dann WebM-Videos anbieten statt diese in Quicktime zu kapseln. Da Apple ein grundsätzliches Problem mit WebM und Theora zu haben scheint, machen sie es halt nicht). Aber so, wie sie Safari diesbzgl. behandeln, also das nackte H.264-Video per <source> in <video> einbinden, so ist das gemäß Spezifikation zulässig und im Sinne der Spezifikation. Weil die Spezifikation hier kein e Vorgaben macht, noch nie gemacht hat und auch nie machen wird.

Was Anderes ist aber der Fallback-Codec, den man da ggf. ZUSÄTZLICH oder eben stattdessen nehmen KANN, wenn man z.B. nicht sicher ist bzw. sein kann, ob auf der Gegenseite überhaupt der H.264-Codec installiert ist (also ähnlich wie bisher bei Schriften, deshalb gibt es ja auch betriebssystemweit und browserweit gültige und einstellbare sogenannte generische Schriftarten, also eine Schriftart, die dem generischen Begriff "serif" zugeordnet ist .. meist "Times New Roman" oder "Times" bzw. für non-serif dann z.B. "Arial" oder "Helvetica"). Will heißen: wenn nix anderes gefunden werden kann, dann wird ggf. auf diese Schriften zurückgegriffen.

Und ähnlich sollte man auch das Thema rund um den Fallback-Codec bei HTML5 <video> begreifen. Sprich: ein Codec, der in der Spezifikation als Fallback-Codec definiert ist und auf den man sich geeinigt hat (Einigkeit muss sein, sonst wird der Fallback an sich ad adsurbum geführt, wenn jeder da was Anderes drunter versteht). Das heißt, an dieser einen Stelle, an der Stelle des zu definierenden wünschenswerten Fallback-Codecs herrscht bisher keine Einigkeit.

Ähnlich, als wäre man sich nicht einig darüber, ob nun im alt-Attribut für das <img>-Element Text stehen soll oder ein weiteres Bild etc.

Zumal das <video>-Element Schachtelung erlaubt und mehrere Codecs erlaubt, die man da angeben kann, und man kann auch eine Prioritätenliste vorgeben, welcher Codec mit welcher Priorität als erstesy genommen werden soll/sollte bzw. der Browser des Client fragt automatisch ab, was denn zur verfügung steht und pickt sich dann den Codec raus, der am besten für ihn passt, das sieht HTML5 alles vor.

Es ist auch denkbar und möglich und ja sogar derzeit durchaus manchmal sinnvoll, wenn man z.B. Flash als Fallback dort einsetzt. Also eine Flash-Quelle einbettet als weitere Wahlmöglichkeit zwischen <video> und </video>. Sprich: als Erstes wird abgetestet, ob der Browser überhaupt <video> beherrscht, und wenn ja, welche Codecs er bzw. das System beherrscht. beherrscht er einen der Vorgaben, dann wird der betreffende vorhandene Codec genutzt unter Berücksichtigung der obligatorischen Prioritätenliste.
Beherrscht er keinen der dort angegebenen Codecs, so könnte/dürfte/sollte er dann zum Beispiel auf den derzeit strittigen Codec zurückfallen und das betreffende Video, das natürlich vorliegen muss, dann mit dem Codec abspielen.
Oder/und man gibt als weiteren Fallback dann z.B. ein in Flash eingebettets Flash-Video an. Sprich: Kaqnn der betreffende Browser kein HTML5 <video>, oder beherrscht er keinen der angebotenen Vodeo-Codecs, und ist auch kein weiterer Video-Codec definiert, so wird dann als Fallback dann eben das Flash-Video eingebettet und abgespielt (vorausgesetzt, Flash ist auf der Gegenseite überhaupt installiert). Mit dieser Flash-Fallback-Lösung könnte man zum Beispiel IE6, IE7 und IE8 noch bedienen, die bzgl. <video> ja so gar nix am Hut haben. Alle anderen Browser, die das <video>-Element kennen (und das tun eigentlich alle aktuellen Browser, zählt man den IE9 da mit hinzu), die spielen das Video dann nativ in einem der angegebenen Video-Codecs mit der definierten Prioritätenreihenfolge ab. Sind mehrere Video-Codecs angegeben, liegt das Video also in mehreren Erscvheinungsformen vor, so bedient sich jeder Browser genau bei dem Codec, der am besten zu ihm passt.

Youtube funktioniert zum Beispiel so. Neu hochgeladene Videos werden seit mai 2010 automatisch gleich in WebM bei Youtube abgelegt und kodiert und dann erst im zweiten Schritt als Doublette im H.264-Format.

Lies lieber die Originaltexte des W3C. Da hast Du es unverfälscht statt evtl. falsch interpretiert. Wenn der interne bürokratische Apparat beim W3C bestimmte Zeiträume festlegt, ab wann eine Spezifikation den REC-Status erreicht, dann hat das nichts aber auch gar nichts zu tun mit dem inhaltlichen Fortschritt dieser betreffenden Spezifikation. Die kann meinetwegen 3 jahre lang als Draft vorliegen und trotzdem schon total stabil und verfestigt sein ohne weitere Änderungen. Und dann nochmal 2 Jahre als sog. Candidate Recommendation. Und dann erst irgendwann als Recommendation. Und zwischendrin hat sich am Inhalt NICHTS geändert. Das hat mehr mit den organisatorisechen Abläufen beim W3C zu tun und zum Beispiel mit ausgiebigen Tests der jeweiligen Implemeteure (hier: die Browser-Hersteller). Sind die schnell und fix und reichen immer fleißig ihre Tests ein, so geht's schnell voran. Sind sie behäbig, dauert's länger. Weil die Regularien beim W3C vorschreiben, dass eine bestimmte Anzahl von Implementeuren eine gewisse Anzahl von Tests eingereicht haben muss, bevor eine Spezifikation auf der Leiter einen Schritt nach oben kletterne kann. Und an dieser Front hakt's im Moment noch. Da ist nämlich fast der Einzige, der da überhaupt Tests einreicht, ausgerechnet die Firma Microsoft, die sich da vorbildlich verhält und wo man zügig bei der Sache ist. Tests schreiben macht nämlich keinen Spaß und ist eine undankbare Aufgabe. Das macht niemand gerne und schon gar nicht gerne freiwillig. Und von den anderen Browserherstellern leigen bisher halt noch kaum bzw. noch keine Tests vor. Müssen aber, damit die Spezifikation im Fahrplan weiterkommen kann. Da muss sich inhaltlich nichts ändern, aber erst, wenn alle Browser-Hersteller ihre Tests eingereicht haben und auch bei diesen Tests alle unisono keine Probleme haben (jeder reicht natürlich nur solche Tests ein, wo sein Browser natürlich mit bravour durchmarschiert, damit wirbt Microsoft ja derzeit so fadenscheinig, indem sie sagen: "Unser IE9 absolviert alle Tests, unser Browser ist 100% HTML5-fähig", dabei aber unterschlagend, dass man ja nur einen Ausschnitt eingereicht hat und der eigene Browser bei einem Test eines Konkurrenten evtl. bös auf die Schn... fallen kann/könnte). Deshalb ist es wichtig, dass möglichst VIELE Tests eingereicht werden von möglichst vielen beteiligten Browser-Herstellern. Und das ist bisher halt leider noch nicht der Fall. Mozilla ist da säumig bisher, Opera ist da säumig, und Apple auch. Vorbildhaft eben ausgerechnet Microsoft. Die haben fleißig abgeliefert.

Zu sagen ist außerdem noch: Derzeit läuft die Phase des "Last Call" für die HTML5-Spezifikation. Letzter Aufruf, um irgendwo die Hand zu heben. In gut zwei Monaten ist diese Phase abgeschlossen, dann kommt die Phase "Call for Implementations". Also der Aufruf an die Browser-Hersteller: JETZT könnt ihr das alles implementieren! Wenn Du Dich recht erinnerst: Genau DAS machen die Browser-Hersteller aber sogar schon längst! Seit 2007 machen die nix Anderes als diesen Schritt schon bereits umzusetzen. Die sind also schon alle kräftig dabei, obwohl sie es laut Fahrplan erst in zwei Monaten beginnen müssten! GLEICHZEITIG mit diesem Call for Implementations wird die HTML5 Spezifikation in den Stand der "Candidate Recommendation" erhoben und ist API-stabil und feature complete. API-stabil und feature complete. Ab April/Mai 2011! Der Rest, der dann folgt, ist reine Bürokratie beim W3C. Ab dann wird diese Spezifikation nicht mehr groß angefasst und geändert. Wird sie jetzt schion nicht mehr. Jetzt werden nur noch Fehler, wozu auch rechtschreibfehler gehören, oder grobe Formulierungsfehler, rausgehauen. Also ab April/Mai, nur noch wenige Wochen, und man kann das Ding nehmen und getrost damit arbeiten.

Mit CSS2 Revision 1 ist das derzeit und seit Jahren auch schon so. Die hüpft demnächst bzw. in diesem Jahr erst in den End-Status Recommendation. Und mit ihr arbeitet man ja auch schon seit Jahren und nutzt verschiedene Dinge daraus.