1295690698|%d.%m.%Y
Schon lange war einiges unklar. Die WHATWG forcierte die Weiterentwicklung von HTML, und das W3-Konsortium war dafür zuständig, HTML5 normativ festzuschreiben. Nun könnte man mit dieser Arbeitsteilung gut leben, wenn der Festschreibungsprozess die Entwicklungen ohne Wenn und Aber zeitnah in definierte HTML-Versionen übernehmen würde. Doch dergleichen war eigentlich nie erkennbar. Nun könnte die Sache eskalieren.
Die Eskalation begann, wenn man so will, mit einer Grafik, nämlich dieser:
HTML5-Logo des W3-Konsortiums
It stands strong and true, resilient and universal as the markup you write. It shines as bright and as bold as the forward-thinking, dedicated web developers you are. It's the standard's standard, a pennant for progress. And it certainly doesn't use tables for layout.
Übersetzung:
Es steht stark und wahrhaftig, unverwüstlich und universell, genau wie das Markup, das du schreibst. Es strahlt so leuchtend und kräftig wie die worwärts denkenden, engagierten Web-Developer, die ihr seid. Es ist der Standard der Standards, der Wimpel für den Fortschritt. Und es verwendet ganz sicher keine Tabellen fürs Layout.
Bevor ich dieses Zitat von der W3C-HTML5-Logo-Seite bewusst gelesen habe, hatte ich meine Irritationen über die Grafik bereits selber in Worte gefasst. Es ist eine Grafik, die fatal an die plakative Kunst der ideologisch geprägten und kriegerischen Phasen des 20. Jahrhunderts erinnert. Und das Zitat des W3-Konsortiums bestätigt diese Ausrichtung. Stark und wahrhaftig, vorwärts, leuchtend und kräftig … nein, ich möchte jetzt gar nicht weiter ausführen, was das alles assoziiert bei mir. Das mag eine spezifisch deutsche Hypersensibilität sein, doch es bleibt die Frage, warum das W3-Konsortium ausgerechnet die Standhaftigkeitssymbolik eines Ritterschildes braucht, um der Welt seinen Part bei HTML5, nämlich Normierung und Versionierung, zu erklären.
Jedenfalls brachte diese etwas ungehobelte HTML5-macht-frei-Attitüde offenbar ein Fass zum Überlaufen — auf der anderen Seite, bei der WHATWG. Dort reagierte man nämlich mit einem recht deutlichen Blog-Artikel, HTML is the new HTML5, betitelt und geschrieben vom nicht ganz unumstrittenen WHATWG- und HTML-Federführer Ian Hickson persönlich. Genaugenommen handelt es sich gar nicht um eine Replik auf das HTML5-Logo des W3C, sondern um eine interne Definitionskorrektur. Die WHATWG hat nun selber erkannt, dass HTML5 eine irreführende Bezeichnung ist für einen Standardisierungsprozess, der sowieso nie zur Ruhe kommt. Ian Hickson dazu:
1. The HTML specification will henceforth just be known as "HTML", with the URL http://whatwg.org/html. (We will also continue to maintain the Web Applications 1.0 specification that contains HTML and a number of related APIs like Web Storage, Web Workers, and Server-Sent Events.)
2. The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth.
Übersetzung:
1. Die HTML-Spezifikation wird ab sofort „HTML“ genannt, mit der URL http://whatwg.org/html. (Wir werden auch die Spezifikation Web Applications 1.0 weiter pflegen, die HTML und eine Reihe von angeschlossenen APIs wie Webstorage, Webworkers und serverseitig gesendete Ereignisse enthält.)
2. Die HTML-Spec der WHATWG kann nun als „lebender Standard“ betrachtet werden. Sie ist ausgereifter als als alle Versionen der bisherigen HTML-Spezifikation, und deshalb finden wir es nicht mehr sinnvoll, sie nur als Entwurf zu behandeln. Wir werden nicht länger dem "Schnappschuss"-Modell der Spec-Entwicklung folgen, mit Gelegenheiten wie „Aufforderung zum Kommentieren“, „Aufforderung für Implementierungen“ usw.
Wer die Szene kennt, liest hier ganz deutlich heraus, dass Ian Hickson nicht länger gewillt ist, sich mit der ewigen Bremserei des W3-Konsortiums abzufinden. Und mit dieser Einschätzung trifft er durchaus den Nerv vieler Entwickler. Peter Kröner etwa, Autor des ersten deutschsprachigen Buchs über HTML5, schildert im Technikwürze-Podcast "HTML5 total" die Situation so:
Da haben wir einerseits eine Spezifikation von einer neuen HTML-Version, die vom W3C gepflegt wird. Dann haben wir eine andere Spezifikation von HTML plus ein paar Erweiterungen, die von einer anderen Arbeitsgruppe gepflegt wird, die das Ganze auch initiiert hat. Und dann haben wir noch einen großen Kreis an erweiterten Technologien, wie zum Beispiel die Geolocation-API, die überhaupt nichts mit HTML5 zu tun haben, oder sehr wenig, weil sie früher mal in den Spezifikationen drin standen (mittlerweile nicht mehr) - und dieses ganze Konvolut aus technischen Spezifikationen wird umgangssprachlich als HTML5 bezeichnet.
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <title>Squark mp3 Player</title> </head> <body> <script language="JavaScript" src="http://webkompetenz.wikidot.com/local--files/intern:src/audio-player.js"></script> <object type="application/x-shockwave-flash" data="http://squark.wdfiles.com/local--files/dev:8/player.swf" id="audioplayer1" height="24" width="290"> <param name="movie" value="http://webkompetenz.wikidot.com/local--files/intern:src/player.swf"> <param name="FlashVars" value="playerID=1&soundFile=http://technikwuerze.de/blogmin/podpress_trac/web/904/0/tw169.mp3"> <param name="quality" value="high"> <param name="menu" value="false"> <param name="wmode" value="transparent"> </object> </body> </html>
Technikwürze-Podcast "HTML5 total" (2:18'04'')
Kröner schlägt sich deutlich auf die Seite derer, die sich eigentlich ganz von eherner Versionenfestschreibung lösen wollen. In den vergangenen Jahren hat sich das Web schnell weiter entwickelt, teilweise in Richtungen, die zuvor kaum absehbar waren. Script- und Style-ergänztes HTML als Code-Basis für alles im Web, egal ob es sich Wikipedia, Twitter, Facebook oder Second Life nennt, muss sich solchen Veränderungen letztlich zeitnah und flexibel anpassen. Diese Basis muss an einem definierten Ort verbindlich dokumentiert werden, doch eine solche Dokumentation muss nicht statisch sein in dem Sinne, dass es sich um eine über Jahre oder gar Jahrzehnte unberührte Steintafel handelt.
Klassische W3C-Empfehlungen (Recommendations) von Markup- oder Style-Sprachen haben noch stark diesen Steintafel-Charakter. Die Absicht dahinter ist durchaus nachvollziehbar: man will Standards haben, die nicht nur für Entwickler normativ sind, sondern vor allem auch eines: maschinenlesbar. So basiert die gesamte vom W3-Konsortium favorisierte XML-Architektur auf diesem Prinzip. Dabei ist die beschreibende Dokumentation letztlich nur eine Textergänzung zum eigentlichen Kern, nämlich dem maschinenlesbaren Dokument, der sogenannten Document Type Definition (DTD) oder dem XML-Schema.
In der Praxis hat sich jedoch gezeigt, dass sich die Maschinenlesbarkeit meist mit der bloßen Sprachkonvention begnügt. Die Validierbarkeit gegen eine bestimmte, offizielle DTD wird dagegen kaum benötigt. So kommen beispielsweise XML-basierte Webservices durchaus häufig zum Einsatz im Web. Dabei ist aber letztlich entscheidend, was der Diensteanbieter spezifiziert, und nicht, was in der W3C-Spezifikation der eingesetzten XML-Sprache steht.
Bleibt der normative Aspekt für Entwickler. Ältere Web-Semester können sich noch gut an die fröhlichen, wirren Anfänge Mitte bis Ende der 90er Jahre erinnern, als jeder einflussreiche Software-Anbieter das Web mit seinen Erfindungen umkrempeln wollte. Netscape, Microsoft, Adobe, Macromedia und Apple, alle wollten letztlich ein Web, das auf ihren Firmenstandards basierte. In dieser Situation forderten kluge Köpfe die unbedingte Einhaltung firmenunabhängiger Standards ein. Und eine ganze Generation führender Webdesigner achtete schließlich akribisch auf die genaue Einhaltung dessen, was im HTML4-Standard vorgeschrieben war. Allerdings kippte diese Akribie alsbald in ein unschönes Oberlehrertum und Beamtentum um. Denn wo immer bedingungsloser Gehorsam gefordert wird, und sei es nur gegenüber einem Sprachstandard, wird letztlich eine ganz bestimmte Sorte von Köpfen angezogen. Und das sind nicht gerade die kreativen.
Die Kreativen aber waren es, die das Web weiter brachten und zu dem Mitmach- und Mobilitäts-Web machten, das wir heute kennen. Sie sind es auch, die heute die maßgeblichen Anwendungen entwickeln. Und sie bevorzugen dabei flexible Normen wie bei Extreme Programming oder Social Coding auf Repository-Plattformen wie Github. In diesen Kreisen wird Randunschärfe, wie sie durch Bewegung typischerweise entsteht, als normal empfunden. Beliebte Frameworks wie JQuery federn typische Probleme wie Browser-Inkompatibilitäten im Hintergrund ab. Programmiersprachen mitsamt Compilern und Interpretern entwickeln sich ständig weiter. Warum sollte das bei verwendeten Markupsprachen mitsamt ihren APIs anders sein?
Es ist also kein Zufall, wenn die klobige, stählerne 5 im neuen HTML-Logo des W3C bei Ian Hickson die Gegenreaktion ausgelöst hat, das WHATWG-Entwicklerdokument zu HTML zur maßgeblichen Dokumentation zu HTML zu erklären, einem lebenden Dokument, das über allen festgeschriebenen HTML-Versionen steht. Entwickler von HTML5-Applikationen oder Autoren von HTML5-Handbüchern (da kann ich mitreden) schlagen ohnehin bevorzugt in dem „lebenden Dokument“ der WHATWG nach als in der ewigen Draft des W3C zu einem leuchtenden Irgendwann-Standard, der dann letztlich nur den HTML-Entwicklungsstand des Jahres 2009 widerspiegeln wird. Hickson bricht damit das Tabu, sich als ernsthafter, professioneller Webentwickler bewusst gegen den zeitraubenden, angestaubten und unfruchtbaren Standardisierungsprozess von W3C-Spezifikationen zu stellen. Ein Tabubruch, der möglicherweise Konsequenzen in der allgemeinen Wahrnehmung haben wird. Darin könnte das W3C mit seinem Standardisierungsprozess alsbald zu einem liebenswerten Wachsfigurenkabinett verkommen, während die Standardisierung des Webs an anderen Orten vorangetrieben wird, mit nicht-akademischen Mitteln.
In Twitter klingt das Ganze dann so:
Tweet von @tcaspers
Was mich denn auch zum Titel dieses Beitrags inspirierte.
Ja, so kann man das sehen. Was wir aber konkreter beobachten ist das allgemeine Unverstehen humaner Systeme. Diese müssen immer auch kompetitiv sein und die Interessenlagen der Systemteilnehmer berücksichtigen. Mit Formalismus, Bürokratie und allgemeiner Betonköpfigkeit kann man solche Systeme nicht lenken oder vielleicht besser: nicht prognostizieren
Etwas abstrakter ist das einer dieser großen Verständnisprobleme, die Etatisten (pol. Linke, Gefühlslinke, Linksspiesser und Spiesser allgemein) nicht verstehen, das Humankapital ist zum Wettbewerb verurteilt. Insofern sind auch aktuelle pol. Bemühungen (EU-Überschätzung, EURO-Fanatismus, UN-Gläubigkeit etc.) zum Scheitern verurteilt. Popper vs Hegel, Old Popper hatte hier auch Probleme…
"Liebenswert" kann man streichen.
MFG + Danke für die anderweitige Hilfe!
Sky
Posting-Vorschau:
Vorschau schließen