Das HTML5-Buch

Veröffentlicht am 27. Mai 2010

HTML5. Webseiten innovativ und zukunftssicher

Wie vermutlich den wenigsten unter euch verborgen geblieben ist, habe ich ein Buch über HTML5 geschrieben. HTML5 - Webseiten innovativ und zukunftssicher erscheint bei Open Source Press, hat fast genau 400 Seiten und ist für Leute gedacht, die bereits versierte (X)HTML-Autoren sind und die vorzugsweise auch schon mal die eine oder andere Zeile Javascript geschrieben haben. Grundlagen stehen nur insofern auf dem Programm, als dass ein bisschen die Regeln von HTML ohne X davor rekapituliert werden.

Inhalt

Das Buch richtet sich sowohl an klassische HTML-Autoren als auch alle JS-Nerds, die auf die neuen APIs scharf sind – von Use Cases für <b> bis zu „Hallo Welt“ mit WebGL ist alles dabei. Die Themen auf die im einzelnen eingegangen wird sind die Folgenden:

  • Semantisches HTML5
  • HTML5-Formulare
  • Offline-Webanwendungen
  • <audio> und <video>
  • Die Drag&Drop-API
  • Das Canvas-Element

Detailinfos nebst Kaufoptionen gibt es auf der Website zum Buch, beim Verlag und bei Amazon, das Inhaltsverzeichnis und eine Leseprobe gibt es als PDF zum Download. (Bei Amazon heißt es zur Zeit, das Buch sei noch nicht erschienen. Das ist falsch! Amazon spielt nur mal wieder Saftladen. Woanders wird bereits fleißig geliefert.)

Zu jedem Thema sind umfangreiche Tabellen und Referenzen sowie nützliche Codesnipsel enthalten (wie zum Beispiel dieses Script zum Auslesen von Custom Data in HTML5-Dokumenten). Es war mir auch sehr wichtig, die Hintergründe von HTML5 zu beleuchten, so dass es neben einem historischen HTML-Exkurs auch ein Extra-Kapitel nur für Kritik an HTML5 und Überlegungen zu Alternativen und der Zukunft des WWW gibt.

FAQ

HTML5 soll doch erst 2022 fertig sein! Jetzt schon ein Buch darüber?
Ich würde sogar die Prophezeiung wagen, dass HTML5 nie „fertig“ (im Sinne eines etablierten Webstandards wie HTML 4.01) sein wird. Also wann wenn nicht jetzt?
Die Hälfte von dem was da drinsteht ist doch gar kein HTML5!
Doch.
Warum beschreibst du nicht Technologie XYZ?
Keine Zeit. Das was heute noch fehlt kriegt dann eben in der zweiten Auflage sein eigenes Kapitel. WebWorkers und SVG sind fest für die Zukunft eingeplant.
Nichts davon geht im IE8!
Aber hallo, und wie das geht! In vielen Bereichen ist der IE8 sogar besser ausgerüstet als Safari oder Chrome.
Nichts davon geht im IE6!
Das ist so pauschal nicht ganz richtig. Man muss nur wissen wie. Und außerdem ist der IE6, wenn nicht schon tot, zumindest schwer komatös. Um den sollte man sich meines Erachtens nicht mehr scheren, wobei ich natürlich spaßeshalber trotzdem den einen oder anderen IE6-Hack im Buch beschreibe.
Viel zu viel zu lesen!
Nächsten Monat halte ich eine dreitägige HTML5-Schulung in München. Noch kann man sich anmelden!
Ich habe eine Frage zu HTML5 oder zum Buch!
Hier kannst du sie loswerden.

Was ist HTML5 und was nicht? Und was hätte der Kaiser dazu gesagt?

Veröffentlicht am 20. Mai 2010

Update: Eine verbesserte und ständig aktualisierte Version der Grafik in diesen Artikel ist unter github.com/SirPepe/SpecGraph zu finden.

In jüngster Zeit regen sich verstärkt Leute darüber auf, dass „HTML5“ immer mehr zu einer Art Marketingbegriff wird und nicht (mehr?) scharf zwischen HTML5 im Sinne der HTML5-Spezifikationen und HTML5 im Sinne von schau mal was dein Browser noch so alles kann unterschieden wird. So wird zum Beispiel die Geolocation-API gerne als HTML5 angepriesen, hat aber damit streng genommen nichts zu tun – sie ist Gegenstand einer völlig eigenen Spezifikation des W3C. Manche regt dieses falsche Label so sehr auf, dass sie ganze Websites erschaffen um ihrem Zorn Ausdruck zu verleihen (kreativerweise unter Zuhilfenahme der Geolocation-API selbst).

Statt zu zürnen halte ich es lieber mit Erklärungen und die folgende Grafik, die ich letzte Woche für andere Zwecke gebaut habe, sollte den Problemkomplex „HTML5“ hoffentlich einigermaßen verbraucherfreundlich illustrieren:

HTML5-Technologien

Download als Inkscape-SVG
Web-optimiertes SVG von Pawel. Danke!

Damit kann man vielleicht dem Einen oder Anderen HTML5-Falschbezeichner den wahren Weg weisen. Aber hilft das wirklich irgendwem bei irgend etwas? Beispielsweise ist es so, dass sich jene Features, mit denen man eine Website zur Offline-App verwandeln kann, auf HTML5 selbst (in Form des dort spezifizierten Application Cache) und diverse andere Standards (DOM Storage und WebSQL) verteilen. Da genau zwischen HTML5 und „HTML5“ zu trennen wäre sicher sachlich richtig, nur wer hat am Ende etwas davon? Wem das nützt da was?

Cover des Verdeutschungshefts

Und ohnehin ist fraglich, ob man die laufende Begriffs(um)bildung überhaupt stoppen kann. Ich als Hobbylinguist und Ex-Historiker habe da meine Zweifel. Einst grub mein Onkel Heinz auf seinem Dachboden ein „Verdeutschungsheft“ aus dem Jahre 1916 aus, in dem der Allgemeine Deutsche Sprachverein seinen Leser antrug, böse Gallizismen wie „Büro“ oder „Garage“ aus gegebenem Anlass doch bitte in ihrem Gebrauch einzuschränken. Was soll denn sonst der Kaiser denken! Wie wir heute wissen, hat das super funktioniert – trotz großer Verbreitung solcher Heftchen. Und wenn nicht mal der Allgemeine Deutsche Sprachverein verhindern kann, dass jeder sagt was er will, wie soll man das dann als HTML-Nerd hinkriegen?

Will man das überhaupt? Die Welt ist auch nicht untergegangen, als alles, was irgendwie blinkte, das Label „AJAX“ verliehen bekam. Wir werden es also überstehen, wenn auch Geolocation und WebWorkers in Zukunft umgangssprachlich als HTML5 bezeichnet werden.

Update: Besseres Bild mit mehr Klarheit und weniger Tippfehlern ist eingebaut.

Update 2: Bild nochmal nachgebessert. Jetzt dürften alle Unklarheiten beseitigt sein.

Update 3: Eine verbesserte und ständig aktualisierte Version der Grafik verschiedenen Formaten ist ab jetzt unter github.com/SirPepe/SpecGraph zu finden.

Programmieren für MODx Revolution

Veröffentlicht am 10. Mai 2010

Nachdem ich nun schon mehrere Projekte mit MODx Revolution, der zweiten Ausfertigung des besten CMS der Welt, bearbeiten durfte, dachte ich, es würde sich anbieten ein kleines Tutorial über Programmierung für MODx Revolution zu schreiben. Es gibt zwar eins in der offiziellen Dokumentation, aber das ist erstens Englisch und zweitens hat es sich als zumindest für mich nicht sehr hilfreich herausgestellt – warum auch immer. Jedenfalls habe ich mich anderweitig in die Materie eingegraben und dieser Artikel ist das erste Resultat meiner Forschungen. Im folgenden geht es erst mal nur um jene Dinge, die man für die vielen kleinen Snippets braucht, die für jede Seite anfallen. Etwas vertiefend-nerdigeres wird dann sicher irgendwann die Tage folgen.

OOP Ahoi

Der große Unterschied zwischen Programmierung für MODx Evolution und MODx Revolution ist, dass in Revolution alles Objektorientiert ist. Während es früher quasi nur ein Objekt, $modx, gab, das allerlei nützliche Methoden hatte, dient $modx in Revolution vor allem dazu, an andere Objekte heranzukommen. Diese haben dann ihrerseits Methoden. Angenommen wir wollten erfahren, welches das Elterndokument von Dokument Nummer 42 ist, würde man im alten MODx Evolution folgendes schreiben:

$doc = $modx->getDocument(42);
echo $doc['parent'];

In Revolution ist der Unterschied, dass man mit Hilfe der allmächtigen getObject()-Methode ein Dokument-Objekt vom Typ modResource aus der Datenbank holt und sich das Elterndokument über dessen get()-Methode holt.

$doc = $modx->getObject('modResource', 42);
echo $doc->get('parent');

Warum so und nicht anders? Nun, mit dem Wissen um diese beiden Zeilen ist man bereits völlig dafür gerüstet, beliebige Daten aus jedem beliebigen MODx-Objekten zu holen. Es ist völlig egal, ob man Informationen über Dokumente, Chunks, Snippets, User oder Zugriffsberechtigungen haben möchte – getObject(), get(), fertig.

// ID des Chunks "foo"
$chunk = $modx->getObject('modChunk', 'foo');
echo $chunk->get('id');

// Kategorie des Templates 1337
$template = $modx->getObject('modTemplate', 1337);
echo $template->get('category');

// Name des Users 42
$user = $modx->getObject('modUser', 42);
echo $user->get('username');

Die ganzen verschiedenen Methoden, die man sich früher für solcherlei Operationen merken musste, darf man also getrost vergessen.

Klassen und Methoden

Die komplette Liste der Objekte, die man sich mittels getObject() holen kann, findet man unter http://api.modxcms.com/. Die für den Hausgebrauch Interessanten Dinge sind unter modxClasses zu finden, wo auch die diversen Methoden der einzelnen Objekte dokumentiert sind – denn natürlich ist get() nicht alles. Jedes Objekt hat eigene, spezialisierte Methoden mit denen man praktische Dinge anstellen kann. Man möchte wissen, welchen Wert die Template Variable foo im Dokument 42 hat? Kein Problem:

$doc = $modx->getObject('modResource', 42);
echo $doc->getTVValue('foo');

Nützliches und Veraltetes aus $modx

Früher war $modx das Ein und Alles der MODx-Programmierung doch mittlerweile ist es fast nur noch für getObject() wichtig. Es enthält zwar noch allerlei Überbleibsel aus MODx 1.x – so sind etwa weiterhin $modx->documentObject und $modx->db an Bord – allerdings nur noch übergangweise. Spätestens zur Version 2.1 wird hier aufgeräumt und die Altlasten fliegen raus. Deshalb sollte man, wenn es etwas Neues gebaut wird, die Finger hiervon lassen und auch veraltete Snippets wie Ditto (wird u.A. durch getResources ersetzt) sind zwar noch da, aber bereits zum Entfernen vorgemerkt.

Das DocumentObject braucht eigentlich auch niemand mehr. Die ID des gerade aufgerufenen Dokuments findet man unter $modx->resourceIdentifier und unter $modx->resource findet man ein komplettes modResource-Objekt, das man wie bekannt mit get() und all seinen anderen Methoden bearbeiten kann. Wir halten also fest: Fast alles, was früher in irgendwelchen Arrays steckte, ist jetzt schön in Objekten sortiert. Wenn man das weiß, ist man schon ganz gut gerüstet.

Fazit

Wie also programmiert es sich so in MODx Revolution? Gar nicht so schlecht, man muss nur alles vergessen, was man in MODx 1.x gemacht hat (abzüglich der Basisprinzipien, also Chunks, Snippets etc) und in der API-Dokumentation etwas heimisch werden. Die dem Objektsystem zu verdankenden Vereinheitlichungen machen, so jedenfalls mein Eindruck, schon hin und wieder die Dinge einfacher – wenn man weiß, dass man an jedes beliebige Feld einfach mit $irgendwas->get('sonstwas') herankommt, kann man sein Hirnschmalz in die wirklich wichtigen Dinge investieren: Content und Design. Und so sollte es ja eigentlich in MODx immer sein.

Wo die Javascript-Performance wirklich versickert

Veröffentlicht am 22. April 2010

Wenn das Javascript lahmt, gibt es viele Ansätze um die Performance zu verbessern – smarte Schleifen, Scope-Optimierung, Closure-Diät und kürzere Ketten beim Objektzugriff (foo.bar ist flotter als foo.bar.blubb.blah). Dass all das zwar Geschwindigkeit bringt, jedoch in 99% aller Fälle nicht das Problem ist, an dem man arbeiten sollte, sollte eigentlich das in aller Länge un Breite ausformulierte Thema dieses Beitrags werden, doch dann flatterte dieses schöne Video vorbei. Hier referieren Nicholas Zakas, Stoyan Stefanov, Ross Harmes, Julien Lecomte und Matt Sweeney über das, was sie in diesem schönen Buch geschrieben haben – High Performance Javascript eben.

In dem Video werden viele Wege der JS-Optimierung beschrieben, aber die besten Zahlen führt eindeutig Stoyan Stefanov in seinem Vortag über das DOM zu Felde: bei unbedachter Arbeit am DOM-Tree hat man selbst im besten Browser Glück, wenn man sein Script nur 20× so langsam macht, wie es sein könnte. Das heißt: sofern man Javascript im Browser verwendet und damit Animationen und ähnliches umsetzt (was wohl so um die 99% aller Anwendungsfälle ausmacht), ist der Flaschenhals, um den man sich vorrangig kümmern sollte, das DOM.

Der geschwindigkeitsbringende Umgang mit dem DOM ist dabei ganz einfach, sofern man zwei Regeln befolgt:

  1. So wenige DOM-Operationen jedweder Art durchführen wie möglich
  2. Fleißig documentFragment verwenden (Details)

Stefanov hat noch 8 weitere Regeln im Angebot (siehe Buch und Video) doch allein mit diesen beiden kann man die meisten Scripts schon erheblich beschleunigen. Wenn man also auf der Fahndung nach Javascript-Performance ist, sollte man im DOM anfangen zu suchen. Für Otto Normalwebworker, der nur hin und wieder ein paar Animationen und Ajax-Requests zu basteln hat, sind all die anderen Optimierungen zwar auch interessant (deshalb Video schauen und Buch lesen!), aber wenn das Script lahmt, liegt das Problem doch oftmals woanders.

Ebenfalls zum Thema und überaus ansehenswert, falls noch unbekannt: Speed Up Your JavaScript, ebenfalls von und mit Nicholas Zakas.