Ein halbes Jahr ist nun seit dem Hochladen des ersten Workshop-Videos vergangen, aber nun ist er mit einer Gesamtlänge von sechs Stunden, fünf Minuten und vierzig Sekunden endlich fertig! Die Playlist ist wie gehabt unter “HTML5 Workshop” vollständig ansehbar.

Im letzten Video des Workshops (siehe oben) geht es darum, welche Techniken nützlich sind, wenn man eine HTML5-Webseite für die Veröffentlichung im Web vorbereitet. Ein vollständiges Transkript des Videos gibt es hier:

Startet wieder NetBeans.

Die Workshop-Seite ist nun fertig, wurde auch Zeit, der Workshop ging nun fünf einhalb Stunden! 5 Stunden, 30 Minuten und 48 Sekunden, um genau zu sein! Ihr fragt euch nun vielleicht, was dann überhaupt hier noch in diesem Video passieren soll!

Ich möchte euch in diesem Video ein paar Techniken und Hilfestellungen zeigen, die wichtig sind, wenn ihr eine “echte” HTML5-Seite macht. Denn das, was wir jetzt gemacht haben, war ja nur eine Tutorial-Seite. Hier ging es im Grunde nur um die neuen Webstandards, teilweise ein wenig exzessiv eingesetzt, um möglichst viel hier im Workshop unterzubringen. Am Anfang habe ich ja auch gesagt, dass wir für WebKit entwickeln, oder noch besser gesagt, für Safari, da Chrome ja nicht die 3D-Transformationen unterstützt. So etwas kann man natürlich nicht in Wirklichkeit machen, da muss man alle Browser bedienen, selbst die alten Versionen des Internet Explorers. Und die sind wie immer das größte Problem.
Der Firefox 3.6 mach zwar auch ein paar Probleme, (…) aber die sind in Firefox 4 behoben (…) und ich denke, dass der Firefox 3.6, jetzt wo der 4er rauskommt, auch wieder aussterben wird, so wie auch jetzt der Firefox 3.5 fast ausgestorben ist.
Chrome macht insofern Probleme, als dass er die CSS 3D-Transformationen nicht richtig darstellen kann, dafür kann er aber vieles andere. Wenn man bspw. 3D haben will, könnte man WebGL verwenden. Das ist der 3D-Rendering Context des Canvas-Elements. Der 2D-Canvas wurde ja schon gehyped, mit WebGL kommt jetzt der 3D-Canvas, da wird sich die Hype-Maschine wohl überschlagen.
Und Opera hat auch einige Probleme. Beispielsweise kommen erst jetzt CSS Farbverläufe zu Opera.

Und genau darum soll es jetzt hier gehen: Browser, die nicht alles unterstützen, was HTML5 bietet, gibt es momentan und auch die nächsten Jahre noch. Und wenn man eine HTML5-Seite erstellen möchte, muss man lernen, mit diesen Browsern umzugehen. Besondere Probleme bereiten, wie bereits gesagt, die alten Versionen des Internet Explorers, weil die aus einer Zeit kommen, wo HTML5 noch nicht mal in Planung war, aber heutzutage noch immer genutzt werden, ganz abgesehen von den üblichen IE-Bugs, die nicht mal was mit HTML5 zu tun haben. Und selbst der neue IE hinkt den alternativen Browsern hinterher, was die HTML5-Unterstützung angeht, aber er stellt bei weitem nicht mehr ein dermaßen großes Problem dar wie die alten. (…)

Deswegen ist das erste, was ich euch vorstelle, HTML5 Shim: Das ist ein kurzes JavaScript, das die neuen HTML5-Elemente beim IE “anmeldet”. Denn der IE kennt ja noch gar nicht die Elemente wie section, nav, usw. und weiß nicht wie es mit denen umgehen soll. HTML5 Shim ruft für all diese Elemente ein document.createElement auf und registriert sie dadurch im Browser. Nur dadurch können die neuen Elemente überhaupt gestylt werden, deswegen muss das auch oberhalb des Stylesheets im Quelltext eingefügt werden.
Geht auf code.google.com/p/html5shim oder googled einfach nach html5shim, kopiert die drei Zeilen, die dort stehen, geht in index.html und fügt sie unter der title-Angabe ein.
Sehr verwirrend ist übrigens, dass es html5shim und html5shiv gibt. Beides ist von Remy Sharp. HTML5shiv ist das ältere der beiden. Und falls ihr euch fragt, was denn wohl der Unterschied zwischen den beiden ist: Es gibt keinen. Der Code ist exakt identisch! In den Changelogs von html5shim steht: “Mirror of the shiv – lord only knows what it was called a shiv…” Das bedeutet, es ging hier nur um den Namen. Aber als html5shim erstellt wurde, war html5shiv bereits verbreitet, deswegen wird nun immer beides geupdated, wenn es Updates gibt.
Dieses Skript sollte in keiner HTML5-Seite fehlen.

Selbst Microsoft findet seinen alten IE inzwischen schlecht und hat die IE6 Countdown Kampagne gestartet, um den IE6 sterben zu lassen, also seinen Marktanteil im Web auf unter einen Prozent zu drücken. Und das begrüße ich sehr herzlich, denn sie haben sogar etwas vorgefertigt, was ich damals in meinem Fazit-Video als Lösungsvorschlag für den IE6 angeboten habe: “…dass man einfach eine Leiste einblendet, in der steht ‘The browser you’re using is 10 years old.’ (…) Dass man den Benutzer darauf hinweist, ‘Heey, könntest du nicht deinen Browser wechseln?!’” Und genau solch eine Leiste hat Microsoft erstellt, und bittet Webseitenbetreiber, diese Leiste einzubinden!
Dieser Bitte komme ich natürlich nach und binde das Bild mit dem zugegeben hässlichen Farbverlauf gerne in die Seite ein! Unter “Join the cause” findet ihr den Code. Kopiert den und fügt ihn über dem header im body ein. Wenn ihr einen IE6 oder kleiner habt und die Seite öffnet, müsste dort nun oben diese Leiste sein.
Es ist zwar nicht nötig, diese Leiste einzubinden, wenn ihr eine HTML5-Seite erstellt, aber jedes Vorhaben, alte IEs aus dem Web zu drängen, sollte man unterstützen.

Eine der praktischsten Möglichkeiten, mit alten IEs fertig zu werden, ist der Google Chrome Frame. Das ist ein Plug-In für die alten Internet Explorer, durch das Google Chromes Engines im IE laufen. Um das zu nutzen, geht in index.html und fügt ganz oben in den head der Seite ein: <meta http-equiv="X-UA-Compatible" content="IE=Edge;chrome=1" >
Bei IE-Nutzern, die den Chrome Frame installiert haben, wird durch diese eine Zeile der Chrome Frame aktiv, und schon wird alles von Chrome gerendert, mitsamt Chromes schneller JavaScript-Engine. Das ist zwar, wenn man sich’s recht überlegt, ziemlich umständlich, denn statt dieses Plugin zu installieren, hätte der Nutzer auch gleich auf Google Chrome umsteigen können, aber für Webdeveloper ist es praktisch. Allerdings habe ich leider keine Angaben darüber, wie verbreitet der Chrome Frame überhaupt ist, also wie viele IE-Nutzer dieses Plugin überhaupt installiert haben. Ich vermute, dass es nur wenige IE-Nutzer sind.

Wir haben nun mit HTML5 Shim die neuen Elemente beim IE angemeldet, den Nutzer darauf hingewiesen, nicht mehr länger einen alten IE zu verwenden, und nutzen Chromes webstandard-konforme Engines, falls die dank Chrome Frame verfügbar sind.
Doch das reicht noch lange nicht aus. Was ist mit HTML5 Video? Was mit dem Canvas-Element? Was mit Geolocation? Wir nutzen immer document.querySelector, um auf Elemente zuzugreifen. Aber was machen wir, wenn die Selectors API gar nicht im Browser implementiert ist?! Was wenn der Browser keinen LocalStorage hat?

Zuerst einmal sollte man Ruhe bewahren, denn HTML5 wurde bewusst so entwickelt, dass es in alten Browsern auch funktioniert. Beim Canvas-Element haben wir ein Bild, das angezeigt wird, wenn der Browser das canvas-Element nicht unterstützt. Beim Video-Element wird gesagt, “Your browser does not support HTML5-video”. Weder die Seite noch der Browser gehen kaputt, wenn die neuen Elemente unbekannt sind. Das war eines der Grundsätze von HTML5 und auch einer der Gründe, warum HTML5 als Konkurrenz zu XHTML2 entwickelt wurde, denn XHTML2 hätte massenhaft Fehlermeldungen produziert und sämtliche Seiten kaputt gemacht.
Das heißt, große Sorgen müssen wir uns nicht machen.

Trotzdem wollen wir natürlich, dass alles funktioniert. Und dafür gibt es die sogenannten Polyfills. Als Remy Sharp zusammen mit Bruce Lawson “Introducing HTML5″ geschrieben hat, hat er in den Recherche-Arbeiten ein Wort gesucht für Techniken, die im Browser fehlende APIs per Skript oder Plugin bereitstellen, und kam auf das Wort Polyfill. Polyfilla ist zu Deutsch Spachtelmasse. Wenn man sich die alten Browser als Wand mit Rissen vorstellt, füllt diese Spachtelmasse die Risse im Browser und schafft eine glatte Wand, mit der man arbeiten kann.
Eigentlich hatte er gar nicht vor, das Wort als Bezeichnung dafür zu verbreiten, aber es hat sich doch irgendwie sehr schnell eingebürgert. Wenn ihr auf das Wort Polyfill oder Polyfiller im Zusammenhang mit HTML5 stoßt, dann ist damit eine Technik gemeint, die eine API zur Verfügung stellt, die der Browser eigentlich nativ unterstützen sollte.

Einige Polyfills liegen bereits im js-files Ordner der Ressourcen, die ihr anfangs heruntergeladen habt. Darunter auch Sizzle. Sizzle ist die CSS Selector Engine, die jQuery intern nutzt. Und die nehmen wir jetzt als Polyfill für die Selectors API.
Schreibt unten auf index.html über dem eingefügten Skript: <script type="text/javascript" src="js-files/sizzle.js"></script>
Geht in script.js und schreibt ganz oben hin:

document.querySelectorAll = document.querySelectorAll || function(query) {return new Sizzle(query);};
document.querySelector = document.querySelector || function(query) {return document.querySelector(query)[0];};

Übrigens: Man sollte den querySelector eigentlich nicht derart oft anwenden, wie wir es gemacht haben: Bei IDs ist getElementByID sehr viel schneller. Wenn ihr also Performance-Optimierungen durchführen wollt, solltet ihr weiterhin mit getElementById arbeiten.

Als nächstes möchte ich Unterstützung für die Canvas-API implementieren. Dank der Abfrage if (canvas.getContext) haben wir auch dort schon mal sichergestellt, dass dort keine Fehler geworfen werden. Aber es gibt auch eine Möglichkeit, die Canvas-API in den Internet Explorer zu bringen und die heißt ExplorerCanvas und liegt ebenfalls bei den js-files.
Da der IE9 die Canvas API unterstützt, müssen wir das nur für die älteren IE-Versionen hinzufügen, deswegen gehen wir in index.html, in die conditional comments, die wir dank des HTML5 Shims dort bereits haben, und fügen dort hinzu:
<script type="text/javascript" src="js-files/explorercanvas.js"></script>
Und das müsste es gewesen sein.

Auch bei Geolocation haben wir mit if (navigator.geolocation) abgefragt, ob Geolocation überhaupt verfügbar ist, das heißt auch hier spielt kein Browser verrückt, wenn wir Geolocation verwenden.
Aber auch für Geolocation gibt es verschiedene Polyfills. Wenn ein Google Gears-Plugin verfügbar ist, kann über Gears die Position ausgelesen werden. Manche BlackBerrys, Nokias, Palms, und andere Handys haben auch eine Geolocation API, allerdings ist das weder entsprechend der W3C Spezifikation noch ist das Google Gears.
Deshalb gibt es das Geolocation-Javascript, das all die verschiedenen Möglichkeiten, auf den Ort des Nutzers zuzugreifen, zusammenfasst.
Wir schreiben über der Einbindung von Sizzle:
<script type="text/javascript" src="gears_init.js">

Allerdings müssen wir dafür unseren Code ein bisschen verändern: Geht in script.js
Geht zum Maps-Abschnitt und tauscht if (navigator.geolocation) zu if (geo_position_js.init()) und navigator.geolocation.getCurrentPosition gegen geo_position_js.getCurrentPosition.

Außerdem, jetzt wo wir gerade hier im Skript sind, scrollt mal runter zum 3D-Haus und ändert dort die each-Funktion: Wir greifen per item auf ein Element zu, aber falls jetzt Sizzle verwendet wird statt der nativen Implementierung, ist der Rückgabewert ein Array und keine NodeList, deswegen steht uns diese item-Methode nicht mehr zur Verfügung. Was uns aber sowohl bei Array als auch NodeList zur Verfügung steht ist in eckigen Klammern [i].

Und wo wir gerade beim 3D-Haus sind. Das soll ja nur angezeigt werden, wenn der Browser überhaupt CSS 3D-Transformationen unterstützt. Wie finden wir das denn nun raus?
Es gibt Wege, die Unterstützung einzelner CSS3- und HTML5-Features heraus zu finden, aber statt euch die zu zeigen, stelle ich euch einen besseren Weg vor: Modernizr. Modernizr ist eine JavaScript-Bibliothek, die für fast alle Neuheiten aus CSS3 und HTML5 eine Abfrage zur Verfügung stellt, um herauszufinden, ob der Browser sie unterstützt oder nicht.
Diese Bibliothek ist super! Ihr müsst die sowas von einbauen, wenn ihr eine HTML5-Seite schreibt, weil sie alle möglichen Tests bietet. Und nehmen wir mal das Beispiel 3D-Transformationen: Das wird bei Modernizr getestet, indem abgefragt wird, ob ein Element die CSS-Eigenschaft perspective kennt, die ja für 3D-Transformationen wichtig ist. Chrome jedoch würde da sagen, dass es die Eigenschaft kennt, das heißt da könnte man annehmen, dass Chrome 3D-Transformationen unterstützt, aber das ist ja (zumindest bisher) noch nicht der Fall! Deswegen testen die dort mit media queries irgendwie weiter, bis sie herausfinden, ob der Browser die Eigenschaft wirklich unterstützt. Und deswegen: Solche Tests selbst zu schreiben, ist schrecklich aufwendig, also nutzt Modernizr! Ihr könnt euch die Bibliothek sogar individuell zusammenstellen lassen, wenn ihr (…) auf “create a custom modernizr build” geht. Dann habt ihr wirklich nur Tests für die Dinge, die ihr auch tatsächlich einsetzt, und reduziert somit den Code, dadurch die Größe der Datei und dadurch die Download- und Verarbeitungszeit.

Wir nehmen hier: CSS-Animations und CSS 3D Transforms. Den Rest brauchen wir nicht.
Und hier (…) seht ihr: Dort wird HTML5 Shim bereits automatisch integriert. YepNope JS brauchen wir nicht, da nehme ich den Haken raus. Das ist eine Bibliothek für asynchrones Laden von Ressourcen. Das ist sehr nützlich: Man kann bspw. auf ein Feature testen, und falls es nicht vorhanden ist, ein Polyfill dafür nachladen, damit es vorhanden ist, und anschließend den eigentlichen Code ausführen lassen. Wenn das eine echte Seite wäre, sollte man so etwas auch verwenden. Hier benutze ich es aber nicht.
Klickt auf Generate It! und [dann] auf Download Build.

Speichert das bei den js-files. Dort ist bereits eine Modernizr-Version vorhanden, die ich damals dem Ressourcen-Paket hinzugefügt hatte. Allerdings ist die nicht auf die nötigen Tests beschränkt und sie enthält nicht HTML5 Shim, ihr könnt die überschreiben.
In unserer Version ist nun HTML5 Shim enthalten, also können wir hier oben in index.html das HTML5 Shim wieder herausnehmen, sodass dort nur noch der Explorer Canvas ist. Stattdessen fügen wir hier unten nun Modernizr hinzu:
<script type="text/javascript" src="js-files/modernizr.js"></script>

Und nun können wir wieder in script.js gehen und um den ganzen Code des 3D-Hauses eine if-Bedingung schreiben: if (Modernizr.cssanimations && Modernizr.csstransforms3d) { ... }

Modernizr ist unter anderem von Paul Irish kreiert worden und der hat auch zwei weitere tolle Sachen kreiert, die ich nun hier vorstelle: Zum einen eine Liste auf GitHub “HTML5 Cross Browser Polyfills” mit einer Übersicht über alle möglichen Polyfills für alle möglichen HTML5 und CSS3 Features. Auch das ist super, weil solche Übersichten immer super sind. Hier findet ihr auch Polyfills für LocalStorage (Den Storage Polyfill von Remy Sharp kann ich da empfehlen) und für HTML5 Video.
Ihr wisst jetzt, wie man die Polyfills integriert, deswegen werde ich nicht für diese beiden Polyfills zeigen, wie man sie einfügt. Es geht ja im Grunde nur darum, die JavaScript-Datei der Seite hinzufügen.
Aber falls es eine Dokumentation zu den Skripten gibt, solltet ihr euch auch die immer noch ansehen.

Die dritte tolle Sache von Paul Irish ist etwas, das ich zukünftig vermutlich als Ausgangspunkt für jede Webseite nehmen werde, die ich von nun an erstelle: Die HTML5 Boilerplate! Das ist ein HTML-, CSS- und JavaScript-Template, bei dem alle möglichen Tricks bereits enthalten sind. Ein Beispiel: Der meta-Tag “charset” ist in HTML5 ja verkürzt worden, hatte ich ja im Video HTML-Gerüst (1/2) bereits gezeigt. Die Spezifikation hatte einfach aufgegriffen, was die Browser ohnehin schon gemacht haben, nämlich nur auf die Angabe des charsets zu gucken und den Rest zu ignorieren. Und das funktioniert auch in allen Browsern. Jedoch gibt es eine seltsame Voraussetzung beim charset: Es muss in den ersten 512 Bytes stehen. Das liegt daran, dass der Internet Explorer anfängt, die Zeichenkodierung der Seite zu erraten, wenn er sie nicht mitgeteilt bekommt. Und das kann dazu führen, dass Nutzereingaben, hier als Beispiel: +ADw− und so weiter, vom IE zum Anlass genommen werden, anzunehmen, es handle sich um UTF-7, und die Eingabe als HTML und JavaScript interpretiert wird und ausgeführt wird. Somit ist das eine Sicherheitslücke im Internet Explorer. Und die kann man nur umgehen, wenn man die Kodierung dem IE entweder bereits vom Server aus mitteilt, im HTTP-Response-Header, oder den meta-Tag charset innerhalb der ersten 512 Bytes angibt, noch vor dem title-Tag.
Dieser seltsame Bug wurde in der HTML5 Boilerplate berücksichtigt neben vielen, vielen, vielen anderen solcher Sachen. Ihr könnt euch einen Vortrag von Paul Irish über die HTML5 Boilerplate auf YouTube ansehen und ihr werdet feststellen, dass das von vorn bis hinten durchdacht ist. Sämtliche best practices sind in die Boilerplate gesteckt worden, deswegen ist die auch schon weit verbreitet. Es gibt WordPress- und Drupal-Themes, die darauf aufbauen, Mashable, Golem, t3n, ibm… haben alle schon über die Boilerplate berichtet, Unilevers Seite basiert auf der Boilerplate, NikeSkateboard basiert darauf, genauso wie eine Seite der amerikanischen Regierung, das belgische Nokia basiert darauf und noch viele, viele weitere Seiten.
Eine Besonderheit ist, dass die Farbe für Markierungen durch die HTML5 Boilerplate definiert wird, und auf ein Pink voreingestellt ist, was man natürlich ändern kann, manche aber so lassen. Daran kann man oftmals erkennen, dass eine Seite die HTML5 Boilerplate einsetzt, ansonsten gibt es eine Liste unter bit.ly/boilerplatesites. Dafür, dass die HTML5 Boilerplate erst im Herbst 2010 herausgekommen ist, ist die Liste schon ziemlich lang!
Die HTML5 Boilerplate hat bereits Modernizr integriert und enthält somit auch HTML5 Shim. Dazu noch jQuery.
Lest den Get Started-Artikel in der Boilerplate Wiki auf GitHub, wenn ihr die Boilerplate einsetzen wollt.

Und dann gibt es natürlich abgesehen von Polyfills etliche Techniken, Bibliotheken, Anwendungen, etc. die die Arbeit mit den neuen Features in CSS3 und HTML5 erleichtern. Eine möchte ich euch vorstellen, das sind die Google Web Fonts, erreichbar unter Google.com/webfonts
Und zwar haben wir ja, als wir die Schriftarten über die @font-face-Regel eingebunden haben, uns abgemüht, haben zig Schriftarten für die verschiedenen Browser erstellt und eingebunden, haben darauf geachtet, dass die auch für die Einbindung in Webseiten lizensiert sind, haben diese komische Bullet-proof @font-face-Syntax mit dem Smiley erstellt (übrigens ist die schon wieder veraltet, die funktioniert nämlich nicht im Android, stattdessen gibt es eine neue Bulletproof @font-face-Syntax, die ich dem Web Fonts-Artikel auf css3-html5.de hinzugefügt habe, und die viel eleganter ist als die Smiley-Variante). Aber all das kann man sich sparen, wenn man die Google Font API nutzt:
Geht in style.css und löscht die @font-face-Regeln. Geht nun in index.html und schreibt recht weit oben hin: <link href='http://fonts.googleapis.com/css?family=Molengo|Droid+Serif' rel='stylesheet' type='text/css'>
Was wir damit machen, ist, unsere Probleme zu Google auszulagern. Wir binden nämlich hier ein Stylesheet ein, das Google generiert, und in dem einfach bloß die @font-face-Regel steht.
Was haben wir davon für Vorteile? Zuerst mal bietet Google nur Schriftarten an, die für die Verwendung im Web lizensiert sind. Man kann sich also nicht in irgendwelche Urheberrechts-Probleme verfangen und wenn doch, ist Google der Anbieter und müsste dafür haften, denke ich. Außerdem wird das Stylesheet dem Browser angepasst: Ruft der Internet Explorer das Stylesheet auf, bekommt er etwas anderes zurück, als wenn der Firefox das Stylesheet aufruft. Dadurch weicht man den Internet Explorer-Problemen aus, muss sich nicht mehr irgendwelche abgefahrenen Bullet-Proof @font-face Syntaxen ausdenken und nicht mehr tausend verschiedene Schriftartdateien generieren, denn all das macht Google. Darüber schont man den eigenen Server, weil die Dateien von Google kommen. Allerdings binden wir ein Video in die Seite ein, da spielt eine kleine Schriftdatei auch keine Rolle mehr.

Solche Auslagerungsmöglichkeiten gibt es viele. Und man sollte sie nutzen. Selbst wenn es gar nicht um Lizenzierung oder Vereinfachung geht. Zum Beispiel wenn es nur darum geht, jQuery einzubinden, oder wie wir es vorhin gemacht haben, HTML5 Shim einzubinden. Selbst bei diesen Sachen ist es von Vorteil das über die Server von Google oder Yahoo oder Amazon oder dergleichen zu machen, weil das CDNs sind, Content Distribution Networks, wo solch häufig abgefragte Dateien wie jQuery gecached werden und für tausendfache Auslieferung optimiert werden. Es ist tatsächlich schneller auf solche CDNs zurückzugreifen. Deswegen bindet selbst jQuery.com jQuery über google ein.

Und schließlich, und dann ist der Workshop auch wirklich vorbei, möchte ich euch ein Tool vorstellen, dass ihr am Schluss einer Webseitenentwicklung mit JavaScript immer nutzen solltet: Einen JavaScript-to-JavaScript-Compiler. Das ist ein Werkzeug, mit dem ihr euer JavaScript in weniger JavaScript umwandeln könnt, das unter Umständen sogar schneller läuft, ohne dass die Funktionalität verändert wird. Es gibt inzwischen verschiedene Compiler: UglifyJS, YUI compressor, den Google Closure Compiler und vermutlich weitere, die ich bisher nicht kenne. Ich nehme den Closure Compiler unter closure-compiler.appspot.com und zeige euch aber nur kurz, was der überhaupt macht.
Wenn ihr das tatsächlich nutzen wollt, solltet ihr euch nähergehend damit auseinander setzen. Denn eine der eigentlich wirklich guten Vorteile ist, dass man dort all seine Skripts reingeben kann und er die alle in ein einzelnes Skript presst. Außerdem kann er Methoden, die nicht verwendet werden, entfernen, was gut ist, wenn man Bibliotheken einbindet, von denen man nur wenige Sachen nutzt. Allerdings birgt das auch Risiken, dass er zu viel entfernt, oder die Namen von externen Bibliotheken, wie die Google Maps API, umbenennt, wodurch die nicht mehr funktionieren usw. Für all das gibt es Optionen, um das zu verhindern, da müsst ihr euch dann, wie gesagt, in die Dokumentation von Closure einlesen.
Ich bleibe bei der Voreinstellung “Simple”, die bringt nämlich auch schon was, und kopiere dort unser script.js hinein, klicke auf Compile und bekomme eine Datei, wo Kommentare, Leerzeilen und alles überflüssige entfernt wurde, Variablennamen verkürzt wurden, if-Verzweigungen vereinfacht wurden, usw., ohne dass dabei das Programm kaputt gemacht wurde.
Speichert die Datei unter script.min.js. Unsere vorher fast 300 Zeilen lange JavaScript-Datei ist nun 12 Zeilen lang. Die Datei ist nun also komprimiert. Ihr kennt das vielleicht von JavaScript-Bibliotheken, dass es dort eine komprimierte und eine unkomprimierte Version gibt. Mit solch einem Tool werden die komprimierten Versionen erstellt. Soweit ich weiß wird bspw. auch jQuery mit dem Closure-Compiler komprimiert, wobei die dann vermutlich diese Advanced-Methode verwenden.

Tja, das war’s. Das war der HTML5-Workshop. Rund sechs Stunden ging der jetzt mit diesem Video und rund ein halbes Jahr ist es jetzt her, dass ich das erste Video hochgeladen habe. An den Download-Zahlen des Ressourcen-Pakets habe ich gesehen, dass einige hundert mitmachen.
Ich hoffe, ihr habt ein paar neue Einblicke in HTML5 und CSS3 gewinnen können. Die Seite ist nicht perfekt und auch nicht cross-browser-kompatibel. Aber das war ja auch nicht das Ziel, deswegen hatte ich ja anfangs gesagt, man solle den WebKit Nightly Build verwenden. Ziel war es, einmal eine Seite zu schaffen, wo viele der neuen Features von HTML5 und CSS3 Anwendung finden.

Wenn ihr mehr über HTML5 wissen wollt, bleibt bei css3-html5.de dabei, fügt es eurem facebook hinzu, dann kriegt ihr alle Updates mit, auch wenn ich neue Tutorials hochlade oder es neue Entwicklungen bei HTML5 gibt.

Weiterführende Links:

• HTML5 Shim ist ein Skript, das in den alten IEs die neuen HTML5-Elemente erstellt, damit sie gestylt werden können
• Der IE6 Countdown ist eine Kampagne von Microsoft, um den weltweiten Marktanteil des IE6 auf unter 1% zu bringen. Unter Join The Cause findet ihr Code, den ihr einbinden könnt.
• Der Google Chrome Frame ist ein Plugin für alte Internet Explorer, um Googles webstandard-konforme Engines in den Internet Explorer zu bringen und Webdevelopern das Leben zu erleichtern.
• Remy Sharps Blog – What is a Polyfill? Polyfills sind Skripte, mit denen ein HTML5 Feature nachgerüstet wird, wenn es in einem Browser noch nicht vorhanden ist.
• Paul Irishs Liste von HTML5 Cross Browser Polyfills auf GitHub.
• Sizzle ist die CSS Selectors Engine, die auch jQuery intern nutzt, um Elemente per JavaScript über CSS Selektoren zu finden.
• ExplorerCanvas ist ein Skript, um alten Internet Explorern die HTML5 Canvas API beizubringen.
• Das geo-location-javascript vereint verschiedene Techniken, um in mehreren Browsern eine Geolocation API zur Verfügung zu stellen
• Modernizr ist eine Bibliothek, mit der man prüfen kann, ob ein HTML5 feature im Browser vorhanden ist. Die Modernizr 2 Beta Preview bietet die Möglichkeit, sich sein eigenes Modernizr zusammenzustellen.
• Die HTML5 Boilerplate ist ein HTML-, CSS- und JavaScript-Template, das sämtliche best practices beinhaltet. Lest den Get Started!-Artikel, wenn ihr sie einsetzen wollt.
• Über die Google Font API kann man ausgesuchte Webfonts in seine Seite einbinden. Vorteile sind, dass man nicht mehr selbst auf Lizenzen achten muss, dass man nicht mehr selbst die Schriftart in verschiedenen Formaten erstellen oder beziehen muss, dass man sich nicht mehr selbst um eine @font-face-Syntax kümmern muss, die in allen Browsern funktioniert, da all das Google macht. Nachteile sind, dass die Google Font API nur eine gewisse Auswahl an Schriftarten bereitstellt.
• Google Closure Compiler ist ein JavaScript-to-JavaScript Compiler, mit dem man Skripte reduzieren kann, zu Performance-Zwecken. Lest die Dokumentation, wenn ihr ihn einsetzen wollt. Neben Closure gibt es auch UglifyJS und den YUI Compressor.