Eine kurze Geschichte von HTML5

German (Deutsch) translation by Alex Grigorovich (you can also view the original English article)

Dies ist der Artikel, den Sie normalerweise überspringen. Hier werde ich keine Unze Code detaillieren, sondern die wichtigen Ereignisse beschreiben, die zu dem führen, was Sie jetzt als HTML5 erkennen. Einige von uns finden dieses Zeug interessant, aber eine Geschichtsstunde ist sicherlich nicht Ihre Vorstellung von einer guten Zeit.

…Warten Sie - sin Sie noch hier? Dann machen wir weiter.

Wir werden nicht so weit zurückreisen wie am Anfang. Das ist ein ganzes Buch für sich. Stattdessen werden wir die Uhr auf die Veröffentlichung von HTML 4.01 Ende der neunziger Jahre zurückspulen.

Was ist der Unterschied zwischen W3C, WHAT WG und HTML WG?

W3C - Eine Community mit dem alleinigen Zweck, an der Entwicklung von Webstandards zu arbeiten.
WHATWG - Gebildet, nachdem verschiedene Mitglieder des W3C durch die Richtung, die mit XHTML 2.0 eingeschlagen wurde, aufgeregt wurden. Sie bevorzugten einen anderen, weniger drastischen Ansatz, bei dem der vorhandene HTML-Code erweitert wurde.
HTML WG - Als das W3C endlich erkannte, dass XHTML 2.0 nicht die Zukunft ist, gaben sie an, dass sie mit der WHAT WG an der Entwicklung von HTML5 arbeiten wollten. Zu diesem Zweck haben sie die HTML WG gechartert.

Wenn das immer noch verwirrend klingt, machen Sie sich keine Sorgen. Lesen Sie weiter für die ganze Geschichte.

HTML vs XHTML

Ungefähr zu der Zeit, als HTML auf Version 4.01 (um 1998) vorgerückt war, begann sich der Boden etwas zu verschieben. Die Entwickler begannen, über diese nächste neue Sache zu sprechen, an der das W3C arbeitete: XHTML, das für „Extensible Hypertext Markup Language“ stand. Diese erste 1.0-Spezifikation war mehr oder weniger identisch mit HTML 4.01, abgesehen von der Aufnahme eines neuen MIME-Typs, application/xhtml+xml.

Ob Sie es glauben oder nicht, wir waren immer in der Lage, Zitate um Attributwerte(meistens) wegzulassen und keine selbstschließenden Tags. Bis vor kurzem wurde dies jedoch allgemein als schlechte Praxis angesehen. Für die Jugendlichen unter Ihren Lesern ist der Grund, warum wir es als schlechte Praxis angesehen haben, hauptsächlich auf die Popularität von XHTML zurückzuführen.

Stellen Sie sich XHTML als Ihre Großmutter vor. Wenn sie zu Besuch kommt, zwingt sie dich, deine Zähne zu putzen, aufrecht zu stehen und deine Erbsen zu essen. Ersetzen Sie nun Zähne, Körperhaltung und Erbsen durch Anführungszeichen, selbstschließende Tags und Tag-Namen in Kleinbuchstaben.

Obwohl ich meistens ein Kind bin, haben wir XHTML 1.0 als eine gute Sache angesehen - den nächsten Schritt. Designer und Entwickler mussten beim Erstellen von Markups eine Reihe von Standards befolgen. Wie konnte das schlecht sein? Die Ironie ist, dass die Mehrheit von uns, obwohl wir diese neuen Regeln befolgt haben, weiterhin Seiten mit dem text/html-MIME-Typ bereitstellte, was bedeutete, dass es dem Browser nicht wirklich wichtig war, wie wir unser Markup erstellt haben. Auf diese Weise kann XHTML aktiviert werden.

Wir haben also Markups auf eine bestimmte, strenge Weise geschrieben, um die XHTML-Validierung zu bestehen, die keinen Einfluss auf das Rendering des Browsers hatte. Ein bisschen seltsam, oder?

XHTML 1.1

Dies änderte sich mit der Einführung von XHTML 1.1 - eine bedeutende Verschiebung hin zu reinem XML. In dieser Version war der MIME-Typ application/xhtml+xml erforderlich. Sicher, das mag theoretisch wie der nächste natürliche Schritt klingen, aber es gab ein paar krasse Probleme.

1. "Auf Festplatte speichern"

Erstens konnte Internet Explorer keine Dokumente mit diesem MIME-Typ rendern. Stattdessen wird ein Dialogfeld zum Speichern auf der Festplatte angezeigt. Huch!

"Ich habe auch einige Zeit im IEBlog Kommentare gelesen und um Unterstützung für den MIME-Typ "application/xml+xhtml "im IE gebeten. Ich sollte sagen, dass IE7 diesen MIME-Typ nicht unterstützt - wir werden XHTML natürlich weiterhin lesen, wenn es als "Text / HTML" bereitgestellt wird, vorausgesetzt, es folgt den HTML-Kompatibilitätsempfehlungen." - Chris Wilson

2. Nehmen Sie keine Gefangenen

XHTML 1.1 ähnelte Professor Umbridge von Harry Potter.

Zweitens war XHTML 1.1 so etwas wie Professor Umbridge von Harry Potter: extrem hart. Haben Sie jemals bemerkt, dass der Browser nicht zurückschreckt, wenn Sie ein schließendes </li> -Tag weglassen? Browser sind intelligent und kompensieren Ihre fehlerhaften Markups (mehr dazu in Kürze). Während die Community heutzutage beginnt, diese Wahrheit zu akzeptieren und auszunutzen, wollte das W3C mit XHTML die strengere Syntax von XHTML durchsetzen. Obwohl Entwickler bis zu diesem Zeitpunkt beispielsweise das schließende <head> - oder <body> -Tag weglassen konnten, implementierte das W3C einen neuen Fehler im ersten Fehlersystem, der als drakonische Fehlerbehandlung bezeichnet wird. Wenn ein Fehler festgestellt wurde, wurde erwartet, dass der Browser das Rendern der Seite beendet und dementsprechend eine Fehlermeldung anzeigt. Wie ich schon sagte: unglaublich hart für Markup.

Infolgedessen haben nur wenige von uns jemals XHTML 1.1 verwendet; es war zu riskant. Stattdessen haben wir allgemeine Best Practices für XML übernommen und unsere Seiten weiterhin als text/html bereitgestellt.

XHTML 2

In ihren Augen wurde das W3C mit HTML 4 fertiggestellt. Sie haben sogar die HTML-Arbeitsgruppe heruntergefahren und neu gestartet und ihren Fokus auf XHTML - oder zu diesem Zeitpunkt auf XHTML 2.0 - verlagert.

XHTML2 war ein Versuch, eine Linie zu ziehen, das Web zu reparieren und das Unrecht von HTML zu korrigieren. Auch dies klingt fabelhaft, aber in Wahrheit hat es einen Großteil der Community verärgert, da es niemals abwärtskompatibel mit HTML 4 sein sollte. Tatsächlich war es auch völlig anders als XHTML 1.1!

Wohin gehe ich hier? Das W3C ignorierte im Wesentlichen das aktuelle Web und die Anforderungen seiner Entwickler zugunsten eines strengen, möglicherweise seitenbrechenden XML-Ansatzes. Es war einfach nicht praktikabel, einen so großen Übergang zu erwarten.

XHTML2 wurde nie finalisiert.

Kämpfen, kämpfen, kämpfen!

(Okay, nicht so ein Fight Club.) Ungefähr zu dieser Zeit kam wieder die Idee auf, dass "Hey - vielleicht sollten wir zu HTML zurückkehren und das abarbeiten". Die Arbeiten an Web Forms 2.0 hatten begonnen, wodurch erneut Interesse an HTML geweckt wurde, anstatt es vollständig für XHTML2 zu verschrotten. Dieser Gedanke wurde 2004 während eines W3C-Workshops auf die Probe gestellt, in dem die Befürworter von HTML ihren Fall und die Arbeit, die sie bereits mit Web Forms 2.0 geleistet hatten, vorstellten.

Leider wurde der Vorschlag mit der Begründung abgelehnt, dass er nicht dem ursprünglichen Ziel entsprach, auf XHTML2 hinzuarbeiten. Unnötig zu erwähnen, dass diese Ablehnung einige Mitglieder der Gruppe verärgerte, darunter Vertreter von Mozilla und Opera.

Die Gruppe verzweigte sich folglich und bildete die WHAT-Arbeitsgruppe (oder „Arbeitsgruppe für Web-Hypertext-Anwendungstechnologie“), nachdem sie mangels besserer Worte sauer auf die Richtung war, in die XHTML 2 zu gehen schien. Ihr Ziel war es, das Baby nicht mit dem Badewasser hinauszuwerfen. Setzen Sie die Entwicklung von HTML über drei Spezifikationen fort und erweitern Sie sie: Web Forms 2.0, Web Apps 1.0 und Web Controls 1.0.

Die zwei goldenen Regeln

Diese neue Gruppe würde zwei Grundprinzipien umfassen:

Abwärtskompatibilität ist von größter Bedeutung. Ignorieren Sie das vorhandene Web nicht.
Spezifikationen und Implementierungen müssen übereinstimmen. Dies bedeutet, dass die Spezifikation unglaublich detailliert sein sollte (daher die 900 Seiten).

"Die Arbeitsgruppe Web Hypertext Applications Technology beabsichtigt daher, die Notwendigkeit einer kohärenten Entwicklungsumgebung für Webanwendungen zu adressieren. Zu diesem Zweck wird die Arbeitsgruppe technische Spezifikationen erstellen, die für die Implementierung in Webbrowsern für den Massenmarkt, insbesondere Safari, vorgesehen sind. Mozilla und Oper." - WHATWG.org

Parser

Unterschätzen Sie nicht, wie bedeutend diese Leistung war.

Während XHTML 2.0 beabsichtigte, perfektes XML durchzusetzen, hat es sich die WHAT-Arbeitsgruppe stattdessen zur Aufgabe gemacht, genau zu dokumentieren, wie HTML ist und analysiert werden sollte. - eine fünfjährige Aufgabe!

Erinnern Sie sich, als wir darüber diskutierten, wie Browser Ihre kaputten Markups hervorragend kompensieren können? Das Interessante ist, dass es vor der Einrichtung der WHAT-Arbeitsgruppe keine Spezifikation gab, die den Browser-Anbietern Anweisungen zum Umgang mit Fehlern gab. Dies führt natürlich zu der Frage: Wie stimmten die Browser mit der Fehlerbehandlung überein? Die Antwort ist durch unermüdliches (wenn auch wesentliches) Reverse Engineering. Firefox, Safari und Opera haben die Implementierung von Internet Explorer kopiert und Internet Explorer hat das Netscape-Handling rückentwickelt.

Im Laufe von fünf Jahren hat die WHAT WG den sogenannten HTML5-Parser ermittelt. Unterschätzen Sie nicht, wie bedeutend diese Leistung war. Heutzutage analysieren alle modernen Browser HTML gemäß den Richtlinien dieser Spezifikation. Obwohl der HTML5-Parser vielleicht nicht so sexy ist wie beispielsweise canvas, ist er eine enorme Leistung.

Eine Linie im Sand

Wie zu erwarten war, wurde eine imaginäre Linie in den Sand gezogen. Sie sind entweder für XHTML2 oder (was später werden würde) HTML5.

Anstelle eines konsensbasierten Ansatzes, bei dem die Mitglieder darüber debattierten und abstimmten, was sie für das Beste hielten, nahm die WHAT WG mit Ian Hickson an der Spitze eine eher diktatorische Haltung ein.

Warten Sie - Diktator!?

Versuchen wir normalerweise nicht, diese Machthaber zu übertreiben?

Versuchen wir normalerweise nicht, diese Machthaber zu übertreiben? Was ist das Problem? Ich muss zugeben, auf dem Papier klingt es schrecklich, nicht wahr? Bestimmt einer die Zukunft des Webs? Wir bevorzugen dieses System? Politisch gesehen kann eine Diktatur eine schlechte Idee sein. Wenn Sie jedoch im Web darüber nachdenken, stellen Sie sich vor, wie viel schneller Dinge erledigt werden können. Wenn eine Gemeinschaft so leidenschaftlich ist wie unsere, tendieren die Dinge dazu, sich sehr langsam zu bewegen, während die Debatten weiter und weiter gehen... und weiter.

"Das Web ist und sollte von technischen Verdiensten angetrieben werden, nicht von Konsens. Das W3C gibt etwas anderes vor und verschwendet viel Zeit dafür. Das WHATWG tut dies nicht." - Ian Hickson

Während die Diskussion sicherlich (und zu Recht) in der WHAT WG stattfindet, hat Ian Hickson letztendlich seinen Finger auf dem Knopf (es sei denn, die Gruppe und die Community sind mit einer bestimmten Entscheidung nicht einverstanden. An diesem Punkt kann er entweder angeklagt werden (nicht als Bill) Clinton als das), oder meistens wird er seine Entscheidung neu bewerten und rückgängig machen).

Das heißt, es ist sicherlich nicht ideal. Das W3C hat seinen langsamen und stetigen konsensbasierten Ansatz, den viele immer noch bevorzugen. Auf der anderen Seite, während sich die WHAT WG schneller bewegt, gibt es sicherlich Schluckauf. Wenn Sie dann die beiden Gruppen kombinieren, kann es manchmal etwas matschig werden!

Das `time`-Debakel

Im Oktober 2011 entfernte Ian Hickson das <time> -Tag und ersetzte es durch eine allgemeinere Lösung: <data>. Mit seinen eigenen Worten:

Es gibt verschiedene Anwendungsfälle für <time>:

Einfachere Gestaltung von Datum und Uhrzeit aus CSS.
Eine Möglichkeit, das Veröffentlichungsdatum/die Veröffentlichungszeit für einen Artikel zu markieren (z. B. für Umstellung auf Atom).
Eine Möglichkeit, maschinenlesbare Zeiten und Daten für die Verwendung in Mikroformaten oder zu markieren Mikrodaten.

Die Anwendungsfälle A und B scheinen nicht viel Traktion zu haben. Anwendungsfall C gilt nicht nur für Daten, und der Mangel an Lösungen für Dinge außerhalb von Daten und Zeiten ist für viele Communities problematisch.

Vorschlag: Wir sichern die Anwendungsfälle A und B und drehen <time> auf Anwendungsfall C, ändern sie in <abbr> für maschinenlesbare Daten und machen sie wie, hauptsächlich für die Verwendung durch Mikroformate und die Mikrodatenfunktion von HTML. - Ian Hickson

Denken Sie daran: Sie haben viel mehr Kontrolle über die Form des Webs, als Sie sich wahrscheinlich zutrauen!

Was er möglicherweise nicht realisierte, war, dass ein Großteil der Community tatsächlich das <time> -Tag verwendete. Außerdem waren sie (ich selbst eingeschlossen) der Ansicht, dass das vorgeschlagene <data> -Tag zwar flexibler, aber zu mehrdeutig war; <data> hat in Bezug auf die Semantik genauso viel Bedeutung wie ein <span>.

Nach einem erheblichen Aufruhr in der Community kündigte die HTML-Arbeitsgruppe an, dass die <time> -Änderung rückgängig gemacht werden muss. Sie gaben Ian eine kurze Frist, um die Umkehrung vorzunehmen. Obwohl nicht ohne zusätzliche Dramaebenen, wurde <time> im folgenden Monat wieder eingesetzt.

Diese Ereigniskette beweist lediglich, dass die gesamte Web-Community - und natürlich die Browser-Anbieter - ein gewisses Maß an Kontrolle über die Spezifikation hat, obwohl Ian das Recht hat, diese Art von Änderungen vorzuschlagen. Es gibt einen Unterschied zwischen den Erstellern von Spezifikationen und den Autoren, die diese neuen Elemente und APIs in ihre Projekte integrieren. Wenn die Autoren sie nicht verwenden, können sie auch aus der Spezifikation entfernt werden. Denken Sie daran: Sie haben viel mehr Kontrolle über die Form des Webs, als Sie sich wahrscheinlich zutrauen!

Melde dich für die verschiedenen Mailinglisten an und sei laut! Andernfalls wissen Leute wie Ian nicht, ob oder wie Sie diese neuen Funktionen verwenden.

„Gibt es Daten, die zeigen, wie Menschen <time> in der Praxis tatsächlich verwenden? d.h. gibt es tatsächlich jemandem einen seiner hypothetischen Vorteile?" - Kommentar von Ian Hickson

Die Form einer Spezifikation

Während einige vielleicht denken, dass eine kleine Gruppe von Menschen die Zukunft des Webs bestimmt, ist dies weit davon entfernt. Drei Fraktionen erhalten das gleiche Gewicht, wenn es um Spezifikationen geht.

Spec Creators - Offensichtlich...
Autoren - Leute wie wir; wenn wir ein bestimmtes Element oder eine bestimmte API ablehnen (d. h. nicht verwenden), kann es genauso gut tot im Wasser sein.
Anbieter - Browser haben eine große Menge an Eingaben in diese Spezifikationen, die oftmals wegweisend sind.

Wenn Sie mehr über das <time> -Debakel erfahren möchten, lesen Sie den Bug-Thread und Ians Google+ Beitrag. Sie sind interessante Lektüren und nicht annähernd so schwarz oder weiß, wie Sie vielleicht denken.

Zurück im W3C…

Zurück zur W3C vs. WHAT WG Fehde. Nun, es war weniger eine Fehde als vielmehr zwei Gruppen, die sich ein paar Jahre lang ignorierten.

Mit der Zeit wurde immer klarer, dass XHTML 2.0 nicht die Lösung war.

Während die Arbeit an der WHAT WG relativ schnell voranschritt, lief die Arbeit an XHTML 2.0 am W3C - wie soll ich das sagen... - nicht gut (fast nicht vorhanden). Im Laufe der Zeit wurde immer klarer, dass XHTML 2.0 nicht die Lösung war (obwohl es erst 2009 vollständig gelöscht werden würde). Im Jahr 2006 gab das W3C nach und signalisierte, dass es an einer Zusammenarbeit mit der WHAT WG bei (was wäre) HTML5 interessiert sei. Zu diesem Zweck haben sie eine weitere Gruppe gegründet: HTML WG oder die Hypertext Markup Language Working Group.

Sie wollten die Arbeit der WHAT WG als Grundlage für die Weiterentwicklung von HTML verwenden. Seltsam, oder? Jetzt haben wir zwei verschiedene Gruppen: die W3C HTML WG und die WHAT WG. Technisch gesehen hatte das W3C XHTML noch nicht aufgegeben. Im Rahmen der neu gegründeten HTML-Arbeitsgruppe wurde Web Apps 1.0 in HTML5 umbenannt.

"Apple, Mozilla und Opera haben es dem W3C ermöglicht, die Spezifikation unter dem W3C-Copyright zu veröffentlichen, während eine Version mit der weniger restriktiven Lizenz auf der WHAT WG-Site beibehalten wurde." - WHATWG.org

Heute

Heutzutage arbeiten WHAT WG und W3C bei HTML5 zusammen. Es ist eine seltsame Beziehung, aber dank eines endlosen Angebots an unglaublich leidenschaftlichen Aktivisten funktioniert es irgendwie.

Dieser Artikel ist ein Auszug aus meinem kommenden Buch über HTML5 und seine Freunde. Weitere Informationen zum Veröffentlichungsdatum finden Sie unter Nettuts+!