HTML5 total Technikwürze 169

Herzlich willkommen zur Technikwürze 169. HTML5 ist unser Thema und Peter Kröner unser Gast. Hallo Peter.

Hallo.

Und ebenfalls mit im Studio sitzt David Marzewski.

Wie immer. Halli hallo.

Und auch ich bin mal wieder dabei. Marcel Böttcher, hallo. Peter, du musst singen.

Herzlich willkommen zu Technikwürze, eurem Design- und Webstandards-Podcast.

Ja, ich sag auch noch mal herzlich willkommen. Peter, du hast grad 'n Buch veröffentlicht beziehungsweise bist gerade dabei, das zu veröffentlichen. Auf jeden Fall ist es fertig geschrieben und heißt HTML5, Webseiten innovativ und zukunftssicher, erscheint bei Open Source Press. Hast du dein Belegexemplar schon bekommen?

Nein, und ich hab heute erfahren, dass es, soeben, ich glaub, zwei Tage nachdem ihr es erhalten habt, auch heute tatsächlich in die Post gegangen ist. Das heißt, wenn ich Glück hab, krieg ich's diese Woche noch.

Sehr schön. Auf jeden Fall haben wir das hier schon auf unserem Tisch liegen und wir wollen auch ein Exemplar verlosen in dieser Sendung, aber dazu später mehr. HTML5 ist heute unser Thema, denn, es hat natürlich in den letzten Sendungen von Technikwürze schon 'ne Menge HTML5-Inhalt gegeben, aber es gab noch keine Totalsendung und deswegen sind wir ganz stolz, dass wir dich jetzt mit an Bord haben.

Es ist mir eine Ehre.

HTML5 ist ja in letzter Zeit schon 'n Begriff, der sich sehr gut gesetzt hat, aber ich denke, man muss ihn trotzdem noch mal erklären, denn, da gibt es so 'n bisschen die Doppeldeutigkeit, oder?

Mindestens Doppel-, wenn nicht sogar Dreifachdeutigkeit. Also wir haben es bei HTML5 damit zu tun, dass wir da ein, da wiederholt sich so 'n bisschen die Geschichte, die wir mit, mit Ajax hatten. Das stand ja ursprünglich für diese asynchronen JavaScript Requests und steht mittlerweile für alles, was irgendwie JavaScript ist und bunt blinkt. Und bei HTML5 ist es ungefähr, das Gleiche. Da haben wir, einerseits eine, eine Spezifikation von 'ner neuen HTML-Version, die vom W3C gepflegt wird.

Dann haben wir eine andere Spezifikation von HTML5 plus 'n paar Erweiterungen, die von 'ner anderen Arbeitsgruppe gepflegt wird, die das Ganze auch initiiert hat. Und dann haben wir noch 'n großen Kreis an weiteren Technologien, wie zum Beispiel 'ne Geolocation API, die überhaupt nichts mit HTML5 zu tun haben oder nur sehr wenig, weil sie früher mal in den Spezifikationen drin standen, mittlerweile nicht mehr.

Und dieser ganze, dieses ganze Konvolut aus verschiedensten Technologien und Spezifikationen wird umgangssprachlich als HTML5 bezeichnet. Das heißt, wenn wir jetzt 'ne Sendung über HTML5 machen, müssten wir uns erst mal darüber einigen, was genau wir damit meinen.

Ja, mach doch mal 'n Vorschlag.

Gerne. Also ich bin immer dafür, dass man,, wie schon Martin Luther sagte, dem Volk aufs Maul schauen und danach reden. Also diese, große Zusammenfassung halte ich schon für, ganz zulässig. Es ist halt alles so 'n, 'n Haufen Technologien, die alle nicht das Gleiche machen, alle nicht denselben Ursprung haben und so weiter. Aber das interessiert ja eigentlich niemanden. Wichtig ist, was die machen und die machen halt alle den Browser stärker. Der kann mehr Sachen.

Also da denke ich, sollten wir dieses Ganze, dieses ganze Bestiarium behandeln.

Also ist bei uns-

Und das ruhig-

Ist bei uns HTML5 so alles, was so in naher Zukunft kommt und nicht CSS3 ist quasi.

Ja, ja. Also ich denke, das kann man der Einfachheit halber durchaus so machen. Wenn man halt genau sagen will, das und das steht in dieser oder jenen Spezifikation, muss man das natürlich genauer nehmen, aber für den Hausgebrauch reicht das.

Dann lass uns aber trotzdem noch mal auf die beiden Spezifikationen zurückkommen und, die dann auch noch mal abhaken, bevor wir uns mit HTML5 als großem Ganzen beschäftigen. Wär mein Vorschlag.

Ja, also ich, ja, ich könnte ja einfach mal so, mal so erzählen, wieso wir überhaupt HTML5 haben und was ist eigentlich mit XHTML2 passiert.

Das ist super. Dann hol ich mir 'n Kaffee. Nein, mach ruhig.

Ne? Weil die Geschichte ging ja eigentlich so: Man hatte ja irgendwann, Ende der Neunziger war das, glaub ich, HTML4.0.1 fertiggestellt. Und danach plante das W3C, 'n richtigen Neuanfang und wollte halt weg von dem HTML5, Quatsch, Entschuldigung, von dem HTML, wie es sich entwickelt hat, was nicht so ganz der technischen Basis entsprach, die dem ursprünglich angedacht war.

Da haben die Browserhersteller in diversen Browserkriegen mit lauter Zusatzimplementierungen und kreativen Interpretationen und eigenen Parsern und solchen Sachen 'ne Basis geschaffen, auf der das gesamte Web lief, die eigentlich nichts mehr mit der Originalintention zu tun hatte. Die technische Basis, Parser-Details, nicht wichtig für den Hausgebrauch, aber die war halt unterschiedlich. Und da sagte man sich: Lass uns doch mal von vorne anfangen.

Und dann haben sie angefangen, XML, zu nehmen und HTML in XML umzusetzen. Da kam dann XHTML1 raus. Das kennen wir alle. Das hat auch die Technikwürze als, Doc-Type. Und XHTML1 war so 'n bisschen die, XHTML-Vorstufe eigentlich nur. Das war noch von der technischen Interpretation her, wie es der Browser verarbeitet, normales HTML, aber schon so geschrieben wie XHTML. Wir kennen das ja, alle, alle Tags schließen und, und, Slashes in leeren Elementen.

Schön sauber schreiben.

Genau, schön, schön sauber schreiben. Und, XHTML2 sollte dann sozusagen die, zweite Stufe, das heißt die endgültliche, endgültige Verwirklichung des XHTML-Traums werden. Da hat man dann komplett umgestellt auf die, wirkliche XML-Verarbeitung. Das, wissen, glaub ich, gar nicht alle, aber das XHTML, wie wir das halt heute meistens so haben, auch bei der Technikwürze, ist gar kein echtes XHTML. Das steht da bloß drüber.

Genau, das wird nur nicht als Text ausgeliefert.

Ganz genau, das ist nämlich der Punkt. Das wird gar nicht als XML verarbeitet. Es wird halt nur so, der, der, der, Validator schaut da halt etwas strenger drauf. Und XHTML2 wäre halt, -

echtes XML gewesen. Das hätte da so kleine Probleme gegeben in der Umsetzung, wie zum Beispiel, man kennt das von XML, ein kleiner Tippfehler, ganzes Dokument unbenutzbar und der Internet Explorer kann das auch nicht, also überhaupt nicht. Der kann keine XHTML-Dateien verarbeiten in keiner Version. Und, das größte Problem war eigentlich, dass das W3C diese ganze schöne Spezifikation zu XHTML2 entwickelt hat, ohne die jene zu fragen, die das am Ende umsetzen müssen.

Die Browserhersteller, die hatten da nämlich nicht so großes Interesse dran. Die haben die Zukunft eher in HTML gesehen. Dann haben die eines Tages angefangen, zu sagen: „Ja gut, wenn die nicht auf uns hören, dann machen wir eben unsere eigene Spezifikation und, denken uns selbst Sachen aus und implementieren die direkt auch." Und das war dann sozusagen die Geburtsstunde von HTML5. Das ging dann so eine Zeit lang.

Die haben beim W3C dann lustig an ihrem XHTML gearbeitet und, die andere Arbeitsgruppe, diese WHATWG, die sich eben zusammensetzte aus den Browserherstellern und Google war damals noch keiner, ist ja mittlerweile auch einer, haben ihre eigene, mhm, Version des Ganzen dann, gebastelt und irgendwann wurde dann halt klar, dass, XHTML2 auf dem Papier schön und gut ist, aber in den Browsern nichts drin ist. Das wurde nie umgesetzt.

Und dann musste irgendwann sozusagen das W3C die Niederlage eingestehen, hat dann, gewissermaßen die Spezifikation, die die andere Arbeitsgruppe, die WHATWG gebaut hat, geforkt. Und jetzt haben wir zwei HTML-Spezifikationen, die nebeneinander existieren. Und spätestens ab hier wird's dann kompliziert.

Vor allen Dingen, weil HTML5 selbst ja noch nicht fertig ist.

Ja, fertig ist auch so eine Sache. Was heißt fertig?

Zukunftssicher implementiert, würde ich es deuten, aber ich glaube, davon sind wir noch weit entfernt.

Ja, ich, ich würde sogar, also da, da gibt's mehrere, Aspekte dazu. Es geistert so 'n bisschen immer dieses, dieses Jahr 2022 durch die Gegend, weil das mal der Ian Hickson, der Chefredakteur der Spezifikation ist, weil der das mal versehentlich gesagt hat. Und jetzt gehen alle davon aus, dass in, dass das dann irgendwie, dass das das Jahr ist, ab dem wir dann zack HTML5 als Webstandard haben und wir können das alle benutzen.

Ungefähr so wie wir heute ja, HTML4 als relativ stabilen Standard haben, auf dem man bauen kann. Da muss man nicht groß testen, da weiß man, diese Elemente funktionieren alle. HTML5 ist ein bisschen komplizierter in der Hinsicht, als dass das Ganze, von der, Anlage der Spezifikationen her, komplexer ist. Da wird zum Beispiel auch festgelegt, wie ein HTML-Parser zu arbeiten hat.

Da sind sehr viele dynamische Sachen, eingebaut, was man also normalerweise gar nicht als HTML bezeichnen würde, sondern irgendwie als so 'n JavaScript-DOM-Zeug. Das ist alles fester Bestandteil von HTML5, alles darin spezifiziert.

Und bis das alles, in mindestens zwei Browsern – das ist die Voraussetzung – so perfekt umgesetzt ist, dass man sagen kann, hier haben wir 'ne vollständige Implementierung, dann könnte man das, so ist die Rechnung, zum Webstandard erheben und irgendwer hat dann mal auskalkuliert, das dürfte wohl so bei der derzeitigen Entwicklungsgeschwindigkeit 2022 sein.

Was jetzt erst mal relativ unrelevant ist.

Ja, also ich glaub auch ehrlich gesagt nicht, dass das überhaupt so weit kommt.

Wie viele Spezifikationen im Moment?

Ich glaub, das sind ungefähr, also das kommt halt drauf an, welche Spezifikation man nimmt, aber, die der, der WHATWG, also derer, die von denen, die halt die treibende innovative Kraft sind, sag ich jetzt mal, und die eben auch die Browserhersteller sind, die hat, glaub ich, so um die 700 Seiten. Mittlerweile wahrscheinlich 'n bisschen mehr.

Würdest du sagen, dass das eher die ist, an die man sich, na ja, mehr oder weniger halten-- Ich mein, man muss sich jetzt ja wirklich, keine an die kompletten 700 Seiten halten, aber würdest du eher sagen, dass die Version der WHATWG oder, das W3C so die, die führende und leitende dabei ist?

Also das ist, schwierig. Im Moment zeichnet es sich so ab, dass die, Spezifikationen des W3C von dem, was da drin steht, 'ne Teilmenge sind von den Spezifikationen der WHATWG. Ja.

Also wir haben, die Spezifikationen der WHATWG setzen sich sozusagen zusammen aus dem, was beim W3C in der HTML5-Spezifikation drinsteht, in der Canvas-Spezifikation drinsteht, in der Microdata-Spezifikation drinsteht und dann gibt's noch 'ne neu, 'ne relativ neue Erfindung, das Device-Element ist auch 'ne eigene Spezifikation. Ich glaub, jetzt ist es 'n guter Zeitpunkt, mal auf 'ne Grafik zu verweisen, die wir jetzt hier, auch in dem, in dem Post verlinkt haben.

Da hab ich mal versucht, mit so, mit 'nem Diagramm mit vielen bunten Kreisen darzustellen, wie das alles ungefähr miteinander in, in Beziehung zueinander steht. Ich glaub, es ist sinnvoller, da drauf zu gucken, als das jetzt versuchen zu erklären. Das ist sehr schwierig, das alles zu sagen.

Also im Grunde genommen, ist das Thema, das wir am Anfang erwähnt haben, dass es, die HTML5-Spezifikationen gibt und das, womit wir HTML5 in Verbindung bringen, nämlich Geolocation und so weiter, das soll das mal ein bisschen aufschlüsseln, wo ist was verankert und wie sie ganze, wie ist das aufgehangen.

Ja, wobei halt die Frage ist: Was, was, was hilft einem diese, diese, diese Erkenntnis dann, was wo steht? Es, es hilft einem ja nicht besonders viel heutzutage, weil das ja noch nicht alles notwendigerweise überall umfassend implementiert ist. Es gibt so Sachen, wie das Canvas-Element, das kennt, glaub ich, mittlerweile auch jeder. Diese Zeichenfläche, die man mit JavaScript programmieren kann, die angeblich Flash killen soll. Die hat man überall zur Verfügung.

Die kriegt man sogar im Internet Explorer 6 ans Laufen mit 'n paar Tricks. Die ist zum Beispiel stabil. Andere Sachen wie zum Beispiel, hm, nehmen wir mal die, bob, bob, bob, Data-Attribute. Man kann sich in HTML5 buchstäblich neue Attribute ausdenken. Das ist 'ne ganz praktische Sache. Braucht auch ange, an sich keine besonderen Browserfähigkeiten, aber da gibt's 'ne Schnittstelle für die, spezifiziert ist und die gibt's zum Beispiel noch nirgends. Und solche Späßchen sind da alle drin.

Man weiß es halt nicht genau. Was aber ziemlich gut ist, ist, die WhatWG führt Buch darüber, wo was implementiert ist. Wenn man dieses, Monsterdokument aufmacht und dem Browser ein bisschen Zeit lässt, das zu rendern, das ist, das dauert halt 'n, 'n kleinen Moment, selbst im schnellsten. Und wenn man dann so runterscrollt in den verschiedenen Features vorbei, dann kommt links so eine kleine Einblendung mit so Browser-Icons und da kann man ablesen, wie umfassend wo was implementiert ist.

Das ist relativ hilfreich, nützt dann aber auch nur, so lange, weil halt, ne, wenn da zum Beispiel steht, da ist etwas teilweise implementiert, dann steht man wieder vor der Frage: Ja, was heißt denn jetzt teilweise? Da muss man genau, gucken und letztlich hilft eigentlich nur testen, testen. Also um auf die Ausgangsfrage mal zurückzukommen: Auf welche Spezifikation kann man sich am ehesten stützen? Keine.

Eher das, was wieder der Stand der Implementation ist.

Genau. Also ich, maßgeblich ist halt, was geht im Browser und was geht nicht.

Obwohl sich das auch ziemlich, ändert, gerade wenn man so die Nightly Builds sich runterlädt und sich das da anschaut. Da kann sich ja täglich auch was ändern.

Genau, es ist halt die Frage: Auf was zielt man? Letztlich ist, haben wir das alte Problem, des ei, des einen Browsers, der mit I anfängt. Der ist halt so der, der kleinste gemeinsame Nenner. Der kann zwar auch einiges aus diesem HTML5-Zettel und viel anderes kann man tricksen, aber nicht das meiste. Wenn man halt den mitbedienen möchte, dann, verengt sich der Kreis der Sachen, die man machen kann natürlich schon. Und dann ist halt die Frage: Wie kriminell möchte man in seinen Hacks sein?

Und, dann geht das schon. Ja, ich, ich erzähl das jetzt, glaub ich, jetzt alles 'n bisschen zu negativ. Es gibt ein paar Sachen da drin, die sind, die sind wirklich stabil und die kann man benutzen. Damit kann man tolle Sachen machen. Andere gehen im Internet Explorer nicht, aber die sind halt zum Beispiel super getrickst. Dieses, Canvas-Element kann man da zum Leben erwecken mit 'ner JavaScript-Bibliothek. Das funktioniert, in neunundneunzig Prozent aller Fälle ohne jede Abstriche.

Was gibt’s denn so grundsätzlich, was gibt’s denn grundsätzlich bei HTML5, was so, so Neues oder was ist beim Alten geblieben?

Beim Alten geblieben ist eigentlich, dass, fast nichts aus dem alten HTML-Standard entfernt wurde. So gut wie gar nichts. Man könnte also in den meisten Fällen den neuen HTML5 Doctype nehmen und den über 'ne gewöhnliche XHTML-Seite wie die Technikwürze kleben und ich wette, das, funktioniert völlig problemlos. Also das alte HTML4 ist zu neunundneunzig Prozent wiederum 'ne Teilmenge vom neuen HTML5. Das ist alles beim Alten geblieben.

Es gibt ein paar Vereinfachungen und Vereinheitlichungen, von denen auch jetzt nicht alle wirklich relevant sind, weil die optional sind. Man kann zum Beispiel, wenn man einen Skriptblock aufmacht, das Type-Attribut weglassen, sofern es sich bei diesem Skript um JavaScript handelt. Das ist jetzt einfach als Standard festgelegt, weil man auch festgestellt hat, die Browser beachten dieses Type-Attribut nicht.

Die gucken halt, ist das JavaScript vom Inhalt her und wenn ja, führ ich's aus und wenn nicht, lass ich's halt bleiben.

Genau, das war nämlich bisher bei den Validatoren, wenn sich da jemand dran gehalten hat, 'n beliebiges Problem, dass man einfach dieses Type nicht gesetzt hatte aus Faulheit. In Zukunft braucht man's überhaupt nicht mehr.

Ganz genau. Gleiches Ding auch bei, bei Style. Da kann man das auch fallen lassen. Das sind so Kleinigkeiten. Die sind auch eigentlich ganz nett und die kann man dann, die gehören wirklich auch zu dem, Kreis der Dinge, die man völlig problemlos verwenden kann. Was ich jetzt grad alles so, mit negativ und nicht implementiert und Internet Explorer und so erzählt hab, das sind ja wirklich alles die, bahnbrechenden Neuheiten, bei denen man 'n bisschen aufpassen muss.

Bei den, bei dem, was man vielleicht so, beim tagtäglichen Seitenbau, zu tun hat, da bietet HTML5 auch einiges. Meistens halt Vereinfachungen und 'n paar neue Elemente. Da kann man fast sein Hirn ausschalten und die verwenden.

Wollen wir erst mal zu dem spannenden Bahnbrechenden kommen.

Ja, wir können das, lass uns doch erst mal praktisch bleiben.

Na gut.

Also ich find ja zum Beispiel den Doctype ganz klasse. Ich weiß nicht, könnt ihr euch den irgendeinen, Doctype außer dem HTML5 Doctype merken?

Nee, Copy und Paste. Hm?

Wollte ich grad den von HTML5, aber gut.

Der von HTML5 besteht im Prinzip nur aus zwei Wörtern, aus eben, ne, Doctype HTML und fertig. Und der funktioniert. Und der funktioniert auch in jedem Browser. Das Praktische ist, ist nämlich, Doctypes haben eigentlich Browser noch nie wirklich interessiert. Hauptsache, da steht irgendwas, was so ungefähr nach Doctype aussieht. Und deswegen ist das auch eine von diesen Vereinheitlichungen von HTML5 einfach, dass man sich dieses Ding merken kann. Ne, super Sache.

Und alles, was man eben aus dem alten HTML4-Kanon weiterverwenden möchte, kann man mit ganz, ganz, ganz wenigen Ausnahmen, auch weiterhin machen. Und zack, schon hat man sich den Seitenbau 'n bisschen vereinfacht, wenn man schon mal nicht dauernd dieses Ding hin und her copy pasten muss oder sich Templates anlegen muss und solche Sachen. Das ist zum Beispiel 'ne prima Sache.

Ich glaub, die Erfindung der Snippets geht auf dieses, Doctype zurück.

Da, würde ich mich durchaus hinter stellen, hinter diese Vermutung, ja.

Ist bestimmt ein ganz, ganz mieses Spiel.

Und dann gibt's noch so 'n paar Elemente aus, aus früheren HTML-Zeiten, die wiederbelebt werden. Man erinnert sich jetzt zum Beispiel was mit XHTML, -W -Pff. Was mit XHTML aus dem Standard geworfen wurde, waren ja so Präsentationselemente. B, I, HR, solche Sachen.

Wo wir jahrelang gepredigt haben, ne, no bitte strong und em.

Genau. Und das ist auch weiterhin nicht grundsätzlich falsch, wenn man das so predigt. Es ist nur so, die werden halt, wiederbelebt, in einer neuen Rolle.

Man dürfte wieder, es muss aber nicht.

Ja, also das sind die gleichen Elemente im Sinne von, die haben die gleichen Tags, B, I, HR, aber dieses, das sind halt, die sind halt jetzt in den Stand von semantischen Elementen erhoben worden. Die haben also jetzt 'ne Bedeutung. Das ist zum Beispiel ganz banal bei, bei B und I kann man damit einfach, Text von anderem Text, stilistisch absetzen, ohne jetzt darauf festgenagelt zu sein, dass B für bold und, I für italic steht. Das wäre halt nur so die gängigste, Textliche Repräsentation davon.

Also sagen wir mal so, also wenn ich jetzt b anstatt, strong nehme, dann wird das, ausgangssprachlich, wenn ich das vorlese, nicht extra betont, wie ich das bei strong machen würde, sondern es wird nur grafisch hervorgehoben.

Nicht unbedingt nur grafisch. Es könnte auch beispielsweise bei einer Audioausgabe beim Screenreader anders, abgese-- anders, ausgegeben werden. Der Punkt ist halt, der Text ist abgesetzt, aber nicht in seiner Bedeutung verändert. Strong ist eben buchstäblich halt stark betont, also wichtig. Das andere ist halt nur anders.

Und bisher gab's für, für b und i und, so weiter gar keinerlei Bedeutung, oder?

Nein, das waren völlig, bedeutungsleere Elemente, die buchstäblich gesagt haben: b ist fett, i ist italic. Das ist jetzt 'ne, 'ne sehr feine Unterscheidung, wo man halt wirklich genau schauen muss. Also was zum Beispiel, 'n Beispiel ist, was ich ganz gerne immer nehme zur Erklärung, ist, wenn man einen Text liest und da kommen jetzt, sagen wir mal, Schiffe drin vor. Ja, das Schiff heißt dann jetzt meinetwegen die Technikwürze.

Dann ist das ja im, im gedruckten Text häufig so, dass, solche Namen von Schiffen, kursiv gesetzt werden. Ist ja nicht unüblich, weil die halt abgesetzt sind, weil's halt 'n Eigenname ist von einem Gegenstand. Das wär zum Beispiel 'n Einsatzgebiet für das, für das i-Element im neuen Sinne von HTML5, weil, die Gegenstücke dazu in XHTML em wäre ja falsch. Wir wollen ja den Schiffsnamen nicht besonders betonen, sofern er nicht im jeweiligen Kontext besonders wichtig ist.

Und die Alternative dazu wäre dann halt, 'n Span-Element mit irgendeiner Klasse aufzumachen, was auch 'n bisschen unglücklich ist, weil es ist ja durchaus 'ne übliche Darstellung von solchen Schiffsnamen in so einem Text.

Ja, ist 'n gutes Beispiel.

Für solche Sachen ist das halt. Und das Gute ist halt, i und b, die sind nie aus irgendwelchen Browsern rausgeflogen. Die kann man verwenden, völlig problemlos. Selbst im IE5, wenn man möchte. Ich hab's ausprobiert. Das ist zum Beispiel 'ne ganz praktische Sache. Oder das, das hr-Element. hr ist ja klar, horizontal rule. Das stand früher für buchstäblich einen horizontalen Trennstrich. Und das ist jetzt einfach ein inhaltlicher Trenner.

Sagen wir mal, wir haben in einem Kapitel, wo eine Geschichte mit unseren tollen Schiffen erzählt wird, 'n Szenenwechsel. Wir wechseln vom Hafen in Hamburg zum Hafen in... Schieß mich tot. Sag was. Buenos Aires.

Ja, das ist irre. Hört sich gut an.

So. Ja, und we-- und eben diesen Szenenwechsel könnte man ganz früher mit diesem, mit diesem, hr-Element trennen, was halt in HTML5 nicht mehr heißt, als dass hier ein inhaltlicher Schnitt stattfindet. Der ist immer noch, wenn man das jetzt ungestylt lässt, in den meisten Browsern durch 'nen horizontalen Trennstrich repräsentiert. Aber das kann man ja ändern. Also das sind, sind immer so ganz feine Nuancen, aber das ist schon hilfreich.

In älteren Spezifikationen ist dann 'n hr wirklich, wie muss ich mir das vorstellen? Wie ist das definiert? Wirklich einfach nur als 'ne Linie und komplett bedeutungslos, oder?

Genau. Also, wenn ich mich jetzt nicht, nicht, nicht falsch erinnere, ist das so, ja.

Also sozusagen könnten wir auch sagen, dass das hr eigentlich 'n Comeback feiert mit HTML5, weil die meisten Webentwickler da drüber gegangen sind und haben einfach gesagt: „Ich nehm hier 'n Div und, pack per CSS 'n Border drunter." Und da könnte man jetzt semantisch noch einen draufsetzen und sagt: „Ich pack jetzt wieder die hr rein."

Mhm. Ganz genau. Das ist also-- Man könnte sagen, es feiert 'n Comeback. Andererseits, es ist, es ist schon irgendwo was Neues. Es hat nicht mehr viel damit zu tun, außer dass es halt in der Standarddarstellung, wenn man CSS komplett weglässt, gleich aussieht in den meisten Browsern. Das ist alles. Es hat noch 'ne ganz andere nette, nette Eigenschaft. Da kommen wir auch gleich super zu den neuen semantischen Elementen. Aber, es gibt ja diese schöne, W3C-Spezifikation für Zugänglichkeit, Aria.

Und, die ist mit HTML5 verzahnt in dem Sinne, dass einige von den neuen HTML5-Elementen automatisch solche Aria-Attribute quasi eingebaut haben. Die muss man dann nicht mehr manuell reinschreiben. Das heißt, wenn wir jetzt also irgendein Programm haben, 'n Screenreader oder so was, der, mit Aria arbeitet und wir ein hr-Element einsetzen und der Screenreader hält sich an HTML5-Spezifikationen, dann weist er diesem hr-Element automatisch Role Separator zu. Das ist direkt eingebaut.

Das erspart einiges, ja. Also quasi noch mal für die, die, die das nicht wissen, was das ist. Also noch mal eine extra Betonung: Du bist jetzt, vom Element Trenner.

Genau, es geht halt bei Aria darum, eben solche Konstruktionen wie dieses schon erwähnte Div-Element mit 'ner Border irgendwie mit 'ner Bedeutung aufzuladen. Oder irgendwelche selbstgebastelten Widgets mit Ladebalken oder so was, wo nur bei der visuellen Darstellung klar wird, was das soll. Aber für 'n Screenreader ist es 'n Haufen Diffs und nicht wirklich ersichtlich.

Und mit diesem Aria kann man das halt machen, dass da, dass man mitteilt: „Pass auf, das hier, das Gesamtkonstrukt ist 'n Ladebalken, das hier ist der Fortschritt und so weiter und so weiter."

Hast du noch 'n paar praktische Beispiele neben dem hr?

Wo das eingebaut ist? Aria? Ja, ganz klar. Wir haben ja auch noch, bei HTML5 viele neue Elemente. Header, Footer, Section hat der eine oder andere sicherlich schon gesehen. Da ist auch überall schon so was, eingebaut. Ich hab jetzt grad die Spezifikation blöderweise nicht vor, Augen, aber zum Beispiel im Header und Footer gibt es entsprechende Aria-Gegenstücke und die sind automatisch da, dran gebaut.

Also-

Das heißt-

Ganz kurz, das ist noch mal 'n Ersatz jetzt genau für das, was wir bisher gemacht haben: Div, class sidebar, Div class header und Div class footer. Da gibt's jetzt extra Elemente in HTML5 dafür.

Ganz genau. Die einem eben erstens ersparen, dass man da dauernd mit, Classes rumwurschtelt, die es einfacher machen, wenn man irgendwie das Dokument maschinell erfassen möchte, zu sehen, was ist was, was ist 'ne Sidebar, was ist unwichtig, was ist wichtig. Und was halt eben wirklich super ist, ist für alle Leute, die sich jetzt nicht mit, mit Aria rumgeschlagen haben bisher in ihrem Leben. Ich würd mal behaupten, das ist die Großzahl.

Die wertet halt durch die Verwendung dieser neuen Elemente, sofern die Elemente korrekt verwendet werden, diese Seite auch aus, Sicht der Zugänglichkeit automatisch mit auf. Weil diese ganzen Screenreader, sofern sie HTML5 verstehen, diesen ga, diese ganzen ARIA-Hilfsmittel direkt drin haben. Das betrifft zum Beispiel auch die Formularelemente, die neuen.

In der Praxis, wenn wir mal kurz bei, bei den von dir genannten neuen Elementen sind, haben wir dann wahrscheinlich im Moment zweierlei Probleme. Also zum einen so was wie 'n, wie 'n Header oder, 'n Footer und so weiter ist im Moment noch relativ schwierig einzusetzen?

Ja, es kommt halt dann wieder, dann, dann sind wir im Bereich der, der Internet Explorer, Experimente. Das ist das eine.

Und zum anderen, natürlich ist es super darauf zu setzen. Allerdings bis die ersten Screenreader das wahrscheinlich implementiert haben, auch wenn ich auf dem, Gebiet nicht so firm bin, aber die sind ja auch noch, die sind ja meist relativ langsam. Das heißt, bis das in der Praxis wirklich zum Tragen kommt, vergehen wahrscheinlich noch ein paar Tage, Monate, Jahre.

Ich weiß, ich hab blöderweise ist mir die letzten Tage an, irgendwas an mir vorbeigescrollt, wo drinstand, dass das wohl in dem einen oder anderen Programm schon teilweise unterstützt wird.

Schade, dass es nur vorbeigescrollt ist.

Das ist das Problem, ja. Aber also ich, ich bin da nicht zu pessimistisch, weil das ist eigentlich, es ist letztlich nur 'n, also ich stell mir das jetzt in der, in der Implementierung aus meiner Laiensicht jetzt nicht so wahnsinnig kompliziert vor. Es ist halt ein HTML-Element, wo automatisch diese Dinger, diese ei, diese gewissen Eigenschaften mit drin sind. Das ist 'ne relativ übersichtliche Tabellenspezifikation. Kann man sich auch als Normalverbraucher angucken.

Da ist im Übrigen auch, festgelegt, man, man kann das teilweise überschreiben. Also man wird jetzt wahrscheinlich nicht, es haben, dass man ein Header-Element hat, was gar kein Header sein soll. Aber bei einigen Elementen, kann man sich halt vorstellen, dass das in 'ner anderen, ARIA-Rolle vorkommen soll und dann kann man das auch teilweise überschreiben. Also ich wär da jetzt nicht so pessimistisch.

Und selbst wenn das jetzt nicht unterstützt wird, wenn's in zwei Jahren unterstützt wird und man baut die Seite jetzt schon, dann ist die halt in zwei Jahren nicht mehr eines Umbaus bedürftig. Ist doch auch schön.

Natürlich. Also es gäbe ja auch eigentlich keinen Grund dafür, dafür, das Ganze nicht einzusetzen, wenn wir den IE ausklammern würden.

Ja, das, das ist das, das Problem. Der IE mag keine unbekannten Elemente. Also der, implement-- Also ein normaler Browser, sagen wir jetzt mal Firefox oder so was, wenn der ein unbekanntes Element trifft, dann, denkt er sich halt: „Ja gut, kenn ich halt nicht, behandeln wir aber wie jedes andere." Und der Internet Explorer verschluckt sich daran auf eine, Art und Weise, die lässt einen schon an den Kopf greifen. Ich bin jetzt kein Browserprogrammierer, vielleicht mache ich das zu Unrecht.

Aber es ist schon so, dass, die Verwendung von diesen neuen Elementen Header, Footer, Section und so was im IE zum Totalschaden führt, falls man nicht, Vorsichtsmaßnahmen ergreift.

In Form eines JavaScript, die ihm das beibringen.

Das ist die eine Möglichkeit der Vorsichtsmaßnahme. Man kann dem Internet Explorer mit einem JavaScript, was auch so simpel ist, dass... Also das ist der Punkt, wo ich mir an den Kopf greife. Es ist ein einfaches document.createElement, unbekanntes Element. Wenn man das ein einziges Mal ausführt, bevor der Internet Explorer irgendwo im Code auf dieses Ding trifft, dann verarbeitet er das korrekt. Wenn man das nicht macht, dann nicht.

Das Problem ist halt, diese Lösung baut auf JavaScript und da kann man sich ja nicht drauf verlassen.

Was passiert? Also du sprachst von einem Totalschaden. Wie sieht dieser Totalschaden dann in der Praxis aus?

Der ist recht lustig. Man hat ja, bei so 'nem neuen Element, sagen wir mal Header oder Footer, zwei Tags. Spitze Klammer, Header, spitze Klammer und das schließende Tag, spitze Klammer, Slash, Header, spitze Klammer.

Und zweites, glaube ich, missachtet er, oder? War das nicht die Lösung?

Nein, besser. Besser, besser. Der hält, der hält beide Tags für öffnende Tags eines Elements.

Ah, genau.

Ja, er glaubt also, es gäb, es gäbe ein, Header-Element. Nicht ganz falsch, aber er glaubt auch, es gäbe ein Slash-Header-Element. Und wie halt so 'n guter HTML-Parser ist, der versucht, 'n kaputtes HTML zu reparieren, indem er dann halt automatisch Endtags einfügt. Und dann haben wir da plötzlich irgendwo im Code drinstehen Slash Slash Header als schließendes Element für Slash Header, was natürlich völliger Kappes ist und, nicht brauchbar.

Und das machen alle Internet Explorer bis zur Version acht. Also da ist, kein Land zu sehen.

Genau, und das, was Microsoft angekündigt hat für die Version neun, ist, dass unbekannte Elemente – das hatten wir in der vorletzten Technikwürze-Sendung –, erstmalig unterstützt werden sollen, genauso wie heute das Firefox macht.

Genau, wobei wir beim Firefox auch schon mal wieder 'n bisschen weiterkommen können, weil der unterstützt die nicht, der unterstützt die normalerweise eigentlich auch nicht. Der verarbeitet die nur eben auf eine Art und Weise, wo man sich nicht an den Kopf greift. Also für den ist 'n, ist jetzt sagen wir mal 'n Header oder 'n Section oder so was, das ist für den genauso gut wie 'n, wie 'n Span.

Das ist ja sozusagen sein Fallback für „Kenn ich nicht, nehmen wir's halt so." Und das ist ganz gut, weil, dann kann man ja einfach sagen: „Pass auf, Section, dir weise ich jetzt 'n, Display Block zu und zack, du verhältst dich jetzt genauso wie 'ns, wie 'n Section-Element, wie es in den Standards definiert ist." Also der kennt die auch nicht wirklich, aber man kann mit denen dann arbeiten.

Einerseits, andererseits, der Firefox 4 wurde ja schon angekündigt und der wird einen echten HTML5-Parser dabei haben, wo die Dinger dann endgültig auch richtig verarbeitet werden. Also so weit sind wir schon und der IE 9 auch angekündigt. Also es sieht gar nicht so schlecht aus in naher Zukunft.

Gut, in naher Zukunft, mit IE, 6, 7 und 8 – korrigiere mich, wenn, wenn ich falsch liege –, laufen wir mit, mit Header und Co. komplett gegen die Wand, richtig? Außer wir verlassen uns auf JavaScript.

Ja, es kommt wieder drauf an. Man, man, man kann, man, man kann ein paar sehr,, kreative Konstruktionen bauen, bei denen man sozusagen diese neuen Elemente Auf eine Art, Progressive Enhancement, auf einen Progressive-Enhancement-Sockel stellt. Wenn man sein HTML auf eine ganz spezielle Weise konstruiert, kann man um dieses Problem drum herum arbeiten.

Das ist aber jetzt schon wirklich sehr esoterisch und da hab ich auch 'ne ziemlich große Grafik in meinem Buch für gebraucht, um das einigermaßen zu erklären. Weil das Problem ist nicht nur, dass HTML geht kaputt, sondern natürlich geht halt, weil die Elemente völliger Käse sind, auch das, das CSS klappt dann nicht mehr.

Man kann kein Section-Element im Internet Explorer ansteuern, auch wenn es ja teilweise da ist, von diesem Relikt, was dann aus dem Slash Section hervorgeht, mal abgesehen, aber das klappt alles nicht. Und man kann zwar was tricksen, aber das ist alles nicht schön. Ich find das aber auch gar nicht so schlimm, weil der IE6 ist, glaube ich, der letzte der, seiner Art, der so'n bisschen, der so'n echtes Problem ist im Sinne von der existiert Jahre und Jahrzehnte.

Also ich weiß nicht, was eure Statistiken sagen, aber ich glaub, der IE7 ist schon relativ stark am Abbauen im Vergleich zum Achter und ich hab auch relativ großes Vertrauen daran, dass der Neuner dann mit den ganzen alten, die da noch übrig sind, relativ schnell aufräumt. Also es wird, glaube ich, nicht noch mal so schlimm wie, wie mit dem, IE6.

Ja, im Vergleich zum Sechser, der jetzt natürlich auch 'ne deutlich längere, Lebenszeit hatte als der Siebener oder dann jetzt dann irgendwann bald dann auch der Achter. Also bei den, bei den anderen beiden, beim, beim Siebener, ist es schon so, dass man, dass man deutlich sieht, dass die Welle da auch weiter rollt und, n-nicht irgendwo hängen bleibt jetzt für die nächsten zehn Jahre.

Meiner Meinung nach sind wir sowieso langsam an 'nem Punkt, wo wir uns über den Sechser mal Gedanken machen müssen im Sinne von: Wollen wir uns über den noch Gedanken machen? Aber das ist dann wahrscheinlich eine andere Sendung. Festzuhalten bleibt auf jeden Fall, dass es eigentlich, außer man will es unbedingt einsetzen, um es einzusetzen, noch nicht so wirklich Sinn macht, wenn man den Sechser mit beachten muss.

Ja, alle Internet Explorer, die im Moment aktiv sind. Also der Achter macht genauso großen Käse wie der Sechser. Ja, es ist halt, es ist halt die Frage: Wie, wie konstruiert man sein Seitenkonzept insgesamt? Weil wenn man jetzt sagt, die Elemente mit JavaScript aktivieren ist genauso gut wie sie, wie die überhaupt nicht zu haben, da bin ich mir auch nicht so sicher.

Man muss halt einfach dafür sorgen, dass egal wer auf die Seite kommt, dass das Ding irgendwie benutzbar ist und ob das dann nun in der, exotischen Konfiguration Internet Explorer 7 Punkt was weiß ich und JavaScript aus dann 'n bisschen weniger schön aussieht als jetzt sagen wir mal im Firefox 3.5 unter, unter Mac, dann ist das halt so. Das muss man halt hinnehmen. Also ich würd da kein, kein Denkverbot aufstellen wollen. Es ist halt 'n bisschen komplizierter.

Wo glaube ich 'ne ganz andere Fußangel liegt, ist, dass, diese semantischen Elemente Header, Footer, Section, die haben noch 'ne andere Bedeutung. Das sind nicht nur einfach nur neue semantische Elemente, sondern die beeinflussen, wie, Überschriften, zusammenkonstruiert werden. Im Moment haben wir's ja so: Wir haben die Überschriftenelemente H1 bis H6 und dann ist Schluss. Und mit HTML5 haben wir unendlich viele. Wie geht das?

Das geht so, dass wir, diese, diese Section-Elemente zum Beispiel innerhalb eines jeden Section-Elements, beginnt die Zählung der Überschriften, der Überschriftselemente eins bis sechs von Neuem. Das heißt, wenn wir jetzt ein Section-Element nehmen und dann 'ne H1 reinschreiben, da drunter 'n Section, Section-Element packen und da auch 'ne H1 reinschreiben, haben wir aber, haben wir nicht eine Überschriftenfolge H1 H1, sondern quasi H1 H2, obwohl wir H1-Elemente verwendet haben.

Also diese, Verschachtelung der, strukturierenden Elemente beeinflusst die Überschriftenebenenkonfiguration.

Das heißt, hier muss ich mich wirklich dann oder s-sollte ich mich eigentlich, wenn ich mich nach dem Standard halten möchte, komplett umstellen eigentlich.

Wenn, sagen wir mal so, wenn diese neuen Elemente verwendet werden, sollen, dann muss man sich daran halten. Das ist ganz klar, weil sonst kommt, Überschriftenkäse raus und den wollen wir ja nicht haben. Ja, wobei natürlich die Frage ist, theoretisch könnte man mit dieser, wenn man das nutzt, auf alle Überschriftelemente außer H1 verzichten, weil die werden ja nicht mehr gebraucht. Wenn man 'ne neue Verschachtelungstiefe haben will, macht man 'n neues Section-Element oder so was.

Da ist dann aber wiederum wirklich die Frage: Was machen dann Screenreader, die kein HTML können? Was macht Google mit so was? Mit 'ner Seite, die nur H1 hat? Es ist schwierig.

Ja, hier kommen wir dann zur Aフェックス-Kompatibilität und, in relativ schwierige Gewässer.

Ja, es, es, es geht eigentlich. Man kann, man, man, man kann das kombinieren. Man kann die alten Überschriften, alte Überschriftenordnung mit Elementen H1 bis H6 mit den modernen, mit den modernen Section- und Article-Elementen und so was alles, so kombinieren, dass in beiden Fällen 'ne vernünftige Überschriftenordnung rauskommt. Ist 'n bisschen komplizierter, geht aber eigentlich.

Was eigentlich viel wichtiger ist, ist, man muss erst mal wirklich intus haben, wie dieser, Algorithmus funktioniert, mit dem diese Überschriften sortiert werden. Und, dann, kann ich, zwei Tools empfehlen oder sagen wir mal, wir nehmen ruhig das eine. Das ist 'n, der sogenannte HTML5 Outliner. Da kann man 'n HTML-Dokument reinstecken. Das Ding, verarbeitet Überschriften und Elemente gemäß HTML5-Regeln und gibt einem dann die Überschriftenordnung aus.

Und wenn man dann sieht, was hier rauskommt, das ergibt Sinn, dann weiß man, ich hab's richtig gemacht.

Ja, das hört sich doch nach 'nem sehr vernünftigen Tool an. Was haben wir denn noch für Elemente, die erwähnenswert wären neben den dreien, die wir jetzt hatten?

Also die drei, die wir jetzt hatten, waren jetzt ja, glaub ich, hauptsächlich Header, ist ja klar. 'n Kopfbereich entweder von 'ner ganzen Seite oder von einem Teilabschnitt. Footer ist das Gegenstück dazu, Seitenende. Und Section hatten wir, denk ich mal, oder? Section ist, Section ist, also, sozusagen das, - Das generische, Sektionierungselement, wie der Name schon sagt, das umfasst halt einen wie auch immer gearteten Abschnitt, der in sich mehr oder minder geschlossen ist.

Und so ein Section Element kann eben einen Kopfbereich haben und kann einen Fußbereich haben mit Header, Footer oder so was. Und, also wenn wir jetzt bei diesen Elementen sind, die also die grobe Struktur vorgeben, da haben wir noch ein paar mehr. Und zwar, einmal Article. Das ist das, was für, Blogs oder sagen wir mal für Forenbeiträge oder Kommentare unter einem Blogpost ganz sinnvoll wäre. Das sind jeweils in sich wirklich komplett geschlossene inhaltliche, Pakete von Inhalt.

Aside, klingt ein bisschen nach Sidebar, ist auch nicht falsch, ist aber für jede Art von Element, für jede Art von Inhalt das richtige Element, das so, das zum Hauptinhalt in diesem jeweiligen Kontext, also in einem Section Element zum Beispiel auch, nur eine ergänzende Information darstellt.

Also so was wie eine Metainformation.

Richtig. Genau. Zum Beispiel. Also bei einer, beim Blog wäre jetzt zum Beispiel die ganze Sidebar könnte im Gesamtkontext der Seite eine aside sein, weil da eben nur so Sachen drin sind wie Tech Clouds oder so. Interessant, aber nicht zum Hauptinhalt gehörend. Und im Hauptinhalt drin könnte da zum Beispiel sein, ein Copyright-Hinweis oder so was gehört da halt rein, ist aber jetzt nicht sozusagen direkt an den Inhalt vom Blogpost gebunden.

Kann ich denn auch zwei asides definieren oder darf ich jeweils nur eine, einem Element zuweisen?

Das ist eine gute Frage. Das weiß ich gerade gar nicht. Aber ich denke mal, es müssten mehrere gehen. Es geht halt immer darum, es geht halt, kommt halt immer darauf an, um welchen Inhalt geht's? Ja. Es ist also zum Beispiel, auch bei Header und Footer, so: Normalerweise steht der Header ganz oben, normalerweise steht der Footer ganz unten. Das ist naheliegend. Das ist aber keinesfalls so vorgeschrieben, dass das so sein muss.

Wenn man aus irgendwelchen verqueren Gründen - mir fallen keine ein, aber falls es welche geben sollte -, warum die Reihenfolge umgekehrt sein sollte, dann ist das erlaubt. Es muss halt nur inhaltlich Sinn ergeben. Also was es dann noch Neues gibt, ist zum Beispiel das, Nav-Element. Klar, wofür das ist. Das ist halt für Navigationsblöcke. Damit kann man, sozusagen eine Gruppe aufmachen, der man, über die man aussagen möchte: Das ist eine oder das ist die Hauptnavigation.

Jetzt nicht jeder Fitzel-Link, der dann unten zum Impressum führt oder so was ist ein Nav, das muss nicht sein. Aber wenn's halt irgendwas Größeres navigationstechnisches ist.

Also klassisch die Haupt- und vielleicht noch die, die Subnavigation, oder?

Genau. Und wenn man dann im Footer noch irgendwo so drinstehen hat, was weiß ich, da ist die Datenschutzerklärung, da ist Impressum. Das dann eher nicht.

In der Praxis, wie würde das aussehen? Weil normalerweise habe ich ja meine UL mit meinen vielen LIs. Würde ich jetzt Nav noch, wahrscheinlich drum rum schließen, oder? Als Parenthesetech?

Genau so kann man, so würde ich das machen. Diese,, Elemente Article, aside, nav und section, das sind, diese vier Elemente s-sind es, die der auch mit diesen, diesen Überschriftenalgorithmus beeinflussen. Das heißt, es ist zum Beispiel auch immer ganz sinnvoll, diesen Abschnitten eine Überschrift zu verpassen. Im Fall von Nav wäre halt die Überschrift, was weiß ich, Navigation ganz sinnvoll. Man muss diesen auch immer keine Überschrift geben. Es ist halt nur immer ganz, ganz nett.

Sonst tauchen die nämlich in der Outline als leere Abschnitte auf, was erlaubt ist. Aber man muss halt immer gucken: Ergibt das alles immer Sinn?

Wollen wir vielleicht mal ganz kurz an am Beispiel eines klassischen Blogs mal, von oben nach unten durchbesprechen, was so wie verschachtelt wäre, damit man das noch mal so ein bisschen plastisch vor Augen hat.

Das können wir gerne machen. Ich hab auch, das kann ich ja, an der, Stelle mal sagen, so ein Beispiel wird auch im Buch durchexerziert in zwei Varianten: in der reinen HTML5, leere Variante und in der abwärtskompatiblen Variante, was wir schon erwähnt haben, wo man dann noch die Überschriftenelemente außer H1 verwendet. Und das gibt's auch, dieses, Beispiel auf der, Seite zum Buch HTML5buch.de, zum Download. Die Codebeispiele zum Buch sind das. Da ist das drin.

Aber wenn wir das mal eben durchexerzieren wollen, können wir das gerne machen. Also beim Blog würde ich mal sagen, wir fangen an mit einem, Kopfbereich für das Blog. Hm, ist klar, Kopfbereich nehmen wir ein Header-Element für und packen wir eine Überschrift rein mit einem H1-Element: das HTML5-Blog. Damit ist dann, denke ich mal, der Kopfbereich des Blogs versorgt. So, zweites brauchen wir eine Navigation fürs Blog.

Packen wir in dem Fall direkt unter das Header-Element, und nehmen da einfach eine UL mit Navigationspunkten li, li, li mit Link, Link, Link. Da ist dann halt die Frage: Will man diesem, Nav-Element – das ist ja, wie wir gerade gesagt haben, eins von diesen strukturierenden, was eine eigene Sektion aufmacht – eine Überschrift geben, um dem halt, zu sagen: „Pass auf, du bist die Hauptnavigation." Da ist halt die Frage: Will man das? Will man das nicht? Macht das vom Inhalt her Sinn oder nicht?

Wäre für Screenreader auf der einen Seite vielleicht hilfreich, auf der anderen Seite hat es ja schon das Nav-Tag und, insofern ja schon irgendwie sowieso die Bedeutung einer Navigation.

Genau, es ist halt die Frage. Also ich denke mal, das wäre zumindest mal sinnvoll, wenn's mehrere Nav-, Elemente auf einer Seite hat. Dann soll, dann spätestens dann sollte man das machen. Aber-

Einigen wir uns darauf, ja.

Man muss immer gucken, wie, wie sollte man das so, machen? Also was, was, was ist der Inhalt? Es geht halt eben hier wirklich immer um den Inhalt und der Inhalt diktiert, was wir drum packen und, irgendwelche in Stein gemeißelten Regeln haben wir hier eher nicht. So, Kopfbereich steht, Navigation steht. Jetzt brauchen wir unsere Hauptspalte für unser Blog. Die Hauptspalte ist eine, Sektion, ohne dass die jetzt näher mit einem Zweck definiert wäre.

Also nehmen wir einfach ein Section-Element und in diese Hauptspalte packen wir mehrere, Blogposts. Und diese Blogposts würde sich natürlich anbieten, dafür das Article-Element zu nehmen. Wir erinnern uns.

Für jeden Post ein einzelnes Article-Element.

Genau. Jeder Post ist eine in sich geschlossene Geschichte. Die kriegt eine Überschrift. Wir können in diesem Fall auch wieder eine H1 nehmen, weil das durch diese Section und den Artikel in die entsprechende Ebene passend reingerückt wird. Da brauchen wir also nicht mit einer H2 oder so was rumzuhantieren. Da können wir Text reinpacken und dann, Metainformationen hatten wir ja gesagt, das Aside-Element kann man dafür nehmen.

Nehmen wir halt eins Aside-Element und packen da rein:, dieser Blogpost wurde geschrieben am soundsovielten.

Nur kurze Erklärung: Wenn ich jetzt eine, wenn ich jetzt mehrere Headlines hätte, beispielsweise bei der Technikwürze, haben wir die eine Headline Technikwürze meinetwegen hundertachtundsechzig und, die Hauptheadline Google I/O. Das würde ich dann aber schon mit einer H1 und einer H2 machen.

Das würdest du so machen, dass die Überschriftenhierarchie aus der Kombination von verwendeten H-Elementen und den Sektionierungselementen einen Sinn ergibt. Also nicht vergessen, jeder-

Kannst du das praktisch erklären?

Es ist mir nicht ganz so leicht gefallen, das in dem Buch zu tun. Es ist am besten wirklich, man, -

Kauft endlich dein Buch und-

Ja, entweder das natürlich oder man, man, man, man sollte halt wirklich ein bisschen mit diesem Outliner herumspielen. Also es ist halt wirklich so: Wenn man eine, ein Section-Element hat und darin eine H1 schreibt, ist das klar: Überschrift erster Ordnung. Wenn man unter dieser H1 noch ein Section-Element macht und da wieder eine H1 reinschreibt, dann ist das eine Überschrift zweiter Ordnung, obwohl H1. Warum? Neues Section-Element ist ein neuer Kontext des Ganzen.

Dem also wieder untergeordnet.

Aber ich würde ja jetzt nicht unbedingt eine neue, eine neue Section machen, nur aufgrund dessen, dass ich, meine Headline mehr oder weniger optisch so ein bisschen auch semantisch trennen möchte, oder?

Genau, wenn du die Headlines trennen möchtest, dann haben wir nämlich auch noch eine ganz lustige Option. Wir können die aber beim Block einbauen. Angenommen, wir hätten jetzt einen Blogtitel, wir hätten einen Blog, das heißt jetzt „Das HTML5-Blog". Und der Untertitel ist, bob, bob, bob, ein weiteres tolles Blog über HTML5. Nehmen wir das mal an.

Das ist ja zum Beispiel beim, lass mich nicht lügen, also so manches WordPress-Theme macht das, glaube ich, so: Das erste ist eine H1, das zweite ist eine H2. Ist ja nicht unüblich. Kann man drüber streiten, ob das sinnvoll ist. Manchmal möchte man das so machen. Das kann man auch weiterhin mit HTML5 so machen, weil die ganzen, Überschriftenelemente außer H1 ja immer noch da sind. Die sind auch nicht irgendwie jetzt als veraltet oder so, gebrandmarkt.

Die gibt’s weiterhin und das könnte man sogar drunterschreiben. Wenn man aber jetzt zum Beispiel das verwenden möchte, um das so auszudrücken: Das ist eine Überschrift, das ist auch eine Überschrift, aber eine Unterüberschrift, also nicht so wichtig, kann man Folgendes machen: Man kann, die Überschrift geringerer Ordnung, also in diesem Fall die H2, aus der Outline, das heißt diesem berechneten, dieser berechneten Überschrift-Hierarchie heraushalten. Es gibt ein Element, das, H-Group-Element.

Da kannst du mehrere, ja kann man mehrere Überschriften, reinstecken und in der Outline kommt letztlich nur das an, was die höchste Ordnung innerhalb dieser Liste hat. Wir hätten also ein H-Group-Element und da hätten wir drin eine H1, eine H2, eine H3, eine H4. Käme in der Outline nur die H1 an, der Rest würde verschluckt. Für solche Konstruktionen ganz praktisch, macht aber alles viel komplizierter.

Da, so hört sich das auch schon an. Lass uns mal weiter im Text springen. Wenn ich, das richtig im Kopf hab, waren wir bei der Inhaltsspalte und die ist eigentlich auch so weit dann fertig mit den einzelnen Posts, oder?

Genau, wir haben die mit, Artikelelementen gefüllt, mit Überschriften und Text drin und einem Aside-Element für die Metainformation. Also Informationen, die jetzt nicht unbedingt dazugehören zu dem, sonstigen Inhalt der, der Spalte, halt so ergänzender Natur sind.

Datum, Autor.

Genau so was. Würde ich machen. Man kann sich drüber zanken, wie man das Aside-Element genau einsetzt. Dann würde ich sagen, können wir unsere Hauptspalte zumachen. Also Section-Element schließen und dann haben wir die Seitenspalte des Blogs. Und in den meisten Blogs ist es dann ja wirklich so, dass die Seitenspalte solches Material enthält, das auch in diesem Fall wieder nur, begrenzt mit dem, mit dem Hauptinhalt zu tun hat. Eine Tag-Cloud oder eine Blog-Scroll oder so was.

Da würde sich halt dann wieder anbieten, das Ganze in ein eigenes Aside-Element zu packen. Und innerhalb dieses Aside-Elements könnte man dann die einzelnen, Inhalte, Blöcke, also die Tag-Cloud und die Blog-Roll auch voneinander trennen. In dem Fall würde ich sagen, dann würden sich Section-Elemente anbieten, weil es nicht wie die Artikel-Elemente in sich geschlossene Sachen sind, aber eben schon eigene Inhaltssektionen jeweils.

Stück für Stück machen wir ein paar davon, machen das Aside-Element wieder zu. Haben wir noch den Blog-Footer, nehmen wir ein Footer-Element, schreiben rein Copyright soundso, machen es zu und sind fertig. Alles ganz normal wie beim, bei HTML4, nur dass wir hier halt statt Div, Div, Div, Div und noch mal Div eben Elemente verwenden, die ein bisschen was darüber aussagen, was das Einzelne jeweils halt ist. So einfach ist das.

Das Ding ist halt, weil wir jetzt überall nur H1-Überschriften verwendet haben, würde halt ein Programm, das das verarbeitet, was von HTML5 nichts weiß, wie zum Beispiel der Google Bot, dem unterstelle ich das jetzt einfach mal, ohne das jetzt mittlerweile noch mehr genau zu wissen. Meine Recherche ist etwas her. Für den wäre es halt alles eine, eine Seite voller unsortierter H1-Überschriften. Das wäre ein bisschen blöd.

Und deswegen kann man Folgendes machen: Man kann, diese, Struktur mit den Sektionselementen so bauen, aber die Überschriftenordnung, so bauen, als wären es eben weiterhin, ganz normale alte Divs. Man würde also bei unserem Blog-Beispiel machen: Eine H1, das HTML5-Blog. Der Untertitel H2, ein weiteres tolles Blog über HTML5. Navigation, Navigation und dann kommen wir zu den Artikeln. Dann würde man in unserer Situation wahrscheinlich H3-Elemente normalerweise nehmen. Können wir auch hier machen.

Das ist kein Problem. Die Überschriftenzählung innerhalb eines solchen Sektionselements muss nicht mit H1 anfangen. Die kann auch mit H5 anfangen, wenn man lustig ist. Dann gehen einem natürlich auf lange Sicht irgendwann innerhalb dieses Elements die Überschriften aus, wenn man mit H5 anfängt, aber man kann das machen.

Der gute Effekt dabei ist, das ist sowohl nach dem Outline-Algorithmus her, eine richtige Ordnung Weil der halt, wie gesagt, es erlaubt, dass wir auch mit anderen Überschriften als H1 anfangen und es ist auch, richtig nach der Verarbeitung, nach der Verarbeitung der Seite durch ein Programm, was eben kein HTML5 kann. Man macht also beides sozusagen. Der einzige Nachteil ist halt, dass man dann wirklich nur wie früher auch die Überschriften eben in H1 bis H6 hat und keine weiteren.

Aber, wahrscheinlich ist das bei den meisten Blogs etwas, womit man leben kann.

Ich denke auch.

Da stößt man hoffentlich selten auf, auf Probleme.

Das klingt jetzt auch alles wesentlich komplizierter als es ist. Wenn man das erst mal zweimal gemacht hat, dann, geht das ganz locker und es ist ganz prima und, super.

Ich denke, dazu werden wir bestimmt auch noch irgendwo 'ne hübsche Grafik finden, die das dann so mal so ein bisschen verschachtelt zeigt und das ist dann vielleicht auch ein bisschen einfacher zu begreifen.

Also ich will, ich würde wie gesagt ganz einfach mal, ich würde das, ich würde dieses, Blogbeispiel von der HTML5-Buchseite runterladen, daran rumspielen und das immer wieder durch diesen Outliner durchjagen.

Genau den Link zu deiner Seite haben wir natürlich auch verlinkt.

Genau. Und, irgendwann macht es dann also so was bei mir Klick. Aha, so läuft das und dann hat man's drin und das läuft.

Okay, dann lass uns doch noch mal auf die, Elemente als solches kommen, nämlich, die Schreibweise. Wie schreibe ich die Elemente? Stichwort HTML5 versus XHTML5.

Genau. Also ich hab ja vorhin gesagt-

Was ja, was ja im ersten Augenblick ganz komisch, klingt, weil wir am Anfang der Sendung gesagt haben, XHTML2 ist ja tot.

Genau. XHTML, ganz wichtig XHTML2 ist tot. XHTML5 gibt's aber weiterhin. Jetzt ist die Frage, wo finde ich die Spezifikation dafür? Die Spezifikationen zu XHTML5 sind die Spezifikationen zu HTML5. Hat folgende Bewandtnis: Das, was ha, die HTML5 Spezifikationen eigentlich beschreiben, ist, das abstrakte Konstrukt, also der DOM Tree, den ein Browser erzeugt, wenn er HTML oder XHTML verarbeitet.

Das heißt, die, HTML5 Spezifikationen spezifizieren das Endresultat dessen, was man schreibt, nachdem es durch den Browser gejagt wurde. Und man kann dieses Endresultat erreichen, indem man entweder HTML5 oder XHTML5 schreibt. Wichtig ist dabei XHTML5 ist echtes XHTML, wie es XHTML2 gewesen wäre. Das heißt, mit allen schönen,, dazugehörigen Sachen wie zum Beispiel kleinster Tippfehler ist Seite unbrauchbar. Der Internet Explorer kann's nicht. Man darf kein document.write verwenden. All das.

Ob das sinnvoll ist, sei dahingestellt. Aber das gibt es halt. Wer das möchte, kann das verwenden.

Empfehlung des Fachmanns?

Ich, pff, ja, w-warum sollte ich das irgendwem ausreden wollen? Aber warum?

Okay, alles klar. Also du würdest die HTML5-Methode schreiben, also w-wie HTML4 quasi.

Jein, das ist kompliziert. Also erst mal nur wirklich XHTML5, das muss man wirklich noch mal sagen, ist echtes XHTML. Das braucht, das ist also XHTML, nicht XHTML1, das ist kein XHTML, das ist HTML, das sich als XHTML getarnt hat.

Dementsprechend hoch absturzgefährdend.

Ja, also wie gesagt, echtes XHTML, das heißt echtes XML. Also, das Dokument muss wohlgeformt sein, sonst fliegt einem das um die Ohren. Der Internet Explorer, kein Internet Explorer, egal welchen Trick man aus dem Hut zaubert, kann das verarbeiten. Das geht nicht. Man muss 'ne XML-Deklaration drüber schreiben und man kann den DOCTYPE weglassen. Man muss den Namespace definieren und also es ist echtes XHTML. Das hat warschein, haben wahrscheinlich die wenigsten, je geschrieben. Warum auch?

Der Internet Explorer kann's nicht verarbeiten. Ist relativ nutzlos. Man will das meistens nicht machen, glaube ich. Macht nur Probleme.

Ja, ja.

Im, im HTML.

Ich hatte es mal ausprobiert,, echtes auszuliefern und, hab gemerkt, wenn dann doch mal irgendwie 'n Redakteur dabei ist, der vielleicht ein bisschen Unsinn schreibt in seinen What-you-see-is-what-you-get-Editor, dann fliegt die Seite um die Ohren und nichts geht mehr. Und, das, macht keinen Spaß.

Ja, also es kann natürlich insofern sinnvoll sein, wenn man irgendwelche XML-Daten hat und die einbetten möchte oder die transformieren möchte in... Aber das ist wirklich, sind sehr spezielle Use Cases immer. Für das Wald- und Wiesenblog sollte, da sollte man davon weit Abstand nehmen, es sei denn, man hat wirklich einen ganz extremen Hass auf den Internet Explorer. U-u-und sehr großes Vertrauen in seine eigenen Fähigkeiten, keine Tippfehler zu machen.

Also kommen wir doch zu der, zu der Schreibweise, die noch offen ist. Wir nehmen HTML5, schreiben es aber wie XHTML.

Genau, das ist jetzt so die Frage: Wie schreibt man HTML5? Die, Syntax von dem, was im Moment State of the Art ist, XHTML1 ist ja relativ fest. Da gibt's nicht viel Varianz. Das kann man nur, das kann man eigentlich nur richtig schreiben. Alle Attribute, ausschreiben und alle Tags schließen. Solche Sachen. Das kann man in HTML5 auch so machen. Man kann's aber auch anders machen. Man kann es so schreiben wie HTML4. Da braucht man zum Beispiel, einige Tags nicht mehr zu schließen.

Man kann zum Beispiel den, Body-End-Tag offen lassen. Das ist kein Fehler, das ist so erlaubt. Der Parser fügt den dann automatisch ein. Man kann auch den Body-Anfangs-Tag weglassen, wenn man lustig ist. Man kann zum Beispiel, Attribute wie zum Beispiel das disabled-Attribut bei einem Formularelement, einfach so als Bullets-Attribut reinschreiben. Man muss nicht mehr schreiben disabled gleich, disabled.

Da hast du, da hast du, in deinem Buch auch das eine oder andere Beispiel gebracht, was schon eher nach einer Verschlüsselung des Codes aussah als, nach noch irgendwas wirklich Sinnigem. Aber es hätte funktioniert.

Genau, es, es würde funktionieren, es wäre gültig. Es ist halt so ein bisschen die Frage: Was will man? Und, wie hält man das durch? Das Problem ist nämlich der HTML5 Validator, so wie er im Moment ist, lässt alles durch. Das heißt, man kann jetzt beispielsweise sich die, sich das Ziel setzen, ich schreibe jetzt, Code, der wäre auch valides XHTML, weil ich weiß ja nicht, ob das nicht eines Tages aus dem Grabe emporsteigt. Ist ja, 'ne sinnvolle Überlegung, das so zu machen.

Dann, ja lässt der HTML5-Validator aber auch Sachen durch, die halt kein valides XHTML wären, weil eben die Syntax da ein bisschen mehr zulässt..

Das Ganze ist wahrscheinlich eher was, um das, vielleicht später durch irgendeinen, Quellcode-Optimierungstool laufen zu lassen, was das Ganze dann ein bisschen ausdünnt, oder?

Ja, pff, ich bin mir nicht so ganz sicher. Also es wird wahrscheinlich irgendwann mal jemand ein Tool erfinden, mit dem man sich einstellen kann, welche Syntaxregeln man haben möchte. Also ich zum Beispiel, meine Ansicht ist, ich find das ganz klasse, wenn man jedem immer jedes Element zumacht. Das schafft klare Verhältnisse, da muss man nicht nachdenken und nachdenken mag ich nicht.

Aber andererseits, ich versteh nicht so ganz, warum ich bei einem Formularelement immer schreiben muss disabled gleich disabled. Das ist ja doppelt gemoppelt. Wenn ich was schreibe, lass ich das zum Beispiel gerne weg.

Sagen wir so, deine Schreibweise, deine, deine persönliche ist, dass du Listenelemente, die list zum Beispiel immer schön gerne schließt und, Sachen wie disabled, die lässt du nur einfach stehen.

Genau, man kann sich's aussuchen. Das ist halt eigentlich, wenn man alleine arbeitet, auch ganz schön. Nur wenn man dann irgendwie ein Team aufmacht, muss man wahrscheinlich entweder irgendwie Regeln festlegen oder so. Ist halt schwierig. Bei XHTML1 ist es ganz einfach. Da werden halt die Regeln definiert durch das, was halt erlaubt ist und das ist nicht viel und das ist auch eigentlich ganz gut so.

Also was zum Beispiel auch 'n Aspekt ist zum Beispiel, man kann, man kann, wenn man jetzt wirklich der absolute Speedfreak ist, ja ein ganz minimiertes HTML schreiben, ganz kleine Dateien, weil man ja alles wegoptimieren kann, was nicht zwingend gebraucht wird.

Ja, das, das meinte ich grad eigentlich mit den, mit den, da kommen dann bestimmt irgendwann Tools, die das für einen halt machen.

Genau, es ist ja auch keine schlechte Idee. Was die, was das Web schneller macht, ist ja schön. Also da gibt's sehr viel, Variationsmöglichkeiten. Ich würd einfach sagen, im Zweifelsfall so schreiben, als wär's XHTML1. Dann kann nichts schiefgehen.

Kommen wir zur Schnittstelle zwischen Mensch und Maschinen, nämlich den, Formularen, in dem wir schön was eintippen, denn da gibt es auch 'ne ganze Menge Neues in HTML5. Erzähl uns doch mal, was wir denn da Neues haben.

Also wir haben im Prinzip zwei, große Blöcke von Neuerungen bei den Formularen. Wir haben einerseits ein paar neue, Typen von Eingabefeldern und wir haben andererseits 'ne eingebaute Validierungsschnittstelle. Das, Ganze ist jetzt hauptsächlich, in Opera schon zu, zu begutachten. Der ist da der Vorreiter. Bei den anderen Browsern mehr so weniger. Chrome halb, Safari teilweise und im Firefox ist das Ganze noch gar nicht vorhanden.

Aber, das ist schon etwas, wo man, auch HTML5 schon heute gewinnbringend einsetzen kann, ohne irgendwem anders, den Spaß zu rauben. Also irgendwer anders ist ja klar, das ist ja meist der Internet Explorer und, der kennt natürlich nichts von all dem. Der hat noch nie was von HTML5-Formularen gehört.

Das macht aber nichts, weil das Tolle ist, wenn man dem Internet Explorer oder auch sonst irgendwelchen anderen Browsern ein Formularelement, also ein Input vorsetzt, von dem er noch nie was gehört hat, dann sagt er sich einfach: „Okay, kenn ich halt nicht. Machen wir 'n Textfeld draus." Und das ist ja eigentlich 'ne relativ sinnvolle Sache, weil, 'n Textfeld ist eigentlich nie falsch. Nehmen wir mal an, wir hätten 'n Datumselement. Das gibt's in HTML5, 'n Datepicker. Input type date.

Da klickt man dann drauf. Opera gibt einem da so ein schönes Ding aus, wo man sich was auswählen kann. Das würde man sich ansonsten mit irgendwelchen JavaScript-Lösungen zusammenbasteln. Da ist es halt direkt eingebaut. Das würde halt 'n Opera-Nutzer so ausfüllen können mit diesem Element.

'N Internet Explorer-Nutzer, hätte das Teil zwar nicht, aber dann könnte man einfach drunterschreiben: „Pass auf, gib das Datumsformat in diesem oder jedem Format.", es gibt 'n HTML5-Datumsformat, kann man drunterschreiben. Gib das hier in dieses Textfeld ein und dann ist fertig. Und dann können beide das Formular ausfüllen. Nur der Opera-Nutzer hat's halt 'n bisschen leichter.

By the way, gibt es da schon internationale, Datumsformate oder nur das Englische?

Es gibt ein, festgelegtes bei HTML5, was man da verwenden soll. Es gibt auch die Möglichkeit, diese, also beim Datum ist es so, das kann man sich, das kann man über 'ne JavaScript API aus dem Formularelement, glaub ich, auslesen und sich zurückgeben lassen als, Datumsobjekt oder als Timestamp. Bin mir jetzt nicht grad sicher, ob beides oder nur eins von beiden. Und das kann man dann jedenfalls weiter bearbeiten. Das heißt, worauf will ich hinaus? Es gibt 'n festgelegtes, ja.

Okay, aber das wäre ja in diesem Fall eh nur für den, für den Fall relevant, dass irgendwer das ansurft, der halt eben das nicht hat. Und man kann ja auch Folgendes machen:, diese Umwandlung in ein Textfeld passiert komplett. Der hat also nachher in seinem DOM-Tree nicht drinstehen: „Pass auf, ich bin ein Input vom Type date", sondern der hat da wirklich drinstehen: „Ich bin ein Input vom Type text." Das heißt, man kann das abfangen.

Man kann also gucken, hat das Element mit der ID so und so, wenn die Seite geladen ist, den Typ so und so. Wenn nicht, haben wir erstens festgestellt, aha, hier ist jemand mit 'nem alten Browser unterwegs und wir können ihn auslachen. Und, zweitens, wir können, darauf reagieren.

Wir können dann zum Beispiel sagen: „Ja gut, wenn du keinen HTML5-fähigen Browser hast, dann laden wir eben unsere Formularbibliothek mit jQuery oder so was nachträglich in die Seite rein und wandeln das in einen Datumspicker alter Schule um. Wenn man darauf unbedingt angewiesen ist, dann kann man das so handlen. Es gibt 'ne ganze Reihe von neuen Formularelementen, also zum Beispiel für so ganz einfache Sachen, wie zum Beispiel für, für Zahlen. Da hat man 'n ganz normales Textfeld.

Man kann da auch, wenn man lustig ist, andere Sachen eingeben, nicht nur Zahlen, man kann da auch Buchstaben reintippen. Aber man hat daneben so zwei kleine Buttons, mit denen man so rauf und runter zählen lassen kann. Man kann seitens des HTML festlegen, in welchen Schritten das passieren soll, also immer eins rauf, eins runter oder null Komma fünf oder was auch immer. Man kann Maximal- und Minimalwerte definieren und halt so was.

Man kann da also richtig schöne Formulare zusammenbauen, ohne dass man da irgendwie externe JavaScript-Bibliotheken oder so was bräuchte.

Kurze Zwischenfrage meinerseits: Ist, die Validierung, auf die wir gleich sicherlich noch zu sprechen kommen, fest...

Auch in den Spezifikationen festgehalten oder macht das dann jeder Browser, wie er sich das so vorstellt? Weißt du das?

Nee, das, das ist in den Spezifikationen, festgehalten. Also das hat, machen wir direkt da weiter. Also das hat, zwei Aspekte: Die kann einmal automatisch aktiv werden. Das heißt, wenn gewisse Bedingungen zutreffen auf ein Formularelement. Es ist also einem Formular zugeordnet, es hat einen Namen und da gab's noch eine dritte, Bedingung, die mir grad nicht einfiel.

Also irgendwie, wenn's halt so das, das normale Wald- und Wiesenformular ist und man klickt auf Absenden, dann ist der Normalfall, dass der Browser halt, sofern er diese API unterstützt, vorher durch diese ganzen Elemente durchgeht und die validiert. Validieren heißt einerseits, dass einige Elemente eingebaute Validierungsmechanismen haben. Ein Input vom Type number würde zum Beispiel nur Zahlen erlauben. Ist ja klar.

Man ist nicht davon abgehalten, da was anderes einzutippen, aber man wird halt nicht zum Abschicken durchgelassen. Es gibt auch 'n Input vom Type E-Mail, wo man halt eben nur E-Mail-Adressen eintippen kann. Da wird halt wirklich so die Syntax geprüft. Ist, kommt da ein @ drin vor und all so was. Also das, das was man so für den Hausgebrauch eines Formulars, für die Validierung und so haben will, das ist da alles direkt mit drin.

Und man kann die Validierungs-API auch erweitern, indem man zum Beispiel sagt: „Dieses Feld ist 'ne Postleitzahl und da will ich jetzt, da hab ich jetzt meine schöne, meinen schönen regulären Ausdruck und den will ich da einbauen." Dann gibt's 'n HTML-Attribut, das nennt sich Pattern, da schreibt man sein Regex rein und dann wird automatisch geprüft beim Abschicken. Man kann auch einfach 'n ganz normales Textfeld als Pflichtfeld deklarieren.

Also man hat da ganz viele Möglichkeiten und das deckt, alles ab, was das Herz begehrt. Es gibt nichts, was man damit nicht machen kann. So, Frage: Warum sollte man das so machen wollen und nicht mit, mit irgend 'ner Sache jQuery, was weiß ich?

Es ist deutlich nativer.

Und läuft in wesentlich weniger Browsern. Nein, der große Vorteil ist, der große Vorteil ist der: Man hat es ja meist, mit, mit Standardproblemen zu tun bei der Formularvalidierung. Das ist keine E-Mail-Adresse oder das ist keine Zahl oder was auch immer. Warum sollte man, – das Problem ist dann meist, also die Sprache, ja. Irgendwer kommt mit einem Browser vorbei, der ist auf Chinesisch und wir haben hier 'ne deutsche Fehlermeldung.

Okay, wahrscheinlich jetzt nicht so der häufige Fall, aber so was in der Art könnte ja vorkommen. Und das Gute ist, dass der Browser und die Validierungs-API, auf die Lokalisierung des Browsers zurückgreift. Das heißt, wenn wir hier das Problem haben, dieses E-Mail-Feld wurde in der falschen Syntax ausgefüllt mit unserem chinesischen Browser, dann kriegt unser chinesischer Benutzer die chinesische Fehlermeldung, dass da 'ne E-Mail rein muss.

Das heißt, ich muss mich um, Fehlertexte nicht unbedingt selbst kümmern. Kann ich es denn?

Du kannst es, wenn du,, erstens kannst du die Fehlermeldung, glaube ich, alle überschreiben, wenn ich mich recht entsinne. Und zweitens kannst du auch ganz eigene Fehlerbedingungen, erstellen. Du kannst einfach sagen, nehmen wir an, wir hätten zwei verschiedene, zwei Felder, in denen man zwei Zahlen eingeben muss und diese zwei Zahlen müssen verschieden sein.

Dann kannst du an, diese Felder 'ne Validierungsbedingung dran knüpfen, die guckt, ist in dem anderen Feld, 'ne andere Zahl eingetragen oder ist es die gleiche und dann kannst du darauf entsprechend reagieren mit 'ner ganz simplen JavaScript-Funktion.

Also eigentlich 'ne relativ coole Sache. Lass uns noch mal auf CSS zusprechen kommen. Vielleicht-

Sehr schön, sehr schön, sehr schön. CSS.

Das ist ja 'ne super, ein Superübergang.

Nee, weil ich, ich, ich liebe, ich liebe das, ich liebe das Element, das, das neue, Formularelement Search. Das, hat keinerlei Funktion. Das sieht, fast aus wie ein Textfeld mit einem Unterschied: Es sieht aus wie ein Textfeld, das im Betriebssystem des Browsers ein Suchformular wäre. Das heißt, wenn jetzt also ein, sagen wir mal, ein Mac-User daherkäme mit Safari, dann hätte das Suchfeld, wenn ich mich recht, entsinne – ich nutz das ja nicht so häufig – aber so 'ne kleine Lupe da drin.

Und du hättest ein Search-Feld, das würde genauso aussehen wie dieses Lupenfeld im ganzen Betriebssystem. Das wäre einheitlich. Und du kannst nichts dagegen tun. Wenn du dem einen roten Rand geben willst, wird das nicht funktionieren. Es hat keine weitere Funktion außerhalb diesen, diesen Style zum Beispiel durchzuziehen. Ist das nicht klasse?

Ja und nein. Es kommt natürlich darauf an, wenn ich eine schwarze Seite statt eine weiße mache oder andersrum, dann wird's natürlich schon schwieriger. Aber grundsätzlich ist das natürlich zu begrüßen, ja.

Ja, es ist nett, dass es so was gibt.

Magst du uns vielleicht noch zwei, drei Takte zur, Fehlerbehandlung bezüglich CSS sagen?

Also man kann natürlich, wenn ein Fehler im Formularfeld auftaucht, darauf auf zweierlei reagieren. Man könnte da jetzt natürlich theoretisch hingehen und dem sagen: „Pass auf, du kriegst jetzt 'ne Klasse Error", und dann wird das rot angezeigt. Es gibt aber tatsächlich auch, 'n paar CSS-Pseudoklassen, die das übernehmen.

Das heißt, ein, Formularfeld, was eine wie auch immer geartete, nicht gültige Eingabe hat und das wurde validiert und für nicht gültig befunden, kann man, per CSS über eine CSS-Pseudoklasse ansprechen, die invalid heißt. Das geht auch noch 'n bisschen spezifischer. Man kann zum Beispiel auch speziell, Formulare ansprechen, die, bestimmte Bedingungen, gegen bestimmte Bedingungen verstoßen. Also zum Beispiel nehmen wir 'n, ein Input vom Type number wieder, wo man nur Zahlen eingeben kann.

Da kann man ja ganz viele Sachen mit falsch machen. Man kann 'ne Zahl eingeben, die zu hoch ist, die zu niedrig ist, die eine Kommazahl ist, obwohl's keine sein sollte und man kann da meinetwegen auch einfach 'n Text reinschreiben statt Zahlen. Und das alles kann schiefgehen. Und das alles kann man erstens mit der Validierungs-API Stück für Stück abfangen, wenn man möchte.

Wenn man nicht möchte, kann man einfach sagen: „Das Feld ist falsch ausgefüllt, mach das gefälligst richtig." Und man kann auch über diese Pseudoklassen teilweise ganz prä-präzise ansteuern:, welcher Fehler liegt da vor? Ist es einfach nur ungültig wegen 'ner ungültigen Eingabe oder ist da zu viel eingetragen oder ist da zu wenig eingetragen? Das geht halt alles.

Gibt es zu invalid auch das Gegenstück valid?

Gibt es auch.

Um das Ganze dann so hübsch grün zu färben, wie das ja jetzt sehr in Mode ist.

Genau, kann man machen. Also schon, so, so in dem Moment, wo man die Taste gedrückt hat, die die Eingabe gültig werden lässt, ab dann wirkt dann sofort diese Pseudoklasse. Und da kann man dann sofort draufspringen und, darauf eingehen.

Man kann im Übrigen, was vielleicht auch ganz nett ist für irgendwelche komplette komplexeren, Bestellprozesse oder so was: Also wirklich, diese Validierungs-API, die geht zwar automatisch und in den meisten Fällen wird man die wohl auch so nutzen wollen für Otto Normalverbraucher Kontaktformular oder so was, aber man kann die auch wirklich ganz präzise steuern.

Man könnte zum Beispiel ein langes Bestellformular, was aus mehreren Fieldsets besteht, Fieldset für Fieldset validieren. Das heißt, wenn sich dann zum Beispiel ein Nutzer also durch den Bestellprozess durchtabbt, zack, zack, zack, dann kann man jedes Mal, wenn er ein Fieldset verlässt und ein neues reingeht, das alte prüfen und dann gegebenenfalls ihn zurückhalten.

Nicht, dass er dann den ganzen Bestellprozess, das fünfseitige Ding bis zum Ende ausfüllt und dann wieder von vorne anfangen muss, weil er ganz am Anfang was vergessen hat.

Du hattest, anfangs gesagt, dass die Unterstützung noch nicht besonders weit ist. Also, der, der, Date Picker zum Beispiel funktioniert, wenn ich das richtig im Kopf habe, bisher nur in Opera. Also dass dann, dass dann halt auch was Vernünftiges aufgeht. Wie ist das mit der Fehlervalidierung? Also kann ich davon ausgehen, dass alle außer der IE, wie halt so oft, in der aktuellen Version mit meiner Validierung dann umgehen können?

Oder und ist es dann halt wirklich nur, dass das kein Date Picker aufgeht und, der Nutzer dann halt das Datum händisch ins Textfeld tragen muss?

Der Firefox ist eigentlich der, der große Üble, wo ich ein bisschen enttäuscht bin. Der kann gar nix aus den, von den neuen Formularen. Also fast gar nichts. Es gibt noch ein paar esoterischere Sachen, worüber wir noch nicht gesprochen haben, Keegan zum Beispiel und solche Geschichten. Die kann der, aber so das, was man wirklich gerne haben möchte, das, das geht da alles noch nicht. Da ist noch, komplette Wüste. Der IE fällt natürlich auch raus. Die Frage ist: Ist das immer ein Problem?

Braucht man immer eine Live-Formularvalidierung im Browser oder ist es meist nur 'n Bonus? Ich will mal wieder unser, unser Blogbeispiel nehmen. Nehmen wir an, wir hätten so ein Blog-Kommentarformular wie bei der Technikwürze. Da könnte man jetzt hingehen und da könnte man sagen, ich unterstelle jetzt mal, das ist jetzt kein HTML5-Formular und das besteht aus, ein paar, Textinputs und 'ner Textarea.

Damit liegst du richtig, ja.

Gut, dann könnte man zum Beispiel hingehen und sagen: Bei, Website nehmen wir den, Input-Typ URL und bei E-Mail nehmen wir den Text, Eingabe, also den Textinput, E-Mail. Das würde, für jetzt jemanden wie mich, der mit dem Firefox unterwegs ist, keinen Effekt haben, weil ich merke ja nicht mal, dass hier ein anderes Feld ist. Wir erinnern uns: Unbekanntes, unbekannter Input-Typ resultiert in 'nem Textfeld in der Ausgabe. Ich merk das gar nicht. Ein Internet Explorer-Nutzer merkt das nicht.

Aber wenn jetzt zum Beispiel jemand daherkäme mit Opera und der würde das hier ausfüllen, der würde sich bei seiner E-Mail vertippen oder der würde statt Website, irgendwelchen Kapis eingeben, dann würde in dem Moment die Validierung aktiv, indem er auf Absenden klickt. Das ist also sozusagen als Bonus obendrauf konstruiert. Und worauf man ja nie wird verzichten können, ist die, serverseitige Validierung der Eingaben.

Gut, das ja, das ja sowieso nicht, weil Sicherheit bietet das ja insofern nicht, weil man ja locker einfach, wenn man die Kenntnisse dafür hat, dann am Dom rumschreiben, schrauben kann und dann ist halt fertig.

Genau, deswegen die Sache die:, auch hier kann man wieder dazu übergehen, dieses Feature der Formularvalidierung einfach so als Bonus mitzunehmen. Das wird noch nicht überall unterstützt. Mir doch egal. Dann haben halt nur die Opera-Server für den Moment, 'n angenehmeres Surferlebnis, weil die halt bei der Falscheingabe eher benachrichtigt werden. Der Rest muss halt wie bisher klarkommen. Was ja wohl auch irgendwie ging.

Zweierlei Dinge würde ich noch gerne einstreuen. Also zum einen klar bei 'nem Blog oder jetzt meinetwegen bei der Technikwürze-Seite, wo ja wahrscheinlich sowieso alle mit dem absolut aktuellsten Webkit unterwegs sind. Aber ansonsten, auf so privater oder ich sag mal Hobbyseite ist das vielleicht noch keinerlei Problem.

Wenn ich mir jetzt einen großen Shop, vorstelle und der sagt: „Okay, die, Fehlervali-Validierung funktioniert jetzt in keinem IE und in keinem Firefox, und erst nach dem Abschicken dann." Da geht's halt um, um bares Geld. Ich schätze, da ist es einfach in der Praxis noch nicht so weit, dass man, dass man sagen kann: „Okay, darauf verzichten wir dann.", das zum einen-

Kommt drauf an, Moment. Kommt drauf an, was ist der Ist-Zustand? Hat der Shop jetzt schon eine Formularvalidierung, eine-

Ja, natürlich. Also man kann's natürlich-

Ja, wenn er schon eine hat, dann wa-warum sollte man die ändern, ne? Never change running system. Aber wenn er noch keine hat, ist das halt, ist, ist sozusagen einfach der Umbau der Formulartypen ein geringstmöglicher Aufwand, um so was jetzt im Moment in wenigen, aber für die Zukunft in ganz vielen Fällen zu kriegen. Man muss nur einen Input-Typ austauschen, schon hat man die.

Natürlich. Also wenn's eigentlich gar nicht zur Debatte steht oder man, man nicht glaubt, dass man's wirklich braucht, dann ist das 'n, 'n, ja 'n, 'n schnell realisiertes, Feature über die neuen Input-Typen. Wenn man aber wirklich, sagt: „Okay, wir haben's zwar bisher noch nicht, müssen's aber jetzt einführen", dann ist das wahrscheinlich noch nicht so wirklich die Alternative.

Die andere Sache, die ich noch einführen wollte, ist, dass man natürlich auch darauf achten sollte und das Problem haben wir jetzt mit Java Script auch, dass die Fehlervalidierung, die man dann Backend-seitig im PHP oder was auch immer macht, am besten eins zu eins mit der übereinstimmt, mit der gleichen Logik, arbeitet, wie man das Ganze Frontend-seitig macht.

Ja, deswegen, einer der Gründe, warum wir alle, hoffen sollten, dass serverseitiges JavaScript so langsam mal in die Puschen kommt. Dann kann man einfach die Funktion nehmen und recycle.

Ja, oder halt, sowieso, wenn man schon Backend-seitig 'n eigenen Regex einsetzt, das Ganze dann, auch Frontend-seitig zu benutzen.

Ja, es ist, das ist immer auch ein bisschen riskant. Wir wissen ja, wie JavaScript ist und auch Regex. Es gibt ganze Blogs, die, die sich nur mit den Spezialitäten von JavaScript in der Hinsicht befassen.

Wollen wir vielleicht noch ein, zwei Typen, um das Thema dann auch abzuschließen, nennen, die es jetzt noch neu gibt. Also wir hatten bisher die E-Mail auf jeden Fall. Numbers, kann man da auch bestimmen, oder kann man bestimmt bestimmen, aber man kann dann auch bestimmen, ob das Ganze jetzt, Nachkommastellen haben soll, wie viele, wie getrennt und so weiter, oder?

Kann man alles festlegen. Einfach über HTML-Attribut. Min, Max. Step ist das Attribut, mit dem man festlegt, wie groß so die Schrittgröße ist, die da vorkommen darf.

Apropos Schritt, Größe: Range.

Genau. Range, Schieberegler auch sehr schön. Ist halt auch 'ne Eingabe von,, auf 'ner Skala zwischen zwei Zahlen mit dem Unterschied, man sieht halt nicht, welche Zahl es ist. Ist halt nun 'n Schieberegler halt.

Also das, was wir bisher nachgebaut haben mit jQuery und, anderen Geschichten.

Ganz genau das. Und auch hier wieder, Aria ist da eingebaut. Das ist also, da steckt direkt Information drin. Pass auf, das ist ein Schieberegler und der ist soundso steuerbar. Das ist da alles mit drin. Und zu guter Letzt, was mir noch spontan einfallen würde, wäre die URL. Die hatten wir, glaub ich, auch noch nicht.

URL, genau. Nur gültige absolute, URLs passen da rein. Also wenn man zum Beispiel relative URLs haben möchte, muss man dann, drüber nachdenken, ob man sich nicht eine eigene Validierungsregel baut. Ist wie gesagt ganz einfach., 'n RegEx in ein Attribut reinschmeißen und fertig. Gibt auch noch, gibt auch noch eins. Eins würde ich noch erwähnen. Das ist, das ist spannend.

Mach's am Schluss.

Das ist zwar auch noch zu,, zu, zu inkonsistent implementiert überall, um das wirklich zu nutzen, aber es gibt ein Attribut, Quatsch Attribut, ein, Input-Typ Keygen. Das ist ganz spannend. Das ist ein Schlüsselgenerator, mit dem man, da kann der Nutzer auswählen, wie stark möchte ich meine Verschlüsselung haben. Und dann wird an den Browser gesendet ein, öffentlicher Schlüssel und an den Server ein privater Schlüssel.

Und dann kann man mit diesen beiden Sachen serverseitig ein Sicherheitszertifikat erzeugen und dann hat man automatisch eine sichere Verbindung zwischen, Browser und Server, weil der Browser sofort aus seinem Schlüssel einen Server, eins, zwei, drei, ein klientseitiges Zertifikat angelegt hat. Das ist eine ganz spannende Sache, die, noch nicht wirklich irgendwo funktioniert. Aber natürlich kann man sich vorstellen, eine nette Sache.

Gibt's auch schon ewig lange, in unterschiedlicher Form und Ausprägung. Benutzt halt nur noch niemand, weil Internet Explorer und so, wir kennen das ja. Aber das ist, wirklich was, das, das, das fehlt der Welt noch.

Dann kommen wir mal zu einer Sache, die, im Gegensatz zu KeyGen schon hier und da an der einen oder anderen Ecke funktioniert und, in der letzten Sendung auch ein sehr großes Thema war: Audio und Video.

Das funktioniert. Das würde ich einmal zur Debatte stellen wollen.

Ah, ich hab gesagt, an der einen oder anderen Ecke.

Ja. Also bei Audio und Video, ganz, ganz normal erst mal zu erklären, ist ja ganz klar, es geht halt darum, Flash in die Tonne zu treten und irgendwie, eine möglichst schmerzfreie Möglichkeit herzustellen, Filmchen und Ton einzubinden. Und da haben wir halt einfach Audio-Video-Element. Das ist also wirklich Spitzklammer auf Audio, 'ne Quelle angeben, angeben mit Attributen, ob's automatisch abspielen soll oder nicht. Spitzklammer zu und fertig.

Beim Videoelement ist es die gleiche Geschichte und damit kann man dann in der Theorie ganz wirklich schmerzlos ohne Flash-Plugins und ohne dann aufheulende Notebooklüfter und so was, Filmchen abspielen oder Ton.

So viel zur Theorie. In der Praxis bedeutet das eher, dass wir, ziemlich umfangreiche Codekonstruktionen mit ganz, ganz vielen Fallback-Möglichkeiten bauen wollen, wenn wir das Ganze wirklich massenkompatibel umsetzen möchten.

Genau, weil hier haben wir nicht nur das Problem, dass der Internet Explorer nicht mitspielt. Das nehmen wir jetzt ja einfach mal so als gegeben hin. Sondern wir haben ja auch noch, die Unstimmigkeiten zwischen einzelnen Browsern. Und da geht's halt eben darum, was für Videos wollen wir überhaupt abspielen? Da gibt es die, eine Fraktion, die möchte Codec A und die andere Fraktion, die möchte Codec B und die beiden wollen ums Verrecken sich nicht einigen.

Und neuerdings gibt's jetzt noch die Fraktion mit dem Codec C, WebM.

Genau. Also wir können ja mal kurz die, die, Argumente aufrollen, die die jeweiligen, Seiten, zu Felde führen.

Ja, kurz.

Wir haben einerseits die kleinen Browserhersteller und, die Hersteller von freien Browsern. Das heißt also Firefox und Opera vor allen Dingen. Die haben einen freien Codec, also eine Sammlung von freien Codecs. Es geht ja immer um Audio- und Video-Codecs, aber alle reden aus für mich unerfindlichen Gründen immer nur von Video. Macht aber nichts. Die wollen also, Codecs verwenden aus dem OGG-Kosmos. Die sind frei.

Die Qualität ist halt so mehr mittel, aber, da hat man halt weniger Probleme mit irgendwelchen Lizenzgebühren oder Patenten. Ist die Theorie. Ob das stimmt, weiß man auch nicht. Dann haben wir die andere Fraktion. Das ist jetzt hauptsächlich Apple, die sagen: „Nein, wir haben unseren, quasi kommerziellen Codec. Der liefert bessere Ergebnisse, also nehmen wir doch den." Und, warum die sich nicht einigen wollen, ist klar.

Apple, möchte gerne sein Image pflegen als nur das Beste vom Besten und so weiter und so weiter. Aber natürlich kann ein Browser wie Firefox schlecht einen kommerziellen Codec in sich einbauen.

Ist deiner Meinung nach WebM jetzt die Zwischenlösung zwischen frei und gut?

Also WebM ist jetzt das neue Konstrukt, was Google ja kürzlich angekündigt hat, letzte Technikwoche, haben wir ja alle gehört, wo dann eben ein freier Codec von Google aufgekauft wurde und, der soll wohl gut sein und der wurde jetzt veröffentlicht, unter einer freien Lizenz. Ob das jetzt was wird, ist die Frage.

Okay, ist alles ein Blick in die Glaskugel im Moment, ja.

Ja, weiß ich nicht. Würde ich gar nicht so sehr sagen. Also die, die Frage ist halt die:, erstens, macht der Internet Explorer mit, beziehungsweise was macht der? Den können wir ja nun nicht aus der Welt schaffen. Früher oder später wird der das irgendwie unterstützen müssen, wenn wir das verwenden wollen. Und der hat sich schon auf die Seite der Kommerz-Codec-Leute geschlagen.

Er hat zwar gesagt, wir wollen den freien auch unterstützen, also diesen neuen WebM von Google, wenn der Browser, wenn der Nutzer ihn auf seinem Computer installiert hat. Das bedeutet so viel wie, das wissen wir alle, der wird nicht unterstützt. Weil wie hoch ist die Wahrscheinlichkeit, dass, weiß ich nicht, meine Mutter das Ding installiert hält, wenn sie mit dem IE durch die Gegend surft? Nix so hoch.

Kizu.

Ja. Und auf der anderen Seite, Apple hat sich noch gar nicht gemeldet. Ich glaube, die wollen keinen freien Codec haben, unterstelle ich denen. Die sind mit ihrer Kommerzlösung so zufrieden, dass das denen super gefällt.

Und antworten auch einfach nicht auf meine E-Mails.

Ja, ich glaube, sie antworten erst gar nicht und, alle dürfen wieder rätseln, was Apple da so vorhat.

Ja. Und dann noch die Sache im-

Steve, wenn du, wenn du grad zuhörst, lieber Steve, antworte doch mal bitte wir. Wir würden gern wissen, wohin die Reise geht.

Und außerdem scrollte an mir heute Morgen noch vorbei, dass da, Zweifel daran bestehen, ob WebM erstens, wirklich von allen Patentproblemen befreit, zweitens wirklich so gut ist, wie man sagt, und, drittens überhaupt unter einer freien Lizenz steht, die also wirklich kompatibel mit Mozilla und so was alles wäre.

Man kann also zusammenfassen, es wird auf jeden Fall nicht einfach. Ja.

Ja, also der, der, der Ist-Zustand ist ja der folgende:, man muss für jede mögliche, jedes mögliche Format, das irgendein Browser da draußen abspielen kann, exklusiv abspielen kann, ein eigenes Video vorhalten.

Also im Moment ist das, zum Glück, sind das zum Glück halt nur zwei Formate. Also das, für die Kommerzfraktion H264 und, das aus dem OGG-Kosmos für Mozilla und so weiter. Und wenn, wenn man die beiden vorrätig hält und da ein etwas Kompliziertes bastelt, was dafür sorgt, dass dann immer nur der Browser, der das kann, auch das Richtige geliefert bekommt und so, dann geht das einigermaßen. Und man muss eben noch eine Flash-Alternative zur Verfügung haben, um den Internet Explorer zu bedienen.

Wenn man jetzt so was baut, muss die Frage erlaubt sein:, nehmen wir doch gleich Flash und lassen's bleiben. Also ich, ich seh, ich seh da ehrlich gesagt relativ viel wenig Hoffnung, dass da überhaupt noch irgendwas draus wird, weil die, die a, können sich nicht einigen, die wollen sich meiner Ansicht nach auch nicht so wirklich einigen. Die Google-Lösung ist 'ne nette Idee, aber wenn da, Microsoft und Apple nicht wollen, dann werden die das nicht einbauen.

Ich glaub, das wird viele interessante Kommentare unter dieser Sendung zu dem Thema noch geben. Ja, also so, so schwer mir dieser Satz jetzt auch über die Lippen geht, aber aus, Webentwicklersicht und, vor allem aus, Sicht derer, die das Ganze dann, videotechnisch zusammenbasteln und rendern müssen, ist wahrscheinlich ohnehin Flash wirklich die, komfortabelste Lösung.

Ja, wahrscheinlich holen wir uns einfach alle zum Videogucken im Netz ganz krass aufgemotzte Windows-Kisten und gucken das in Flash.

Ja, also ich, ich, ich sehe nicht, wie das anders gehen soll. Man, man kann auf Dauer, wenn man ernsthaft wirklich regelmäßig auch verbraucherfreundlich, also als Nicht-Codec-Nerd irgendwie, Videos einbinden will, dann ist Flash die einzige Lösung, wo man sagen kann, das funktioniert relativ zuvers, zuverlässig auf relativ vielen Geräten. Alles andere artet auf Gefrickel oder mehrfach vorrätig halten von Videos auf. Es ist, nicht wirklich praktikabel.

Ich glaub, wir dürfen an der Stelle Google nicht unterschätzen. Allein mit der Umstellung von YouTube können sie, glaub ich, einiges bewegen. Ich setze auf WebM. Das wird was. Schauen wir mal.

Ich bin gespannt.

Wollen wir uns weiterbewegen oder gibt's zu Audio und Video noch was zu sagen?

Nee, das Thema ist ja relativ, relativ, prominent.

Dann kommen wir zu 'nem, weiteren, glaub ich, sehr prominenten Thema und schon wieder ein Flash-Killer.

Canvas nämlich. Genau, das hat wirklich mal 'ne Chance gegen Flash.

Dann sag uns doch mal, noch mal ganz kurz: Was ist Canvas?

, 'n programmierbares IMG-Element im Prinzip. Das ist 'ne Malfläche, auf die kann man mit 'ner, relativ umfassenden, JavaScript, Schnittstelle Sachen drauf zeichnen, Animationen mit machen. Es gibt 'ne 3D-Schnittstelle und,, Flash-Killer möchte ich noch 'n bisschen einschränken, weil es ist offenbar nicht vorgesehen für den IE9. Das heißt, das wird wohl möglicherweise auch nichts werden. Im Moment ist es halt in sehr vielen Browsern implementiert.

Das heißt, in allen guten Browsern, in allen richtigen Browsern ist das nativ vorhanden und in allen nicht so richtigen Browsern gibt's 'ne JavaScript-Bibliothek, die das dann nativ nachbildet. Das ist sehr langsam und sehr hässlich und kann nicht alles, aber geht halt relativ gut. Es ist halt so, dass, dass wenn man Animationen, animierte Bitmaps oder so was machen will, dann ist das 'ne super Sache.

Geht relativ gut. Damit meinst du aber jetzt auch wirklich nur die Webentwickler aus Webentwicklersicht. Den, der Nutzer möchte so was nicht, oder?

Was möchte er nicht?

Mhm, die Alternative für den IE mit JavaScript und dem ganzen Krams.

Ja, das, d-d-die IE-Alternative funktioniert so: Der hat ja dieses, diese archaische Technologie namens, VML bei sich rumliegen, so 'ne, so 'ne Art, SVG-artiges Vektorgrafikgedöns. Und, die schlauen Leute bei Google haben 'ne Bibliothek programmiert, die im Internet Explorer jedes Canvas-Element durch so eine, Vektorkonstruktion ersetzt und man kann die Prog-- Und dieses, diese Bibliothek übersetzt jeden Canvas-Befehl in eine, VML-Entsprechung.

Das heißt, als Webentwickler hat man's relativ einfach. Man schmeißt einfach dieses Extra-Skript rein von Google und programmiert seine Canvas so, als würde die in allen Browsern unterstützt werden, mit ganz wenigen Ausnahmen, die halt nicht gehen, weil, ne, VML ist ja von anno dazumal. Und der Nutzer merkt davon eigentlich gar nichts. Das heißt, kein echtes was auch immer ist. Das funktioniert halt einfach. Das ist also schon relativ gut.

Das Ärgerliche ist halt nur, im IE9 wird das nicht nativ vorhanden sein. Da wird man auch so rumhacken müssen.

Das heißt, deine, deine Zukunftsaussichten für, für Canvas, auf, ich sag mal, die nächsten drei Jahre sehen wie folgt aus?

Was heißt die nächsten drei Jahre? Die, die sind jetzt ja schon super. Die fu-funktioniert überall. Es ist halt nur, im Internet Explorer eben wegen dieser Übersetzung und dann noch in dieses, in dieses Vektorformat und alles so, so ekelhaft langsam und der IE selbst ist ja schon nicht grade als, Speedgranate bekannt. Und, wir werden jetzt dasselbe Problem mit dem IE9 haben. Bis jetzt hat sich Microsoft beharrlich darum gedrückt.

Die sind ja mit dem IE9 relativ offensiv und erzählen alles, was da Tolles drinsteckt. Aber wenn man die mal auf Canvas festnageln will, dann spielen die wie so 'n glitschiger Fisch. Die rutschen dann immer weg und sagen nix. Das, das heißt wahrscheinlich, dass das da nicht drin sein wird, warum auch immer. Mir ist es rätselhaft. Ich verdächtige die, dass die da versuchen wollen, keine In-House-Konkurrenz gegen Silverlight zu schaffen. Ein Verdacht, aber ich bin paranoid. Wer weiß es?

Hat das wer installiert?

Was?

Hat das irgendwer installiert, außer um, irgendwelche Microsoft-Konferenzen verfolgen zu können?

Ich kenn niemanden, ehrlich gesagt, aber das ist ja kein, ist ja kein Grund.

Noch 'n anderes Thema, ja.

Ja, es, es, ist halt nicht drin. Aber meine Zukunftsaussichten sind insofern halt ziemlich gut, dass es, es gibt halt keinen Grund, wirklich buchstäblich keinen Grund, Canvas nicht zu verwenden. Das im IE zurechtzuhacken, ist eben ein extra JavaScript einfügen. Das macht die Seite langsam. Ist die Frage, ob das jetzt im Internet Explorer 'n Problem ist, weil ob du langsam oder ganz langsam bist, ist dann ja Wurst. Es geht halt. Es kommt halt immer drauf an, was möchte man machen?

Möchte man irgendwelche dynamischen Animationen rendern? Dann wird's 'n bisschen schwierig mit dem IE. Will man einfach nur irgendwie 'ne, - Was Statisches darstellen, zum Beispiel einen Grafen rendern oder so was, dann ist das relativ problemlos möglich. Die Frage ist: Was macht man halt immer damit? Das Ganze ist von seiner Konzeption her 'ne ziemlich, m-m-me Low-Level-Geschichte.

Das heißt, man muss da wirklich, wenn man da jetzt einen Kreis zeichnen will, muss man da mit Kreisbögen und Winkeln und so was alles rumhantieren. Man kann nicht einfach sagen: „Mal mir Kreis. Da wird dann wahrscheinlich irgendwann mal, eine Art jQuery für Canvas kommen, mit dem das dann alles auch ein bisschen verbraucherfreundlicher wird. Aber es ist schon mal 'ne ziemlich gute Sache und das füllt halt wirklich, das Canvas-Element füllt ein ziemlich großes Loch.

Wir haben, glaube ich, noch gar nicht gesagt, was wollen die überhaupt mit HTML5, die ganzen Fritzen? Ja. Die wollen, die wollen Webapplikationen voranbringen. Die wollen nicht die, Website von Beispiel Müller GmbH verbessern, sondern die wollen, das übernächste Facebook oder das nächste Google Docs besser machen. Und was ja in dem Web fehlt, ist irgendwie wirklich 'ne Sache, 'ne, 'ne Zeit, 'ne Fläche, wo du einfach so beliebig Pixel draufmalen kannst. Das geht halt nicht mit HTML und CSS.

Also Applikationen, nachbauen mit 'ner Webseite quasi, sodass ich nicht nativ jetzt irgendwas installieren muss und programmieren muss, sondern ich nutze das eben als Webseite.

Ein gutes Beispiel dafür ist, ist ja eigentlich auch, Best Bin. Das kennt ja sicherlich auch schon der ein oder andere.

Hatten wir in der Sendung auch mal vorgestellt, ja. Ja.

Genau. Das ist ein, Projekt von Mozilla. Das ist 'n, 'ne kompletter, ein kompletter Code-Editor im Web, im Browser, der sein komplettes Interface eben auf Canvas aufbaut. Da kann man eben das machen, was man, was eben im Web sonst bisher halt eben fehlte, so eigene Interface-Elemente konstruieren. Es gibt auch schon eine ganze Reihe von, richtigen Bibliotheken, die das, machen, die halt Canvas nehmen und damit so 'ne UI, UI-Bibliothek herstellen. Gibt's ja auch für jQuery, jQuery UI und so was.

Da ist es eben aus HTML konstruiert und bei denen der nächsten Generation sind dann eben diese ganzen einzelnen Sachen Canvas-Elemente, die man dann anklickt und nicht mehr irgendwelche Diffs.

Wo siehst du, wo siehst du da die Grenze? Können wir irgendwann unser GarageBand, was nicht ganz so zuverlässig ist, irgendwann durch eine schöne Webapplikation ersetzen?

Ach, ich wüsste nicht, warum das nicht gehen sollte. Also tatsächlich ist es so, alle, all, alle Bausteine sind eigentlich da. Also ein Beispiel für Canvas auch, was ziemlich, eindrucksvoll demonstriert, was möglich ist. Die Google-Jungs haben ja kürzlich – das ist, glaube ich, auch den wenigsten entgangen –, Quake 2 auf, HTML5 portiert.

Technik will zur Höhe erkennt das jedenfalls, ja.

Siehst du, das läuft, komplett mit HTML5-Bordmitteln. Das rendert auch auf eine Canvas und das spielt, Sounds mit einem Audioelement ab. Und wenn Quake 2 geht, wüsste ich nicht, warum sollte da nicht irgendwie ein Videoschnitt- oder Audiotool-Programm nicht auch gehen? Ich würde sagen, da geht alles. Das sind-- Mit HTML5 sind alle Bausteine dabei, also fast alle.

Wir kommen ja sicherlich nachher auch noch mal ein bisschen auf die Zukunft zu sprechen, HTML6 und so und was da noch so angekündigt ist. Aber generell sind jetzt alle Bausteine halt da, um eben solche Sachen, GarageBand oder, sonstige Dinge nachzubauen. Es muss halt nur erst mal jetzt irgendwer machen.

Genau, und fragen wir mal ganz kurz nach dem Sinn. Sinn macht es natürlich dann, wenn man plattformunabhängig irgendwas bereitstellen möchte. Das heißt nicht nur eine Version für Windows, für Mac und für Linux, sondern man sagt, es soll überall funktionieren und deswegen im Browser und dann bietet sich das an.

Und es soll gut funktionieren. Google Docs kennen wir ja, ist ja, schon plattformunabhängig, aber man kann damit jetzt ehrlich gesagt nicht alles machen, was man jetzt, auf dem heimischen Rechner mit Microsoft Word oder OpenOffice machen kann.

Hat allerdings auch nicht mehr sehr viel von irgendwie in der Text Area. Also sind schon relativ weit.

Die sind relativ weit, aber trotzdem, diese letzten paar Sachen sind da nicht drin, weil die Google-Jungs keine Zeit hätten, die einzubauen, sondern weil die einfach technisch bis dato nicht möglich waren. Mit HTML5 haben sie das Rüstzeug, um wirklich da, Microsoft Office und was da nicht alles rumkreucht, komplett in den Boden zu stampfen. Und ich denke mal, das werden die bald tun.

Wir kamen eben schon auf den 3D-Bereich zu sprechen. Magst du dazu noch zwei, drei Worte verlieren, was da so geht, was da überhaupt so der Stand der Dinge ist und was es da so auf technologischer Basis gibt?

Ja, gerne. Es ist auch eigentlich ganz einfach. Es gibt, OpenGL, kennt jeder. Es gibt von OpenGL 'ne, spezielle Version für eingebettete Systeme, OpenGL ES. Und, die Spezifikation von WebGL ist nicht weniger, als, OpenGL-ES-Schnittstelle zu bauen für das Canvas-Element. Das heißt, wer immer irgendeine 3D, 3D programmieren kann, also ob er sich mit OpenGL auskennt, mit der Shader Language fit ist und so was, kann das Canvas-Element jetzt als Malfläche nutzen, um seine Ergüsse dort abzubilden.

Das beste Beispiel ist, wie gesagt, Quake 2 gewesen, aber da geht, denke ich mal, jetzt alles mit. Das ist jetzt noch nicht so weit, dass es stabil wäre. Die meisten Browser haben das nur als irgendwelche Experimental-Features dabei, aber das geht. Es ist halt nur höllisch kompliziert.

Also wo du grad noch mal zu Quake, 2 zu sprechen kommst, performant ist das allerdings noch lange nicht. Also ich weiß nicht, ob du das mal bei dir hast, laufen lassen.

Vielleicht li, lag's auch nur an meiner uralten, an meinem eineinhalb Jahre alten MacBook Pro, aber, das hat sich so im Bereich von, weiß ich nicht, 40 Frames bewegt und, Quake 2 hat doch schon so das ein oder a, ja, andere Jahr hinter sich und ist eigentlich nicht besonders großartig aufwendig, würde in einer nativen Form auf dem Mac, die Dreihunderter-Grenze sprengen oder so.

Das hat, denk ich mal, mehrere Gründe. Also der erste ist natürlich, dieses ganze, diese ganze Schnittstelle, dieses WebGL ist hoch experimentell. Das ist noch nicht so weit. Zweitens:, ich denke nicht, dass der, JavaScript wurde ja ursprünglich nicht dafür gebaut, 3D-Shooter abzuspulen. Das ist ja von seiner, das ist ja von seiner ganzen Konzeption her nicht zu vergleichen mit dem, in was Quake 2 ursprünglich für eine Programmiersprache geschrieben ist.

Ich weiß nicht, was es ist, aber irgendwie C, C++ wird das gewesen sein. Es hat 'n gewissen Geschwindigkeitsvorteil. Und drittens ist ja auch, dieses Quake 2 nicht so entstanden, dass da irgendwer, von Hand diese ganzen Sachen hin- und hergeport-portiert hätte, sondern es gab, gibt einen Quake-2-Port in Java und Google hat ja dieses tolle, Google Web Toolkit, was, Java-Code automatisch transformiert in HTML und, JavaScript. Und das haben die halt nur auf dieses Quake angewandt.

Das heißt, da ist also 'ne, mehrfache co, automatische Code-Transformation drin. Wahrscheinlich nicht so effizient, wie es sein könnte. Und drittens gibt's, das ist eine schöne Überleitung zu, einer weiteren Technologie. Es gibt Web Workers und, die können, bei solchen Sachen helfen. Also, Web Workers, kurz zur Einordnung, war ursprünglich Teil von, HTML5, von der HTML5-Spezifikation der WhatWG. Jetzt ist es ausgelagert in eine eigene Spezifikation.

Es gibt 'ne Spezifikation der WhatWG, es gibt 'ne Spezifikation des W3C. Da haben wir jetzt auch nicht so 'ne Überschneidungsgeschichte, sondern die sind mehr oder minder identisch und, ich weiß nicht, warum es zwei gibt. Nehmen wir's erst mal so hin. Die machen das Folgende: Die, erlauben es, Hintergrundprozesse für JavaScript einzurichten. Der Browser an sich tickt so: Der kann nur eine interaktive Sache auf einmal machen.

Entweder der führt 'n JavaScript aus oder der lässt einen auf einen Button klicken. Diese, das ganze Interface des Browsers und das JavaScript laufen sozusagen auf einer Spur und es kann immer nur eins gleichzeitig passieren. Die Folge ist das: Wenn ein, langlaufendes Skript vorliegt, kann man nichts mehr anklicken. Der ganze Browser ist blockiert. Das kennt ja, denk ich mal, jeder von uns. Das liegt dann einfach, ist der Konzeption des Browsers so innewohnend.

Da kann man auch nichts weiter gegen machen, es sei denn, man nimmt Web Workers. Da kann man eine, Skriptdatei laden. Die wird im Hintergrund ausgeführt, nicht blockierend in einem eigenen Thread. Man kann mit diesem, mit dieser Konstruktion, mit diesem Web Work, Worker über Nachrichten kommunizieren. Man kann an den Nachrichten schicken. Also 'ne Anforderung:, berechne mir so und so. Der berechnet was und sendet 'ne Nachricht zurück. Dann kann man darauf mit 'nem Event reagieren.

Und das ist wirklich ganz, ganz simpel. Man braucht eigentlich bloß, zwei Funktionen, um die Kommunikation zu regeln, von der Seite zum Web Worker und aus dem Web Worker heraus in die Seite. Alles ganz simpel, funktioniert super, ist in Firefox implementiert, läuft in Safari, glaub ich, relativ gut und man kann's im IE gut faken.

Praktisches Beispiel: W-was würde dir so spontan ein-einfallen, wofür das perfekt gemacht ist?

, 'n praktisches Beispiel hab ich jetzt, also ist halt die Frage, das Problem ist halt, der Browser an sich ist schon relativ flott. Die, diese ganzen Mechanismen, die da das JavaScript rumoptimieren und so was, in Chrome, in Firefox, überall sind da unterschiedliche Sachen drin, die sind alle verdammt gut. Ich hab letztens 'n, 'n Test mit Web Workers gebaut, so zum Ausprobieren.

Da hab ich den, den Firefox fünfzig Millionen Quadratwurzeln aus Zufallszahlen ziehen lassen müssen, bis ich da irgendwie 'ne annehmbare Verzögerung hinbekommen habe.

Was du so für Hobbys hast.

Ich fand's spannend. Jedenfalls.

Was heißt denn annehmbare Verzögerung? Nur so rein interessehalber.

Paar Sekunden, dass man's halt gemerkt hat..

Hast du nachgerechnet? Egal, mach weiter.

Nein, nein, ich hab einfach fünfzig Mil, fünfzig Millionen Zufallszahlen generieren lassen und einfach daraus die Quadratwurzel gezogen. Also wahrscheinlich nicht das Klügste, weil mathematische Operationen, können die ganz gut, ganz gut wegstecken. Ich hab mal jemanden gesehen, der wollte da, der hat da mit, der hat das mit Ba, der hat eben mit Bubble Sort zum, den Browser zum Erliegen gebracht. Das geht wahrscheinlich besser, aber Quadratwurzeln ziehen ist einfacher für mich jetzt.

Also, um darauf zurückzukommen. Also man kann, man, man könnte halt zum Beispiel mit diesem, mit diese, mit dieser Aufgabe, Quadratwurzel ziehen, ist jetzt keine praktische, aber man könnte ja mal beispielsweise sagen, wir hätten jetzt irgendein 3D-Spiel, Quake 17, und wir wollten da 'ne prozedurale Textur zum Beispiel berechnen. Das k, stell ich mir jetzt mal ohn, als 3D-Laie relativ komplex vor.

So, damit wir jetzt während der, während der Berechnung dieser Textur nicht den ganzen Browser blockieren, haben wir einen Textur-Web Worker, also ein JavaScript-Objekt, was diese, diesen Prozess ausführt. Wir können an diesen Web Worker 'ne Nachricht schicken: „Pass auf, ich hätt gerne Textur mit diesen Eigenschaften, zack, zack, zack, zack, zack.“ Dann berechnet er das im Hintergrund in 'nem eigenen Thread. Wir merken davon überhaupt nicht, dass der das berechnet.

Das ist jetzt nicht automatisch deswegen schneller, aber wir merken's halt nicht mehr, dass es stattfindet. Der Browser ist nicht blockiert. Der berechnet seine Textur, das dauert, das dauert, das dauert. Dann hat er irgendwann die Textur fertig gerechnet und sendet die dann zurück an uns. Es ist das gleiche Interface zur Kommunikation mit dem Worker wie aus dem Web Worker heraus. Man hat send message, und man hat 'n Event, mit dem man Messages empfangen kann. Das ist wirklich super einfach.

Und das Gute ist, es sind wirklich einzelne Threads. Das heißt, nicht nur merkt man nicht, dass, irgendwo was rechnet und langsam ist, sondern wenn man irgendwie mehrere CPU-Kerne oder so was hat, dann kann das tatsächlich sogar zu 'ner Geschwindigkeits-, steigerung führen, weil man dann verteiltes Rechnen machen kann, indem ich zum Beispiel meine fünfzig Quo, Millionen Quadratwurzeln, ziehen lasse in, fünfundzwanzig Millionen Paketen von zwei separaten Workern.

Du hast jetzt viel über fünfzig Millionen Quadratwurzeln und 3D-Spiele geredet. Meinst du, das bringt auch 'n, 'n spürbaren Vorteil für die klassische 2D-Applikation?

Also ich könnt mir zum Beispiel vorstellen, wir hatten ja grad das Beispiel, gut, also Video- und Audioschnitt würde wahrscheinlich auf dem Server stattfinden, dann sowieso asynchron sein. Aber nehmen wir mal an, wir hätten irgendwie so was, irgendeine komplexe Berechnung, jede komplexe Berechnung, die auch nur das, die kleinste Verzögerung spürbar hier im Interface hervorruft. Die kann man in solche Web Worker auslagern.

Und das, und das Gute ist halt, der Haupt, der, der Haupt, Aspekt dieser Dinger ist eben, das Blockieren zu verhindern. Wenn immer irgendeine komplexere Berechnung stattfindet und der Browser blockiert und dieses Blockieren nicht daran liegt, dass irgendwie 'ne komplexe, Rendergeschichte stattfindet.

Das ist ja meistens so, wenn man zu viel mit jQuery rumspielt, dann, sind da irgendwelche Animationen und diese Animationen verursachen im Layout der Seite Reflows und Repaints und die sind langsam und das hat eigentlich gar nichts mit JavaScript zu tun. Aber wenn man mal ein, ein Bottleneck hat mit JavaScript und man diese Berechnung durchführen muss, egal was das ist, in den Web Worker auslagern, Problem gegessen. Es ist nicht schneller, aber man merkt's halt nicht mehr.

Der Browser ist nicht mehr blockiert. Es ist also wirklich wieder so eine Geschichte mit der wahrgenommenen Geschwindigkeit. Und wenn man, wie gesagt, ganz komplexe Sachen hat, fünfzig Millionen Quadratwurzeln und das verteilt rechnet, dann geht's auch schneller.

Wie sieht es jetzt da mit der Unterstützung in den Browsern aus?

Super. Alle machen mit, außer Opera und dem Internet Explorer. Das ist gar kein so großes Problem, weil man kann das, man kann diesen Effekt tricksen. Ich hatte ja schon angesprochen verteiltes Rechnen. Man kann das ja auch so verteilen, dass das Kleinstaufgaben sind und die in einem Intervall durchführen.

Das heißt, meine fünfzig Millionen Quadratwurzeln teile ich jetzt in Tausenderpakete auf und lasse den jetzt, ist jetzt ineffizient, aber sagen wir mal, ich lasse jede, jede Sekunde ein solches Paket ausrechnen. Dann dauert das zwar länger, blockiert aber auch nicht mehr, weil nur jede Sekunde einmal so eine kleine Quadratwurzelberechnung passt und in der Zwischenzeit kann ich alles weiter anklicken. Es gibt sogar ein Skript, das nennt sich IE, IE Web Workers, glaube ich.

Das ist genau wie Canvas so eine Drop-in-Lösung. Das heißt, als Web Worker schmeißt man das Skript rein und dann nimmt man einfach als gegeben hin, dass Web Worker unterstützt werden. Wenn die nicht unterstützt werden, kommt dieses, IE-Skript daher und baut sozusagen dieses ganze Web-Worker-Interface mit Post Message und so was alles nach. Die Umsetzung findet dann aber nicht über echte Threads statt, weil die sind im Browser nicht implementiert, sondern eben über diese Intervalltechnik.

Insofern ist das da eigentlich gar nicht so finster. Man kann halt auf jeden Fall, wenn man die Seite nicht wirklich schneller machen kann, kann man sie zumindest spürbar schneller machen, auch wenn es nicht wirklich schneller ist, aber das ist ja auch schon gut.

Ich hätte da noch so ein Thema, was mir, sehr unter den Nägeln brennt, was, zwar nichts spürbar schneller macht, aber ich glaube, uns spürbar weiter an eine, Webapplikation heranbringt, die sich anfühlt wie eine Desktop-Applikation, wenn ich das Thema Web Workers verlassen darf.

Du darfst.

Drag and Drop.

Oh ja, super. Die hässlichste API, die der Mensch je gesehen hat.

Schade eigentlich, weil meiner Meinung nach einer der wichtigsten Dinge, um so den, den, Sprung, von, von Webapplikation zu gefühlter Desktop-Applikation zu schaffen.

Das habe übrigens nicht ich gesagt. Das hat Ian Hickson gesagt, der HTML5-Chefeditor.

Dann glauben wir dem mal.

Das hat Peter Paul Koch gesagt, der Treiber von QuirksMode, QuirksMode.org. Der kennt sich ja eigentlich mit Browsermacken aus. Der muss das wissen. Wenn der das Ganze als einen stinkenden, wenn der das Ganze als einen stinkenden Kuhfladen bezeichnet – seine Worte, nicht meine – muss da was dran sein. Ja, es ist, es ist schrecklich. Ich kann ja mal die Geschichte rezitieren.

Sehr gerne.

Es begab sich zu der Zeit des Browserkrieges, da dachte sich der Internet Explorer: „Ich muss, irgendwas Drag-and-Drop-Artiges implementieren bei mir.“ Und er implementierte. Es ist dann, ursprünglich gedacht gewesen dafür, dass man Text markiert und das in der Text Area reinzieht und so was.

Und dann dachte sich Firefox: „Ja gut, schreiben wir mal ab.“ Und dann dachte sich Safari: „Gut, schreiben wir mal ab.“ Und weil das ja alles nicht irgendwie Open Source war, war das, ist das alles jetzt so unterschiedlich und voneinander abweichend und so.

Und der Grund, warum das in HTML5 drin ist, ist jetzt, dass das, dass diese API, überall irgendwo so teilweise ein bisschen drin ist und dass der Aufwand, eine benutzbare API zu erzeugen, dann jetzt bei allen Browsern in der Summe eher niedrig ist. Ja, das ist der Grund. Der, also ich, ich, ich will gar nicht erst versuchen, das zu erklären, weil ich hab, lange gebraucht, um das zu verstehen, länger gebraucht, um es zu schreiben. Es ist, es ist höllisch kompliziert. Das muss so nicht bleiben.

Ich denke mal, irgendwann wird irgendjemand Schlaues daherkommen und der wird 'ne Abstraktionsschicht dafür schreiben und dann wird das alles ganz wunderbar bequem sein. Wenn man das Ding in real nutzen will, dann wird das sehr schmerzhaft. Also ich kann ja auch mal ein paar lustige, lustige Sachen, erzählen, so aus dem, aus dem, aus dem Fundus der, der Absurditäten da drin. Es gibt, im Internet Explorer die Möglichkeit, Text zu ziehen oder Links.

Es gibt im Firefox die Möglichkeit, Elemente zu ziehen, die das HTML5-Attribut draggable bekommen haben. Das haben die sich extra für HTML5 ausgedacht, weil es im Firefox keine andere Möglichkeit gab. Kann man so machen. Und im Safari macht man ein Element draggable, indem man, eine, dem eine, eine bestimmte CSS-Eigenschaft verpasst. Mit CSS macht man das Ding draggable. Okay, nicht nur mit, nicht nur mit Internet Explorer rauchen die komischen Sachen.

Nein, aber, kurz anzufügen wäre da ja, dass sich, das sieht man ja schon heute, die Browser sich auch unterschiedlich, verhalten.

Also die, die, Safari-Nutzer kennen das jetzt beispielsweise, wenn ich jetzt eine Datei hochladen möchte und ich habe jetzt einfach nur so ein Datei-Upload-, -Fältchen, dann kann ich, einzig nur unter dem Safari zum Beispiel irgendeine Datei aus dem, File Browser direkt da draufziehen und er nimmt es an, was bei allen anderen, Browsern dazu führt, dass er versucht, die Webseite, die Datei zu öffnen.

Und das sind, daran erkennt man schon, dass es da keine einheitliche Basis gibt, auf die man aufsetzen könnte.

Mhm. Also die, einheitliche Basis ist schon zu einem gewissen Grad da. Also ich sollte jetzt vielleicht mal, bevor ich jetzt hier noch weitere,, Horrormeldungen an die Wand male, mal vielleicht ein bisschen erzählen, wozu ist das gut und wozu brauche ich eine Drag-and-Drop-API, wenn ich noch jQuery und Konsorten habe? Der Punkt ist der folgende:, so eine Drag-and-Drop-API mit einer herkömmlichen JavaScript-Bibliothek ist immer beschränkt auf die gerade aktuelle Seite.

Wenn ich auf der Technikwürze-Seite jetzt wäre und ich könnte jetzt meinetwegen die Bildchen von den Autoren durch die Gegend ziehen, kann ich die nur innerhalb dieser Seite durch die Gegend ziehen, weil eben nur diese Seite technikwürze.de diese Bibliothek implementiert hat. Und wenn andere Seiten die auch haben, können die nicht miteinander reden. Das geht halt einfach auf Browser-Ebene nicht. Und, genau das Loch, füllt die HTML5 Drag-and-Drop-API.

Da kann ich Sachen von einem Tab ins nächste ziehen. Also mal angenommen, ich hätte jetzt ein Profil bei Twitter und ich hätte ein Profil bei Facebook und ich will, mein Profilbild, von Twitter nach Facebook schaffen, dass das da auch angezeigt wird Da müsste ich jetzt im Moment, das Profilbild runterladen und woanders wieder hochladen.

Wenn die beiden Seiten jetzt einfach 'ne, mit der Drag-and-Drop-API ganz generell gesprochen so programmiert wären, dass die Drag-and-Drop-Operationen die Bilder enthalten, annehmen, dann könnte ich mein Profilbild aus Twitter rüberziehen nach Facebook, in einen anderen Tab, in ein anderes Browserfenster aus Safari, Internet Explorer. Völlig egal, geht alles. Da loslassen und dann empfängt die Facebook-Seite das und kann das entsprechend verarbeiten.

Wäre ja ein Traum. Bleibt aber einer, oder?

Nein, geht sogar schon teilweise. Also mit mehreren Browserfenstern ist das gar kein Problem. Wenn ich jetzt-- Also im Firefox jedenfalls, da, da sind sie im Moment Vorreiter dabei. Da kann ich das, da kann ich jetzt Seite A aufmachen und, da Inhalte reinziehen, die aus Seite B stammen. Die müssen – also das ist ganz wichtig – nicht speziell aufeinander programmiert sein.

Facebook könnte jetzt dahin gehen und sagen: „Generell, ich nehme Drag-and-Drop-Operationen an, die ein Bild enthalten." Und dann könnte ich zum Beispiel nach Wikipedia gehen. Ich könnte, ich könnte, Elvis ansurfen und mir das Foto von Elvis nehmen und das rüberziehen. Die Drag-and-Drop-Operation im Browser, die nativen, sind, ich lehne mich jetzt hoffentlich nicht zu weit aus dem Fenster, aber meist ziemlich eng verzahnt mit diesen, aus dieser API.

Ich könnte also Wikipedia, eine Seite, die darauf nicht programmiert ist, nehmen, das Bild rüberziehen nach Facebook, da fallen lassen und Facebook ist schlau genug, Drag-and-Drop-Operationen anzunehmen und kann die entsprechend verarbeiten. Also wirklich wie, wie beim Desktop. Ein Programm ist dafür gebaut, weiß ich nicht, ein Code-Editor, dafür, dass wenn man da Textdateien reindroppt, dass der dann was Sinnvolles damit macht.

Und, ob ich die Textdateien jetzt rein droppe aus einem, Dateiexplorer oder aus einer Website darauf ziehe, ist dem Code-Editor ja völlig egal. Der sagt einfach nur: „Ich akzeptiere Textdateien." Und genauso läuft's dann halt eben auch in Websites. Das Problem ist halt die im Moment äußerst haarigen und verschiedenen Implementierungen.

Okay, also es ist wirklich, also nehmen wir mal beispielsweise unsere Freunde von Google mit ihrem noch immer etwas experimentellen Dienst, Google Wave. Daaa, soweit ich weiß, funktioniert's noch immer nicht, dass ich jetzt meinetwegen irgendwas hochladen kann, indem ich es einfach von meinem Dateibrowser in, mein Browserfenster ziehe.

Das sind noch-- Das ist was anderes. Das ist eine andere Schnittstelle. Wenn's um Dateien geht. Es geht halt jetzt hauptsächlich darum, also das wäre die, die File-API, wenn ich mich nicht täusche.

Okay, also das ist gar nicht das Gleiche. Gut, dann habe ich nichts gesagt.

Vom Desktop in den Browser. Jetzt im Moment, wovon ich rede, geht, geht halt hauptsächlich darum innerhalb des Browsers oder zwischen verschiedenen Browsern hin und her.

Alles klar.

Also von der Konzeption her müsste es wirklich gehen, dass ich Safari aufhabe und ich ziehe Dateien in den Internet Explorer, was weiß ich, fünf, der hat die auch schon. Die können miteinander reden. Das ist die Theorie. Ganz praktisch funktioniert's nicht und das liegt in dem Fall im Übrigen an Safari, nicht am Internet Explorer. Der macht das alles super, Safari ist böse. Aber s-solcherlei Sachen gehen halt. Sehr praktisch, aber im Moment noch sehr haarig. Ja.

Und was du gerade sagtest, die File-API kommt dann eben noch dazu. Das sind eben so typische, typische Fälle. Die File-API ist jetzt eine ausgelagerte Spezifikation, die ist nicht Teil von HTML5. Die Drag-and-Drop-API ist Teil von HTML5, den echten Kernspezifikationen. Also erst mal sieht man daran ganz gut, wie sinnvoll das ist, das wirklich zu trennen. Nämlich gar nicht. Und, zweitens, das gehört alles so zu dem Gesamtpaket, mein Browser kann mehr.

Mein Browser und meine Websites werden halt mit, Drag-and-Drop-Fähigkeiten ausgestattet, die ja darüber hinausgehen, dass ich auf einer einzelnen Seite isoliert was hin- und herschiebe.

Oder ich mal auch Dinge machen kann, ohne dass ich eine Internetverbindung habe.

Oh, ein eleganter Themenwechsel.

Bitte sehr.

Also das ist nämlich ein weiteres Problem, was, mit HTML5 ganz gut gelöst wird, nämlich das Problem, des Offline-Seins. Ein grausiges Schicksal, dem man aber auch heutzutage nicht ganz entrinnen kann. Wenn alle Applikationen – das ist ja, die große Idee dahinter – ins Web verfrachtet werden, was macht man denn dann, wenn man mal keine Webverbindung hat? Wenn man im australischen Busch oder im Flugzeug auf dem Weg dorthin sitzt.

Dann, sähe man in der Theorie alt aus, aber da gibt's auch durch HTML5 und die erweiterten Tech-- die Technologien aus dem erweiterten Zirkel Möglichkeiten, da was gegen zu tun.

Die da wären?

Erst mal im HTML5-Kern selbst gibt's die Möglichkeit, einen Application-Cache zu definieren. Das ist zu trennen vom Browser-Cache, der ein paar Sachen zwischenspeichert, damit die Seite schneller lädt.

Beim Application-Cache kann ein Webentwickler ganz genau sagen: „Zum Funktionieren braucht diese Online-Anwendung diese Datei, diese Datei, diese Datei, diese Datei." Und sobald du dieses Ding zum ersten Mal ansurfst und dein Browser versteht diesen Application-Cache, dann lädt er diese Dateien alle runter und hält die vorrätig. Und wenn du dann die Verbindung trennst, kannst du diese ganzen Dateien weiter benutzen.

Also nehmen wir mal an, ein Blog ist jetzt keine klassische, Online-Applikation, die jetzt offline tauglich gemacht werden müsste, aber mal angenommen, wir hätten einen Blog und wir hätten eine Seite About, wo draufsteht, dass wir unser tolles HTML5-Blog haben. Und das wäre jetzt offline tauglich gemacht. Dann würden wir die jetzt ansurfen. Wir würden auf den Index drau-- auf dem Index landen. Wir würden nicht die About-Seite anklicken.

Aber weil der Application-Cache die About-Seite definiert, lädt sich unser Browser das Ding im Hintergrund runter und dann bricht die Verbindung ab und wir kriegen das gegebenenfalls gar nicht mit und wir klicken auf About. Dann würden wir normalerweise sehen: Verbindung besteht nicht. Weil aber der Application-Cache diese Datei vorrätig hält, holt er die aus dem Cache raus und zeigt die uns.

Und wir können das Ding, das ganze Blog, jedenfalls soweit es die About-Seite betrifft, weiterverwenden, als wär nix.

Du hast gerade gesagt, M-man sagt ihm, wir brauchen die Datei, die Datei und die Datei. Wie sieht das in der Praxis aus? Also was, was, was gebe ich dem, dem Browser denn wirklich an die Hand?

Im Prinzip 'ne ganz einfache Liste von, Adressen, wo die Dateien zu finden sind.

Okay, also es geht wirklich um, so richtige Dateien, so einen Punkt HTML oder so was.

Ressourcen. HTML, Bilder, Scripts, Styles. Audio und Video Dateien, wenn man lustig ist, das geht alles. Und man kann, man kann auch umgekehrt,, definieren zum Beispiel, dass gewisse Dateien auf keinen Fall vorrätig gehalten werden dürfen. Also nehmen wir mal an, unser Blog hätte jetzt, einen Beitrag und dieser Beitrag hätte eine Einzelansicht. Beitrag eins HTML.

Und wir sagen, jemand, der offline ist, sollte den nie zu Gesicht bekommen, weil dadrunter läuft 'ne Diskussion und, nicht, dass irgendwer da jetzt einen Kommentar reinposten will und, ist schon gar nicht mehr aktuell. Mittelgutes Beispiel. Nehmen wir mal einfach so hin. Dann können wir den, diesem, Application Cache einfach sagen, pass auf, diese Einzelansicht des Blogs ist, gesperrt.

Und wenn jemand im offline, offline ist und die anklickt, dann kannst du als Ersatz diese, diese andere Datei anzeigen mit einer Erklärung, warum er das nicht an-angezeigt kriegt oder so was. Man kann eben ganz, ganz fein steuern, was die, Webapplikation vorrätig hält und was nicht.

Damit habe ich jetzt erreicht, dass meine Ressourcen vorrätig sind und wenn ich was rein Statisches habe, kann ich auch, neue Seiten noch anzeigen, obwohl keine Verbindung besteht. Wenn ich, wenn wir jetzt aber wieder zurückkommen zu Webapplikationen, bei denen ich irgendwas dynamisch machen kann, komme ich damit noch, damit noch nicht besonders weit, oder?

Da kommt man dann zu einem Problem. Was machen wir denn, wenn jetzt jemand dann, was Neues einträgt, einen neuen Datenbanksatz, einen ei, neuen Datensatz zum Beispiel. Da gibt es eine ganze Reihe an, Techniken, wie man das machen kann.

Der, Weg im Groben ist immer der:, man fängt diese Eingabe ab, speichert die im Browser irgendwie zwischen und entweder ist man damit fertig, weil man seine ganze Applikation so konstruiert, dass sie grundsätzlich nur im Browser arbeitet und gar nicht mit einem Server mehr redet. Das ist ja auch denkbar. Oder man baut eben eine Applikation, die solche Sachen dann einfach sozusagen abfängt, zwischenspeichert und sobald man wieder online geht, synchronisiert sich das dann mit dem Server.

Das wäre zum Beispiel denkbar. Das heißt, man würde also jetzt meinetwegen, man hätte eine To-do-Liste und man füllt die mit Einträgen und man, sitzt im, was weiß ich, in einem Bus und man fällt von einem Funkloch ins nächste. Dann ist das der, dann kriegt man das selbst, wenn man die, wenn die Applikation richtig gemacht ist, überhaupt nicht mit, weil nach der eigenen Wahrnehmung kriegt man immer nur Sachen ein, Sachen ein, Sachen ein, Sachen ein.

Und immer wenn halt gerade Verbindung besteht, merkt das der Browser und, synchronisiert sich dann und, bricht wieder ab. Das ist, glaube ich, auch das, was man bei Google Wave immer sehr schön sieht. Wave hat ja auch so ein Synchronisierungsfeature. Manchmal sieht man das so oben in der Ecke- -dass da so was vorgeht. Genau das ist das dann.

Die Herausforderung dabei ist dann wahrscheinlich eher Backend-seitig, sich, wenn wir jetzt mal nicht über ein kurzes Funkloch von einer Haltestelle oder so was, um bei deinem Bus Beispiel zu bleiben, sondern ich steige zwölf Stunden in, in einen Flieger und mach irgendwie ziemlich viel. Zum einen, jedenfalls ist das so, ohne es wirklich gesehen zu haben, so mein, mein Gefühl, ist das eine ziemlich wackelige Sache.

Ich habe irgendwie einmal meinen, meinen, weiß ich nicht, Browser-Cache vielleicht geleert oder so was und der schmeißt das da mit raus. Liege ich da so richtig? Könnte das passieren?

Jein. Es ist, ein weniger großes Problem. Es ist nicht, also ein Browser-Cache ist, ist ja eine relativ, ist, ist, ist von der Konzeption her schon eine ziemlich wackelige Sache, weil der hat ja eigentlich auch nur die Geschwindigkeit, das vorrätig zu halten, was du möglicherweise mal brauchen könntest und wenn nicht, ist auch egal. Ne, das ist es ja eigentlich. Im Application Cache ist das aber wirklich so, der, der ist sorgfältig.

Der, was du da einträgst, verschwindet da nicht, sobald, s-sofern du es ihm nicht, explizit sagst.

Das heißt, ich muss mich als Entwickler dann nur noch vor allem darum kümmern, nachdem ich das Ganze irgendwie aufgebaut habe, so, was passiert, wenn ich da jetzt 'ne Dublette bekomme, weil irgendwie, User A hat irgendwas gemacht, während User B das auch gemacht hat, nur der war offline und das kommt später rein und solche Geschichten. Das sind dann ja wahrscheinlich die Herausforderungen an der Stelle mit dem...

Genau, solche Sachen gehen. Oder natürlich, es kann natürlich passieren, dass der, Nutzer, bewusst einen, seinen Offlinespeicher halt leer macht, ne. Das ist natürlich auch möglich. Also wer das Ding mal sehen möchte, im Firefox Einstellungen erweitert unter Netzwerk gibt es einen Eintrag Offlinespeicher und da kann man den leer machen.

Wie siehst du grundsätzlich mit der Verbreitung, und der Unterstützung der Browser aus?

Firefox und Safari und Chrome gut.

Rest weniger.

Rest nicht.

Also komplett nicht? Auch die neue Opera nicht?

Soweit ich weiß noch nicht, nein. Kann sich ja ändern. Ich weiß jetzt nicht, wie es beim IE9 mit der Ankündigung da aussieht, ob der das im-implementieren möchte oder nicht. Hab ich, hab ich jetzt ehrlich gesagt nicht auf dem Schirm. Und bei Opera wissen wir, die sind zwar manchmal,, out of sync mit dem, mit den anderen Browserherstellern, aber generell implementieren die ja auch neue coole Sachen. Da würde ich mir keine großen Sorgen drum machen.

Letztlich ist auch immer die Frage: Braucht man diesen Application Cache zwingend? Es kommt immer auf das Benutzungsszenario an.

Ja, klar.

Wenn wir jetzt diese zehnstündige Bustour haben, ist man als Internet Explorer Nutzer natürlich ziemlich in den Hintern gebissen, weil innerhalb dieser zehnstündigen Bustour wird man früher oder später auf irgendwelche Ressourcen aus dem Application Cache zurückgreifen müssen.

Ist die Frage, ob der Nutzer, der mit, einem Internet Explorer zehn Stunden durch die Sahara fährt, nicht einfach-

Meine Theorie, wer, wer das Ding nutzt, ist selber schuld. Aber, ja, mal, mal ein anderes Szenario. Mal angenommen, irgend, wir hätten jetzt dieses, dieses von einem Funkloch ins nächste Szenario. Irgendwer würde jetzt die To-do-Listen-App aufrufen und seine Verbindung würde dauernd wegklappen.

Das kann man im Internet Explorer ziemlich gut abfangen, weil, wir haben ja noch dieses, diese Konstruktion nicht nur das Application Cache, sondern auch der Zwischenspeicherung von Datensätzen auf dem Browser. Da gibt's, mindestens drei verschiedene Spezifikationen, die alle unterschiedlich gut implementiert sind. Also die Safari-Hacker unter uns kennen vielleicht oder die, die WebKit-Hacker allgemein kennen vielleicht die, Web SQL Database.

Da kann man halt einfach wirklich mit 'ner, mit 'ner Datenbank im Browser sprechen und da Queries ausführen und da einfach beliebige Sachen abspeichern, was recht komfortabel ist, aber bislang eben bloß im WebKit vorhanden ist. Als Gegenentwurf dazu gibt's zum Beispiel DOM.storage. Das ist 'n bisschen einfacher, das sind einfache Key-Value-Speicher. Den gibt's zum Beispiel auch im Internet Explorer 8.

Also einfach nur abspeichern, Farbe weiß, Farbe schwarz oder was auch immer.

Ja, entweder so oder man kann ja auch, Jason Strings abspeichern, dann kann's gerne auch ein bisschen komplexer werden. Aber, das Gute ist halt, der Internet Explorer 8 kann zum Beispiel DOM.storage. Das ist in dem felsenfest implementiert. Das macht der super. Das heißt, für dieses, Funklochszenario von wegen ich ruf meine To-do-Listen ab, auf und trag da jetzt Sachen ein, während die Verbindung hin und wieder mal wegklappt, das kann der genauso gut wie alle anderen.

Es kommt immer darauf an, was man will man erreichen. Also da, da ist durchaus einiges mit drin. Das Problem ist halt wirklich, die, die, das Modell der Webentwicklung ist auf so was im Moment, wie's heute gängig ist, noch nicht wirklich vorbereitet. Man müsste wirklich alles zweimal programmieren und so 'n Gebimsel, damit das alles abgefangen wird und die Synchronisation und so was alles. Da fehlt's noch 'n bisschen an Methoden und Frameworks, glaub ich.

Aber an sich ist das schon, auf einem guten Weg, würd ich sagen.

Also um es ganz verständlich auszudrücken, könnt ich sagen, das ist eine Art der Cookie-Setzung und, mit Cookies arbeiten. Ganz vereinfacht runtergebrochen.

Sehr vereinfacht runtergebrochen. Es kann natürlich wesentlich mehr, aber es geht halt wirklich darum, du, rufst dein-- Also das Idealszenario ist das folgende: Du hast deine To-do-Listen-App, du rufst es auf und du ziehst den, den, die Netzwerkverbindung und arbeitest einfach weiter und machst dir gar keine Gedanken mehr darum. Und das kriegt man damit hin. Im Moment nur in Firefox und, und Safari und den modernen Konsorten, aber irgendwann sehr bald auch in allen.

Da sind wir wirklich relativ nah dran. Das Problem ist wirklich die Entwicklung von solchen Sachen, weil das ist noch nicht, da fehlt's noch einfach an, an Grundlagen, an, an Frameworks und so was.

Ja genau, da wollt ich auch grad noch mal nachhaken, wie das so in der Praxis aussieht, weil so was hat man ja jetzt noch nicht an jeder Ecke überall.

Nicht an jeder Ecke, aber es gibt zum Beispiel irgend so 'n, es gibt zum Beispiel, 'ne Mootools-Bibliothek, die ich kenne, nicht verwende, aber, als, ach, das ist aber nett mal wahrgenommen habe. Die speichert Daten serverseitig, Quatsch, kleinseitig mit allen Mitteln, die zur Verfügung stehen. Du sagst ihm einfach, speicher das und dann guckt er, was für 'n Browser hab ich und was kann der alles? Und dann speichert er das irgendwie ab.

Entweder in 'ner, in 'ner SQL-Datenbank, wenn's WebKit ist, in Dom.storage, wenn's Internet Explorer 6 ist oder wenn's irgendwie Opera 7 sein sollte, legt er 'n Cookie damit an. Aber das macht der und das speichert der und der holt ja auch die Daten wieder raus. Also das ist 'n Beispiel für so 'n Framework, das einem wirklich hilft, wenn man seinen Hirn ausschalten kann, einfach nur sagt: „Speichern. Ich will gar nicht genau wissen, wie das geht. Speicher einfach. Mach."

Sehr schön.

Und das, und das klappt, relativ gut. Das Problem ist halt eben bei den Cookies, die sind eher instabil als jetzt zum Beispiel eine Datenbank, aber ist halt immer so 'n besser als nichts, ne?

Dann kommen wir, kurz bevor wir zum Fazit kommen, noch mal zu einer sehr interessanten Geschichte, nämlich Geolocation. Benutzt der ein oder andere von uns ja in abgewandelter Form, wenn er mit seinem iPhone oder Mobiltelefon durch die Gegend, rast und, loggt sich ein bei Govalla oder Foursquare. Das ist in Zukunft, dank HTML auch in, HTML5, auch im Browser möglich. Erzähl uns da mal 'n bisschen was drüber.

Ja, das ist eigentlich eine relativ simple Sache. Man, geht hin, sagt dem, sagt dem Browser: „Gib mir mal die Position", dann muss der Nutzer bestätigen, dass er auch die Position rausgeben möchte. Nicht, dass sie irgendwie belauscht wird. Und dann kann man entweder einen Überwachungsprozess zurückbekommen, also so ein, eine Überwachung in einem Intervall. Dann kann man also wirklich, das geht mit 'nem iPhone ganz wunderbar.

Dann geht man auf eine, solche Seite und lässt sich dann zum Beispiel die Geokoordinaten ausgeben und läuft durch die Gegend und sieht richtig, aha, der trackt mich jetzt. Oder man kann auch alternativ einfach nur: Gib mir die Position einmal und, fertig. Das Gute daran ist, das ist nicht notwendigerweise, von der Konzeption her auf, online verbunden sein angewiesen. Solche Konstruktionen laufen ja im Moment meist über irgendwelche IP-Lokalisationssachen und so. Alles ganz schrecklich.

Das Ding kann von der Konzeption her theoretisch auch ohne Webanbindung funktionieren, weil es dann zum Beispiel auf den in einem Telefon verbauten GPS-Chip zurückgreift.

Das müsste man aus, auf Entwicklerseite dann umsetzen oder ist das eher 'ne Browsergeschichte?

Das ist 'ne Browsergeschichte. Man selbst sagt bloß Geolocation, gib mir Position. Und das Ding hat auch wirklich mehrere Kanäle, über das das 'ne, Position halt beziehen kann. Entweder eben, es hat 'n, 'n GPS-Chip in 'nem Telefon oder es gibt, bei Linux zum Beispiel gibt's so 'n Geolocation-Daemon. Wenn der läuft, holt sich der Firefox die Daten von da. Das geht auch schon.

Ich finde, da ist der Job auch ganz gut aufgehoben.

Genau. Das Gute ist aber, der, der, der, der letzte Ausweg ist, wenn kein GPS-Chip und kein Geolocation-Daemon und nichts von all dem vorhanden ist, dann nimmt das Ding einfach die, Web Location Services von Google, also ganz altmodisch über IP und, den ganzen Krempel. Irgendwelche Daten kriegt man immer raus.

Also insgesamt ist es sehr, sehr interessant, weil wir unsere Tweets derzeit sogar anfangen, mit 'ner Geolocation, auszustatten. Oder wenn wir uns vorstellen, ich möchte jetzt, einkaufen und irgendwas in der Nähe halt vergünstigt bekommen und, bin jetzt gerade mit dem Browser unterwegs, dann macht das natürlich Sinn. Aber wie sieht es denn jetzt wirklich tatsächlich Stand heute mit der Unterstützung seitens der Browser aus?

.

Ziemlich mau noch.

Ja, also in den meisten Browsern ist das mau, aber braucht man im IE6 Geolocation? Brauchst du im iPhone, das brauchst du im Android und da geht das ziemlich gut.

Also die unterstützen das schon.

Android 2.0 glaub ich, ja. Und, iPhones schon ziemlich, ziemlich lange, also dieser Safari. Und, auf Desktop-Seite ist das im Firefox 3.5 oder 3.6, glaub ich drin, aber, ja, das ist halt die Frage. Auch da ist es wirklich immer relativ einfach, dann 'n Fallback zu bauen. Man guckt halt einfach dann im JavaScript nach: Pass auf, Browser unterstützt du?

Wenn ja, gib mir die Daten aus der Geolocation und wenn nicht, dann, bastel ich halt, mir die Informationen über 'ne ganz altmodische IP-Lokalisierung oder so was. Es ist halt wieder auch hier ein nettes Extra, wenn man halt mit dem Telefon durch die Gegend läuft und genauso eine Position halt, immer wissen möchte oder solche Sachen und kein Netz hat.

Und es ist also jetzt sagen wir mal nicht jetzt so der, der, der, der Oberhammer von der Funktion her, würde ich sagen, aber schon ganz praktisch, dass man das hat.

Also 'n praktischer Anwendungsfall, teste ich grad auf dem iPhone, noch mit der Beta-Version ausgestattet und das ist noch das alte iPhone 3G. Aber es gibt, check.in heißt die Webadresse auch dazu. Ein, Dienst von, weiß ich jetzt nicht.

Brightkite.

Brightkite, danke schön. Damit kannst du dich, quasi direkt in zwei Dienste einloggen, in drei Dienste, nämlich Brightkite, Gowalla und Foursquare, was,, dich davon abhält, quasi drei Applikationen hintereinander zu starten. Funktioniert auf meinem Telefon ein bisschen mäßig, aber ist auf jeden Fall 'ne interessante Geschichte.

Oder man benutzt einfach nur Foursquare. Ja, also mein Gefühl ist super viel Spannendes dabei, aber so die, die Schnittmenge von, von den Dingen, die wirklich in, ja, browserübergreifend oder, ja, sagen wir mal, wenigstens, in, in großen Teilen der Browser funktionieren, ist, glaube ich, noch relativ klein, oder? Also was sind denn so die, ja, sagen wir mal, so die drei Dinge, mit der man, mit denen man sich jetzt, nach der Sendung auf jeden Fall sofort beschäftigen und irgendwo einbauen sollte?

Peter. Es kommt, es kommt ein bisschen drauf an, was man halt machen will. Wenn man der, wenn man mehr so jetzt der Webdesigner ist, der weiterhin, Firmenauftritt für Beispiel Müller GmbH baut, dann gibt das ja gar nicht so wahnsinnig viel Neues, mit dem man sich jetzt zwingend befassen müsste. Es gibt jetzt diese neuen semantischen Elemente.

Da darf man auch mal die Frage stellen: Wem würde es denn jetzt theoretisch nutzen, wenn ich die einbauen würde, angesichts der Unsicherheit, die damit einhergeht? Können andere Programme, über die wir noch gar nicht nachgedacht haben, also Screenreader oder so, damit umgehen? Was passiert dann, mit dem Google Crawler? Verschluckt der sich daran vielleicht, wenn ich meine Überschriftenebenen jetzt danach ausrichte?

Da würde ich mich noch ein bisschen zurücklehnen und gucken: Was wird das denn so? Also was man jetzt als Otto Normal-, HTML-Krieger sicherlich, nutzen kann, ist die, sind die diversen Vereinfachungen und Vereinheitlichungen, die damit einhergehen. Also den einfachen Doctype einfach schreiben, zum Beispiel. Aus den Script- und Style-Elementen einfach das rauslassen oder bei der Syntax sich halt so ein bisschen Sachen rauspicken.

Das hier ist XHTML, das ist blöd, das will ich nicht mehr nutzen, das rausnehmen. Man kann die-

Von den wirklich, wirklich spannenden Dingen, die so vorne rum auch was bewegen und nicht nur hübsch semantisch sind. Was geht da so?

Formulare definitiv, weil die haben ja ein, ein eingebautes Fallback zum Textfeld, was in den meisten Fällen ziemlich, ziemlich sinnvoll ist. Wenn man also eine Situation hat, in der man ansonsten nicht mit Widgets um sich schmeißen würde, kann man das einfach nutzen, die neuen Elemente, wohlwissend, dass auf jeden Fall, egal wie die Formularunterstützung im Browser aussieht, das Formular benutzbar bleibt.

Also wenn man jetzt, jetzt akut mit einem Wort, mit einer Änderung im HTML seinen Blog verbessern möchte, dann sollte man zu seinem Formular, Kommentarfeld gehen und das, E-Mail-Feld von Type Text auf Type E-Mail umstellen. Das kostet nix, das tut niemandem weh. Und, der erste Opera-Nutzer, der da versehentlich was Falsches eintippt, wird es einem danken. Er wird's einem wahrscheinlich nicht danken, aber der wird dankbar sein. Das ist zum Beispiel 'ne Sache.

Und, was wir noch gar nicht angesprochen, was ich mal ganz kurz angeschnitten hab, ist, sind Data-Attribute. Das ist ganz praktisch. Man kann sich buchstäblich neue HTML-Attribute ausdenken in der Form, dass man, das Attribut, wie folgt nennt: Data, D-A-T-A, Strich und dann eine beliebige andere Zeichenkette. Die kann man sich aussuchen. Mal angenommen, ich hätte jetzt 'ne Liste mit,, was weiß ich, 'ne Liste mit, mit, mit, mit, mit Musikern, mit Bands.

Und ich hätte jetzt einen Eintrag, da würde ich jetzt drin aufführen, Iron Maiden zum Beispiel. Dann müsste ich ja irgendwie damit, mitgeben, was das für eine Band ist. Bei Iron Maiden müsste ich irgendwie sagen, das ist Heavy Metal. Wie bringe, bringe ich jetzt diese Information so unter, dass die im HTML drinnen ist, dass ich die mit JavaScript zum Beispiel auswerten kann, aber unsichtbar. Wie mache ich das? Das geht mit so einem Data-Attribut.

Da würde ich halt einfach sagen Data Strich Genre, ganz normales Attribut draus machen, Gleichheitszeichen, Anführungszeichen, Heavy Metal, Anführungszeichen zu und einfach in das Li-Element reinschreiben: Es ist Iron Maiden. Dann hätte ich also diese Information da drin, könnte zum Beispiel jetzt mit jQuery beigehen, könnte dieses Li-Element ansteuern, könnte dieses Attribut rauspicken und damit irgendwas anmachen. Zum Beispiel, was weiß ich, alle Heavy-Metal-Bands, rot einfärben nachträglich.

Mittelgutes Beispiel. Aber man kann halt wirklich da, beliebige unsichtbare Informationen in das HTML reinstopfen. Das ist ganz praktisch.

Und alles, was einem,, irgendwie höchstens passieren kann, ist, dass das irgendwie nicht, nicht, durch ältere Validatoren geht, oder?

Was heißt durch ältere Validatoren? Sobald man da oben ja das HTML5, den HTML5-Doctype drübersetzt, ist es HTML5. Also-

Klar, aber, also-

Es kann überhaupt nichts schiefgehen dabei. Das ist einfach ein un-unbekanntes Attribut für alle Programme, die sich darum scheren.

Ja, okay.

Es ist einfach, völlig nett. Das sind, das sind so diese ganzen Kleinigkeiten, so diese, diese syntaktisch neu zulässigen Sachen. Das würde genauso gut gehen mit XHTML, da wär's halt nicht korrekt.

Also wenn ich, keine Ahnung, nehmen wir mal beispielsweise den IE sechs oder so was, wenn ich da, mit der, mit der Data-Geschichte halt arbeite und dann über, über JavaScript auf irgendwas zugreife, ich komme ja auf jeden Fall da ran, wo ich ran will, oder? An die-

Genau, das Ding, das, das Ding ist einfach da. Der, der, der, der, der Browser fragt sich halt wahrscheinlich nur: „Was will der Typ von mir?" Ja, aber damit, damit kommt das schon klar.

Solche Kleinigkeiten sind so für den, für den, für den Otto-Normal-Webworker wirklich ganz praktisch. Also mittlerweile habe ich mich dran gewöhnt. Ist 'n bisschen schwierig, die aus diesen siebenhundert Seiten Spezifikation halt rauszufiltern. Aber wenn man die dann erst mal hat, ist das schon ein, ist das 'ne nette Erweiterung der eigenen, der eigenen HTML-Werkzeugkiste.

Und wenn man dann 'n bisschen, bisschen nerdiger werden möchte, dann kann man wirklich mit dem Canvas-Element tolle Sachen anstellen. Dank dieses tollen Scripts – wir müssen alle Google danken – Explorer Canvas, was eben dieses, dieses Umformen vornimmt. Von Canvas-Befehlen für den Internet Explorer auf VML kann man das Ding wirklich bedenkenlos an allen Fronten einsetzen. Es gibt zum Beispiel dieses Schriftersatzungsscript, Cufón. Das hat sicherlich schon mal der eine oder andere gesehen.

Das läuft auch in jedem Browser, das verwendet Canvas. Solche Sachen. Also ist jetzt die Frage: Was ist der, was ist jetzt der Use Case dafür? Für Otto-Normalverbraucher-Webseite braucht man keine frei bemalbare Fläche. Aber, ne, wenn man so was mal braucht, ist das sicherlich, sagen wir mal, im Vergleich zu Flash, was dann die Alternative wäre, wahrscheinlich die bessere Lösung. Es gibt für Canvas auch schon ganz tolle Bibliotheken.

Es gibt da zum Beispiel 'n Port, von Processing, dieser Sprache für die Beschreibung von – was war das? –, Graphen? Ich weiß es nicht mehr. Es gibt ganz tolle, Statistikbibliotheken, mit denen man wunderbare Charts malen kann mit dem Canvas-Element. Das ist alles kinderleicht zu bedienen, das läuft in jedem Browser, ist 'ne ganz super Sache. Prima.

Und wenn wir dann darüber hinausgehen, dann wird's halt zunehmend 'n bisschen, bisschen schwieriger mit den, mit den, mit den Use Cases, weil's halt eben mit der Implementierung noch nicht überall so ist. Wenn man also jetzt sich zum Beispiel mal die, von Google I/O die Keynotes anguckt, wie sie da alle mit ihren HTML5-Features rumprotzen, das geht auch, aber, in maximal halt zwei Browsern. Heutzutage.

Wann fangen wir an, über HTML6 zu reden?

Wann wir anfangen? Ich glaub, wir haben schon längst angefangen. Also die Frage ist die folgende: Ich hatte ja, glaub ich, am Anfang mal gesagt, wird HTML5 jemals so ein stabiler Webstandard werden wie im Moment HTML4. Da ist zu bedenken, dass, eigentlich die Entwicklung von HTML6 schon begonnen hat. Es gibt nämlich 'n, in den Spezifikationen der WhatWG ein neues, Element. Das nennt sich Device.

Das soll, dazu gut sein, an den Computer angeschlossene Geräte wie zum Beispiel Webcams oder so was einzufangen und damit dann im Browser irgendwelche Sachen zu machen. Und das ist kein Teil von HTML5 mehr. Was es ist, weiß man noch nicht. Man spricht so von HTML6. Das W3C hat das, das Device-Element, glaub ich, wieder in eine eigene Spezifikation ausgelagert..

Gut, aber genauso fangen komische Leute an, von, von Web 3.0 zu reden, also.

Ja, also die, die Sache ist halt die folgende: Wir, wir können mal durchrechnen. Die Entwicklung von HTML4, also sagen wir mal, die Spezifikationen, aus denen irgendwann mal das wurde, was jetzt, das hat die WhatWG-HTML-Spezifikation, das wovon HTML5 ja 'ne Teilmenge ist. Das hat angefangen 2004. So. Sechs Jahre später, also heute, haben wir die ersten Bücher darüber. Und HTML6 mit der Entwicklung hat bereits angeko, angefangen.

Wir haben schon drüber gesprochen, dass, in zwölf Jahren, also 2022, mit der Standardisierung von HTML5 gerechnet wird. Hatten wir ja gesagt, hat der

Rechnerischerweise ja.

Ja, also, entweder wird HTML5 nie zum Webstandard, weil das ganze Entwicklungsmodell unversioniert wird. Das heißt, es gibt irgendwann kein HTML5 mehr, sondern alle sehen ein, das wird alles ei, werden alles Einzelspezifikationen, wie im Moment das Device-Element. Das ist alles beim, im Korpus von WhatWG HTML drin, beim W3C was eigenes. Ist ja auch Wurst, ist irgendwie 'ne Technologie, die halt entwickelt wird. Und dann gibt's vielleicht in Zukunft keine große HTML-Version mehr.

Und die andere Möglichkeit ist, dass 2022 wirklich HTML5 zum Webstandard wird und uns das völlig egal ist, weil wir alle schon an, an, an HTML7 dran sind.

Wenn wir uns so 'n bisschen, von dem, von dem ganzen Versionschaos da mal lösen würden, dann hätten wir auf jeden Fall den Vorteil, dass wir nicht so die Erwartung haben, dass alle zehn Jahre so ein Sprung im Web kommt, sondern wir das alles schön nebenbei machen können.

Das gab's ja eh nie. Also ich glaub, HTML4 und, mh, das Ganze, was halt sozusagen uns ins Web 2.0 gebracht hat bis kurz vor HTML5. Das alles hat sich ja nur so stabilisiert, weil halt, die Browserentwicklung stillstand. Danke IE6. Wenn die Entwicklung, an allen Browserfronten so weitergegangen wäre, wie es im Moment der Fall ist, dann wär das ja nie so stabil geworden.

Dann hätten wir jetzt ja schon längst, wären wir ja schon längst in diesem – ich will's nicht Chaos nennen – aber in dieser dynamischen Entwicklung wären wir ja schon längst, wären wir ja schon längst, da wären wir schon längst in begriffen, ne. Also, ich, ich, ich glaub ehrlich gesagt nicht an den Webstandard HTML5, so wie wir das heute von HTML4 kennen. Das wird nix mehr. Und wenn, wie gesagt, interessiert's dann keinen mehr.

Dennoch dein, dein Fazit: Einsetzen? Ja oder nein?

Ja, weil ich mir den anderen Doctype nicht merken kann. Nein, aber wirklich. Man muss halt, man mu-- man, wenn man so, wenn man weiß, was man tut und sich so wirklich diese Sachen, rauspickt, von denen man weiß, die funktionieren und die bringen mir was. Warum nicht? Es läuft, ja. Also, ich kann nur immer wieder sagen, Canvas-Element, das muss man sich einfach auf den Schirm holen, was man damit alles machen kann.

Dann denke ich, ist es 'n perfekter Übergang zum Schluss dieser Sendung. Diese Technikwitz-Sendung gibt's nämlich auch zum Nachlesen quasi, wie praktischerweise in deinem neuen Buch. Ist jetzt quasi super frisch erschienen. Wir haben's wie gesagt schon aufm Schreibtisch liegen. „HTML5: Webseiten innovativ und zukunftssicher“, erschienen im Open Source Press Verlag. Könnt ihr euch überall bestellen.

Bei Amazon ist es derzeit noch nicht verfügbar, weil die so 'n kleines Problem damit haben, aber ich denke, das wird sich dann in naher Zukunft erledigt haben Auf jeden Fall.

Ist ja auch noch nicht so lang dabei.

Auf jeden Fall, wollen wir zwei Exemplare dieses, brandneuen Buches verlosen.

Genau. Und dafür müsst ihr Folgendes machen:, zweierlei Voraussetzungen erfüllen. Zum einen uns dreien und der Technikwürze folgen und, ja, zum anderen einfach frei, wie euch beliebt, positiv oder negativ mit, Kritik oder Lob behaftet, einfach mal twittern über diese Sendung. Damit wir das Ganze auch so 'n bisschen, tracken können, bitte einfach mal mit dem Hashtag HTML5TV versehen.

Genau, alles zusammengeschrieben.

Klingt alles viel komplizierter, als es ist. Wir verlinken das alles auch noch mal, verlinken auch unsere, Twitter-Accounts noch mal und verlosen dann, wie gesagt, zum einen, zwei Exemplare, dieser Sendung zum Nachlesen sozusagen. Mit natürlich noch, deutlich mehr Tiefe und, Zusatzinformationen. Und ich leg noch mal dreißig Euro in iTunes-Gutschein on top. Lohnt sich also diesmal wirklich.

Okay, perfekt. Nehmt dran teil, twittert fleißig und wie gesagt, was ihr genau, wen ihr folgen müsst bei Twitter, um dran teilzunehmen an dieser Verlosung, das seht ihr noch mal auf Technikwürze.de. Ich danke auf jeden Fall, Peter Kründer, dass du dabei warst.

War mir ein Vergnügen, wie immer.

Demnächst wirst du auch auf unserer Technikwürze-Teamseite verewigt sein, weil du hast jetzt, den Grundstein gelegt sozusagen mit dieser Sendung, dass du in den erlesenen Kreis aufsteigen darfst. Dazu gibt's auch demnächst 'n Bildchen von dir. Ansonsten-

Das, was sich hier so als Ankündigung anhört, ist eigentlich eher intern als Drohung und, Druckmacherei, gemeint, denn der Peter sollte schon viel länger am Start sein auf unserer Teamseite natürlich.

Aber nur intern. Er hat ja 'ne Ausrede mit sei, in Form seines Buches.

Der kriegt das schon hin. Ja, Peter-

Glaubt denen kein Wort.

Ich glaub, wir haben das ganz gut, hinbekommen. Mit, mit wir mein ich halt dich, Peter.

Danke schön.

Vielen Dank. Vielen, vielen Dank. Und, ja, ich freu mich auf eine rege Diskussion in unseren Kommentaren.

Genau, für euch war auch dabei Marcel Böttcher und mein Name ist David Maciejewski. Wir hören uns wieder nächste Woche, wenn es wieder heißt Technikwürze, euer, ja, Podcast für Webstandards und so, ne. Bis dahin.

Bis dann. Ciao.

Tschüss.

Mehr Qualität im Webdesign durch Webstandards. Tipps und Tricks zur Umsetzung findet ihr bei den Webkrauts auf Webkrauts.de. Für ein besseres Web. Weitere Informationen und die Links zur Sendung auf Technikwürze.de.

Und eine eingebaute, Validierungsschnittstelle. Das ist das, das Hauptsächliche. Die, Eingabefelder sind so Sachen wie... Tut mir leid, ich bin vorhin-

Ja, dann komm doch erst mal.

Ich bin etwas-

Hol erst mal Luft.

Ich bin se, ich bin sehr, ich bin sehr in Form. Ich bin ja eigentlich Fußballer und relativ... Aber ich hab letzte Nacht, glaub ich, einfach nicht gut genug geschlafen. Ich bin noch mal eben kurz in den Keller geretz. Komm hier lassen. Ich werd alt. Was war, was war, was waren die längsten Outtakes, die ihr je hattet?

Ja, wir haben die Outtakes bisher immer weggeschmissen. Das ist die erste Sendung, wo wir Outtakes aufheben wollten.