Fun Facts zu Doctypes

Veröffentlicht am 17. August 2010

Bis letzte Woche konnte ich nur erahnen, wie es ist, Wissenschafts- oder Politblogger zu sein. Diese bedauernswerten Zeitgenossen werden ja auf Schritt und Tritt von abstrusen Gestalten mit originellen Theorien über das Wesen der Welt verfolgt – Esotriker, Kryptofaschisten, Astrologen, 9/11-Besserwisser. Dann aber kam ein HTML5-Verschwörungstheoretiker auf mich zu, der behauptete beweisen zu können, dass der HTML5-Doctype <!DOCTYPE html>) mindestens so schlimm ist wie Handystrahlen und die jüdische Weltverschwörung, denn der HTML5-Doctype löse ja den Quirks Mode aus! Und wenn so ein dahergelaufener Eumel wie John Resig das Gegenteil behauptet, liegt er eben falsch.

Das Problem ist, dass unser HTML5-Verschwörungstheoretiker nicht nur unrecht hat, sondern in etwa so weit daneben liegt, wie ein 9/11-Thruther, der behauptet, die US-Regierung habe am 11. September 2001 nicht das World Trade Center, sondern den Eiffelturm gesprengt. Denn tatsächlich sind Browsern Art und Inhalt eines Doctypes komplett egal. Sofern am Start einer HTML-Seite irgend etwas steht, das grob nach Doctype aussieht, wird jeder Browser die Seite im Standards Mode rendern. Das Folgende ist formal ungültiger, aber wunderbar funktionierender Doctype (hier in Aktion):

<!DOCTYPE html public "Browsern ist völlig egal was im Doctype steht."
	"Solange da irgendwas steht, was grob nach Doctype-Syntax aussieht, wird Standards Mode verwendet.">

Warum aber ist dem Browser der Doctype so egal? Sehen wir uns einmal einen richtigen Doctype an:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Dieser Doctype besteht aus dem Syntax-Pflichtprogramm (<!DOCTYPE html ...), der Deklaration der hier verwendeten HTML-Variante (XHTML 1.0 Transitional) und einer URL. Diese URL enthält alle Informationen, die der Browser zum Verarbeiten der genannten HTML-Variante braucht. Theoretisch wäre das sehr wichtig, denn threoretisch ist HTML eine SGML-Anwendung. SGML ist so etwas wie der Urahn von XML und HTML stünde demnach in einer solchen Beziehung zu SGML, wie XHTML in Beziehung zu XML steht – das Letztere dient jeweils dazu, Ersteres umzusetzen. In der Theorie müsste man dem Browser als wirklich mitteilen, wo genau er nachlesen kann, wie er die Tags in einer HTML-Seite mit seinem SGML-Parser zu verarbeiten hat. Dieser Informationen findet der Browser unter der im Doctype angegeben URL; die .dtd-Datei enthält eine Liste aller HTML-Tags für den jeweiligen Doctype.

Die Praxis sieht allerdings anders aus. Kein Browser hat je so gearbeitet. Kein Browser hatte je einen SGML-Parser. Kein Browser hat je Doctypes verarbeitet und die .dtd-Dateien heruntergeladen. Es herrschte schließlich in der Anfangszeit des Webs Browserkrieg und man hatte dringenderes zu tun, als korrekte Parser zu implementieren –mit Standards nahm man es schon damals nicht so genau. So entwickelte sich HTML statt zu einer SGML-Anwendung zu einer ganz eigenen Auszeichnungssprache, die eigentlich gar keine Informationen aus Doctypes mehr brauchte. Alle Regeln zu HTML waren und sind auch noch heute fest in die Browser eingebaut.

Und so kommt es, dass Browsern die Inhalte von Doctypes völlig egal sind – Hauptsache es ist überhaupt einer vorhanden. Und folgerichtig funktioniert natürlich der HTML5-Doctype genau so gut wie alle anderen.

MODx Revolution: Mehrere FormIt-Instanzen auf einer Seite

Veröffentlicht am 12. August 2010

Formulare erstellt man in MODx Revolution (bekanntermaßen das beste CMS der Welt) mit einem neuen Snippet namens FormIt. FormIt ist der Revo-Nachfolger von eForms und ein gutes Stück weniger krampfig als eForms, hat es doch den Vorteil, Formulare und ihr Zubehör in wesentlich weniger großem Umfang über unzählige Chunks zu verteilen. Der größte Haken an FormIt ist meiner Meinung nach die noch etwas löchrige Dokumentation, die sich zum Beispiel darüber ausschweigt, wie man mehr als eine FormIt-Instanz auf einer Seite unterbringt, ohne dass sich diese in die Quere kommen.

Früher bei eForms behob man dieses Problem, indem man dem Snippet via Parameter jene Formular-ID mitteilte, um die das Snippet sich zu kümmern hatte. Ganz ähnlich geht es auch bei FormIt, nur auf etwas „formularigere“ Art und Weise: man teilt dem Snippet im Parameter submitVar den Namen eines Formularfelds mit, das als Identifikator fungiert – wohl in aller Regel ein Input vom Typ hidden, das speziell für diesen Zweck eingebaut wurde. Das könnte in Aktion dann so aussehen:



<form action="weblog/" method="post">
<input type="hidden" name="meinformular" value="1">

...

</form>

Da in diesem Fall $_POST["meinformular"] nur 1 ist, wenn auch wirklich das fragliche Formular abgesendet wurde, weiß die fragliche FormIt-Instanz wann sie in Aktion zu treten hat und wann sie Post-Daten ignorieren kann – denn die Formulare anderer FormIt-Instanzen übertragen eben keine meinformular-Variable.

Die Existanz von submitVar habe ich das über den Bugtracker des Projekts bei Github in Erfahrung bringen können – denn dokumentiert ist das Ganze wie gesagt nicht, Google liefert nichts Verwertbares und den Code von auch nur ein klein wenig komplexeren Revolution-Komponenten kann man ebenfalls nicht immer locker durchblicken. Schon doof dass es solche Doku-Löcher gibt, denn was nützt einem beste CMS der Welt, wenn man nicht auch mühelos nachlesen kann, wie es zum funktionieren zu bewegen ist?

Das HTML5-Buch als E-Book

Veröffentlicht am 11. August 2010

Das HTML5-E-Book

Mein HTML5-Buch ist seit heute endlich auch als E-Book zu haben! Steter Tropfen höhlt den Stein – nachdem die Anfragen nach einer papierfreien Version einfach nicht nachgelassen haben, kann man das gute Stück nun also auch digital erstehen. Der Inhalt ist mit dem der Totholz-Fassung identisch: alle wichtigen Bereiche von HTML5 werden anhand von anschaulichen Beispielen besprochen, von den neuen semantischen Elementen über <audio>, <video> und <canvas> bis hin zu Geolocation- und Drag&Drop-APIs. Hinzu kommen die Hintergründe der Entstehung von HTML5, zahlreiche Hacks und Tricks sowie ein umfangreicher Anhang mit vielen Tabellen und Referenzen zum Nachschlagen. Lesermeinungen gibt es bei Amazon und Gerrit.

Warum <frameset> und <marquee> in den HTML5-Spezifikationen stehen

Veröffentlicht am 10. August 2010

Ich küre morgens via Twitter gerne mal eine Seite des Tages. Meist handelt es sich dabei um lustige oder fossile Relikte aus grauer Web-Vorzeit und als ich heute morgen die zweite von den beiden genannten zwitscherte, dachte ich, es wäre doch mal interessant zu beleuchten, warum so Dinge wie <frameset> und <marquee> in den HTML5-Spezifikationen stehen und dort haarklein definiert wird, wie sie zu funktionieren haben.

HTML5 ist zwar die nächste Version von HTML, aber man ist sich darüber im Klaren, dass sich fast 10 Jahre HTML-Geschichte nicht einfach so in Rauch auflösen werden, also veraltete Elemente, Attribute und Technologien nicht einfach aus den Websites dieser Welt verschwinden, bloß weil sie sie jetzt überholt sind. Normalerweise wäre das völlig egal – man würde einfach eine neue Spezifikation unter Ausklammerung der veralteten Elemente schreiben, maximal in einem Nebensatz erwähnen, dass es sie mal gab. So heißt es beispielsweise in den XHTML 1-Spezifikationen zu <isindex> lediglich:

The isindex element is deprecated in favor of the input element.

Im Gegensatz dazu spezifiziert HTML5 sogar das Marquee-Element mit allen Details, inklusive aller HTML-Attribute und einer JavaScript-API. Auch Frames und historische HTML-Attribute wie align und cellpadding erhalten diese Behandlung. Warum ist das so?

Bisherige HTML-Spezifikationen waren für HTML-Autoren geschrieben. Es stand jeweils drin, zu was die einzelnen Elemente und Attribute gut waren und wie man sie benutzt. Die HTML5-Spezifikationen hingegen richten sich auch an jene, die HTML-Implementierungen programmieren, also die Bowserhersteller. Und da ist es natürlich im Sinne eines einheitlichen (eben standardisierten) Verhaltens sinnvoll, auch festzulegen, wie sich jene Dinge verhalten sollen, die nicht Teil des Standards sind. Und genau das macht HTML5 mit den detaillierten Spezifikationen zu <frameset>, <marquee> und anderen Relikten.

Der Abschnitt mit all den Details und APIs zu den ganzen Fossilien ist außer zur Erheiterung (eine erst gemeinte JavaScript-API für das Marquee-Element?) für HTML5-Autoren nicht weiter wichtig und richtet sich nur an Browser-Programmierer. Alles was der Webworker zum Thema „abgeschaffte Elemente und Attribute“ wissen muss, steht im Abschnitt über Non-conforming features – eine einfache Liste mit allem, was man in HTML5 nicht mehr verwenden sollte.