Im Juli letzten Jahres kam die Diskussion um responsive images in Webseiten auf. Wir können zwar mittlerweile die tollsten Layouts für verschiedene Endgeräte optimieren, aber die inhaltlichen Bilder (<img>-Elemente) bleiben dabei immer die gleichen. Und damit hat man natürlich einen großen Nachteil: Große Bilder für Desktopauflösungen werden auch bei Mobilgeräten in voller Dateigröße geladen. Andersherum kann für ein mobile optimiertes Bild kein qualitativ passendes Bild auf ein iPad3 mit HighRes-Display ausgegeben werden. Deshalb waren mehrere Leute der Meinung, dass Bilder ebenfalls responsiv werden müssen.

Historie und Initiativen

Die eine Fraktion der Interessierten wollte direkt ein streamendes Bildformat, was durchaus eine sehr gute und anstrebenswerte Lösung wäre. Allerdings werden damit Randbereiche wie andere Bildausschnitte nicht abgedeckt. Außerdem würde das neue Format wohl erst in frühestens zehn Jahren überall einsetzbar sein. Die andere Fraktion hingegen beschränkte sich auch deshalb auf HTML und CSS als Möglichkeiten. Zu dieser Fraktion gehörte auch ich und deshalb veröffentlichte ich in der Diskussion über das Problem und mögliche Lösungen auf der WHATWG-Mailingliste Ende Juli 2011 folgenden Vorschlag:

<img 
    src="http://cdn.url.com/img/myimage_xs.jpg" 
    media-xs="(min-device-width:320px and max-device-width:640px)" 
    media-xs-src="http://cdn.url.com/img/myimage_xs.jpg"  
    media-m="(min-device-width:640px and max-device-width:1024px)" 
    media-m-src="http://cdn.url.com/img/myimage_m.jpg"  
    media-xl="(min-device-width:1024px)" 
    media-xl-src="http://cdn.url.com/img/myimage_xsl.jpg" 
/>

Dieser wäre prinzipiell mit alten Browsern kompatibel gewesen, da er auf dem bereits existenten img-Element basiert und gleichzeitig eine einfache Syntax für alternative Ressourcen enthält – diese würden über über ganz normale CSS3 @media-queries angesteuert.

Der große Nachteil bei dieser Lösung ist, dass das bisher bekannte src-Attribut nach aktueller Logik der Browser immer geladen werden würde. Im Zweifelsfall lädt der Browser also zunächst das in src referenzierte Bild (das immer das kleinste Format sein sollte) und zusätzlich das passende höher auflösende Bild. Es würden also zusätzliche HTTP-Requests und mehr Datenmengen anfallen, als eigentlich erforderlich. Dies könnte jedoch für moderne Browser aufgehoben werden, wenn die Browserhersteller bei der Implementierung berücksichtigen. Hier war zumindest von Browserseite schnell eine ablehndende Haltung vorhanden, da angeblich größerer Aufwand nötig sei.

Nach ein paar Antworten schlief die Diskussion in der WHATWG Mailing Liste jedoch schnell ein. Das schlimme daran war jedoch, dass viele damals der Meinung waren, dass solch eine Lösung nicht gebraucht werde, da ja offenbar kein Bedarf für responsive images da sei. In diesem Zuge schrieb Ian Hickson selbst im Januar noch

What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.

Im Nachhinein ist diese Entwicklung insofern fatal, als dass einige dieser Leute nun im Mai 2012 einen First Draft für die WHATWG veröffentlicht haben. Als ich aber unterwarteterweise im Oktober 2011 wieder auf das Thema angesprochen wurde und auch mehrere Leute wieder anfingen über das Thema in Blogbeiträgen zu diskutieren, wendete sich zunächst das Blatt. Erneut kam das Thema auf die WHATWG-Mailingliste, wiederum jedoch nicht wirklich mit großer Resonanz.

Gründung der W3C Community Group "Responsive images" und das <picture>-Element

Plötzlich wurde im Februar 2012 dann vom W3C eine Community Group "Responsive images" eingerichtet. Eine Community Group ist eine Plattform, auf der jeder, der mitmachen möchte, über spezifische Probleme mit HTML/CSS diskutieren kann. Damit war endlich ein Ort geschaffen, an dem sinnvoll über Vor- und Nachteile der diversen Code-Vorschläge und der zu eruierenden Funktionalitäten und Eigenschaften diskutiert werden konnte. Schnell wuchs die Gruppe auf über 70 Teilnehmer heran, rege Diskussionen wurden geführt, Lösungen vorgeschlagen und verworfen. Letztlich blieb nur noch ein Vorschlag übrig: das <picture>-Element. Dabei handelt es sich um ein komplett neues Element, das kein Standard-Browserverhalten mitbringt, wie es das bisherige img-Tag macht, das aber eben mehrere Ressourcen beinhalten kann. Die dazugehörige Syntax sollte wie folgt aussehen:

<picture alt="Alt tag describing the image represented">
    <source src="photo.jpg" />
    <source src="photo@2x.jpg" media="min-device-pixel-ratio:2" />
    <img src="photo.jpg" />
</picture>

Es handelt sich also um eine Liste an Bildern in <source>-Elementen, angereichtert und abgefragt nach Media Queries, plus ein mögliches Fallback-img-Tag am Ende für ältere Browser. Der Vorteil dieser Technik ist, dass Bilder nicht automatisch geladen werden und nur das angefordert wird, was wirklich nötig ist. Das funktioniert sogar bereits, denn Scott Jehl hat hierzu auf GitHub den sogenannten picturefill entwickelt, einen Polyfill für das <picture>-Element. Sogar eine eine Methode zum bereits heute standardkonformen Einsatz gibt es. Diesen Vorteilen stehen aber auch einige ungelöste Probleme gegenüber.

Da wäre zum Beispiel die Frage der Ladezeit bei Geräten mit hoher Auflösung. Bloß weil ein iPad3 mit hochauflösendem Display ein Bild anfordert, ist ja noch lange nicht gesagt, dass dieses auch schnell geladen wird. Ist man beispielsweise per GPRS unterwegs, was zumindest in Deutschland dank knapp bemessener „Flatrates“ häufig der Fall ist, so möchte man vielleicht auch auf einem Highres-Bildschirm die kleine Variante des Bildes haben. Da stößt man nun mit den bisher zur Verfügung stehenden Media Query-Abfragen auf Probleme, denn eine Bandbreitenabfrage ist für einen Browser extrem schwierig durchzuführen. Auch die Syntax ist nicht unproblematisch; schließlich ist der ganze Spaß mit einigem Mehraufwand verbunden, wenn ich für jedes Bild mehrere Ressourcen angeben muss und für jede Ressource noch Media Queries festlegen muss.

Matthew Willcox beschäftigte sich deshalb intensiv in den letzten Wochen mit Möglichkeiten, die Media Query-Vergabe zu automatisieren. Am 13. Mai 2012 brachte er einen umfassenden Lösungsansatz heraus, der vorsieht, dass in <meta>-Tags eine Art Template festgelegt wird und mit (noch zu spezifizierenden) HTML-Variablen diese Template-Variablen in den Ressourcenlisten eingesetzt werden können. Auch wenn ich persönlich dem konkreten Vorschlag nicht ganz zustimme: ein Templateverhalten in <meta>-Tags festzulegen wäre eine Möglichkeit mit Variablen schnell und einfach HTML zu schreiben. Das wäre nicht nur für das <picture>-Element sehr praktisch sondern auch für viele andere Anwendungen. Willcox‘ Ansatz sieht im HTML folgendermaßen aus:

<head>
    <meta name="case" data="breakpoint1" media="min-width:350px" />
    <meta name="case" data="breakpoint2" media="min-width:1000px" />
</head>
<body>
    <img src="/content/images/{case}/photo.jpg" alt="" />
</body>

Im CSS ist dazu noch folgendes Format vorgesehen: Statt

@media only screen and (min-width: 700px) { ... }

soll nun

@media (case: breakpoint1) { ... }

geschrieben werden können.

WHATWG Vorschlag: responsive images via srclist-Attribut

Zum Streitpunkt wurde das Thema responsive images, als die WHATWG am 15. Mai einen ganz eigenen Entwurf für responsive images online stellte. Das kam sehr überraschend für die meisten – auch für mich, zumal man selbst auf den WHATWG-Mailinglisten vorab nicht allzuviel darüber lesen konnte. Ich war ehrlich gesagt etwas vor den Kopf geschlagen, als ich von diesem Entwurf hörte; hauptsächlich, weil die Syntax, die der Vorschlag verwendet, extrem unübersichtlich und HTML-untypisch ist:

<img src="face-600-200@1.jpeg" alt=""
     set="face-600-200@1.jpeg 600w 200h 1x,
          face-600-200@2.jpeg 600w 200h 2x,
          face-icon.png       200w 200h">

<img src="logo.png" alt="SampleCorp" set="logo-HD.png 2x">

Die Angabe 600w 200h ist nicht, wie man vielleicht vermuten würde, eine Größenangabe des Bildes (so war es ja im <img>-Tag immer gewesen), sondern die Angabe der Viewportgröße. Das heißt, hier wird eine Art Mini-Media-Query angegeben. Für mich birgt allein das schon ein extrem großes Fehlerpotential für den normalen Webentwickler. Zudem gibt es eine auflösungbasierte Angabe @1x oder @2x, mit der die Auflösungen notiert werden. Bietet man @1x also mit 96ppi an, muss man @2x automatisch mit 192ppi bereitstellen. Auch hier entsteht eine weitere Fehlerquelle. Und es gilt am Ende immer noch das Prinzip: der Nutzer muss ausbaden, was der Entwickler falsch gemacht hat. Wird diese Syntax also genauso eingeführt muss man befürchten, dass Entwickler Fehler generieren, die dazu führen, dass ein User auf eine Smartphoneseite mit einem LowRes-Gerät geht und ein HighRes-Bild ausgeliefert bekommt oder ähnliche Szenarios. Das wäre fatal und sollte wenn irgendwie möglich vermieden werden.

Das Resultat dieser Aktion der WHATWG war vorhersehbar: die Web-Community stand innerhalb von wenigen Stunden Kopf, wobei das vielleicht größte Problem an dieser Geschichte die Kommunikationsweise der WHATWG war. Ich versuche nun mein Bestes, die hunderten von E-Mails, Blogposts und dazugehörigen Kommentare zu sortieren und einzuordnen.

Das Kommunikationsproblem, was passierte und wie es dazu kam

Mehrfach hatte ich mit einigen Community-Membern den Versuch unternommen Browser-Hersteller mit in die Community-Group einzubinden. Der Erfolg war mäßig, denn außer einem Opera-Mitarbeiter meldete sich überhaupt niemand zu Wort, weder von Apple (Safari) noch von Google (Chrome), Mozilla (Firefox) oder Microsoft (Internet Explorer). Und nun, nachdem die Community Group mehrere Monate verschiedene Lösungswege durchdacht und sogar praktisch getestet hatte, wird kommentarlos ein komplett eigener Entwurf angenommen! Dieser kam übrigens von Apple – Apple hatte bereits zur iPad3-Einführung eine etwas eigenwillige CSS4 Responsive Images-Lösung eingeführt.

Leider scheint man in der WHATWG nicht einmal von der Existenz der Community Group etwas mitbekommen zu haben. Das jedoch kann ich mir schwerlich vorstellen, hatten wir nicht nur WHATWG-Mitglieder direkt angesprochen, sondern auch diverse Fachblogs und -portale, die darüber berichteten. Nebenher tauchte der Link zur Gruppe auch in den WHATWG-Mailinglisten auf. Dennoch wurde der Spezifikationsentwurf veröffentlicht und zunächst einmal gar nicht auf andere Vorschläge eingegangen. Das führte unweigerlich auch zu verbalen Auseinandersetzungen, die sicher vermeidbar gewesen wären.

Am 16. Mai hat sich zumindest Tab Atkins (Google) zu Wort gemeldet und versuchte die Wogen zu glätten. Seltsamerweise hat jedoch kaum jemand auf die Argumente, die gegen diese Sourcelist-Version der WHATWG sprechen, geantwortet. Ich denke, hier wird das letzte Wort auch nicht gesprochen sein, es wird viele lange Diskussionen geben, wie es sie bereits vor knapp einem Monat zur Vendor-Prefix-Debatte gegeben hat. Nicht zuletzt hat das W3C angekündigt, die Problematik bei ihrem nächsten Treffen (wöchentlich) anszusprechen und sich ihrer anzunehmen.

Mein Zwischenfazit

Ich persönlich hoffe, dass es in Zukunft eine sinnvoll strukturierte, für jeden Entwickler anwendbare Syntax für responsive Bilder geben wird und nicht einmal mehr sich die Browserhersteller mit einer schnell umzusetzenden Lösung auf Kosten der Entwickler durchsetzen. Das bedeutet aber auch, dass die Lösung noch ein wenig mehr Zeit einnehmen wird, bevor sie richtig eingesetzt werden kann. Doch gut Ding will bekanntlich Weile haben.

Dieser Artikel ist Teil einer Serie:

1. Fragen zu HTML5 & Co 1
2. Fragen zu HTML5 & Co 2
3. Fragen zu HTML5 & Co 3
4. Fragen zu HTML5 & Co 4
5. Fragen zu HTML5 & Co 5

Als Erklärbär für HTML5 und andere Webtechnologien bekomme ich jede Woche neue Fragen rund um Webentwicklung gestellt. Da diese Fragen (und Antworten) viel zu schade sind, um sie in meinem E-Mail-Archiv verrotten zu lassen, hole ich sie im Rahmen der Artikelserie „Fragen zu HTML5 und Co“ regelmäßig ans Tageslicht – denn dumme Fragen gibt es schließlich nicht!

Wann welches Element verwenden?

Wann sollte man <mark> verwenden und wann <strong>, <em>, <b>, und <i>?

Es stimmt, dass all diese Elemente auf den ersten Blick so ziemlich das gleiche zu machen scheinen und es nicht immer ganz einfach, das richtige Element zu wählen. Anhand von Beispielen bekommt man am besten ein Gefühl dafür, was wann richtig ist und die gute Nachricht an dieser Stelle ist: es gibt in den HTML5-Spezifikationen offizielle Beispiele, hier für <em>. Eine der großen Errungenschaften von HTML5 ist nicht zuletzt die Qualität der Spezifikationen. Während man in den offiziellen Dokumenten zu HTML 4.01 nur sehr spärliche Erläuterungen und Beispiele findet (wenn überhaupt) sind die HTML5-Specs voll mit Beispielen, Tutorials und erklärender Prosa.

Wenn man also ein Beispiel oder eine Erklärung sucht, kann der Blick in den offiziellen Standard durchaus lohnen. Wem die offiziellen Specs mit ihrem monströsen Umfang etwas zu abschreckend erscheinen, könnte mit den Web Developer Editions von W3C und WHATWG (ja, davon gibt es gleich zwei, eine von jeder Arbeitsgruppe) glücklich werden.

Um aber die eigentliche Frage zu beantworten:

• <strong>: Wichtige Textpassagen, deren Wichtigkeit die Bedeutung des betroffenen Satzes nicht verändert.
• <em>: Betonte Textpassagen, deren Betonung die Bedeutung des betroffenen Satzes verändert.
• <b> und <i>: Textpassagen, die vom Rest abgesetzt, aber nicht auf- oder abgewertet werden sollen. Beispiele wären Produktnamen in einem Review oder Wörter aus anderen Sprachen. Dabei sollte man <b> verwenden, wenn die typografische Repräsentation der betroffenen Passage üblicherweise fetter Text wäre und <i>, wenn es kursiver Text wäre.
• <mark>: Hervorhebung von Textpassagen, die in einem nicht aus ihrem Ursprungskontext heraus eine Hervorhebung verdient hätten, sondern die nur aufgrund eines speziellen Umstandes relevant sind – z.B. weil sie ein Keyword sind, nach dem der Nutzer gesucht hat.

XLink und XHTML5

Für XML-basierte Sprachen wie z.B. SVG gibt es doch die Sprache XLink. Wäre es rein theoretisch auch möglich, sie in XHTML5 einzubinden?

XLink kann man theoretisch schon in XHTML verwenden. Es ist schließlich alles nichts weiter als XML und die (X)HTML5-Spezifikationen erlauben die Verwendung des XLink-Namespaces auch ausdrücklich. Das Problem ist nur, dass es meiner Recherche nach so gut wie gar keine Browserunterstützung gibt. Einzig der Firefox scheint Teile von XLink für SVG- und MathML-Dokumente zu implementieren.

<nav> und ARIA

Macht es Sinn, das <nav>-Element und WAI-ARIA in Kombination zu verwenden, also z.B. als <nav role="navigation">? Oder ist das doppelt gemoppelt? Das <nav> macht doch eigentlich schon deutlich, dass es sich um eine Navigation handelt …

Das ist in der Tat zumindest laut Standard doppelt gemoppelt, denn diese ARIA-Role wird Nav-Elementen automatisch zugeteilt. In der Realität sieht die Sache aber schwieriger aus. Wie man dieser Tabelle hier entnehmen kann, haben die wenigsten Browser heutzutage diese ARIA-Mappings auch wirklich standardkonform implementiert.

Was tun? Rumprobieren und testen. Es mag zwar falsch sein, <nav> zu verwenden, aber wenn das der einzige Weg ist, die Navigation auch für Screenreader als solche auszuzueichnen (und ich weiß nicht, ob das der Fall ist – was machen Browser, die <nav> unterstützen, lesen die dann zwei mal „Navigation“ vor?), dann sollte man sich nicht aufhalten lassen. Regeln sind da, um (nach Kenntnisnahme und gründlichem Nachdenken) gebrochen zu werden.

Selektive Anwendung von CSS-Regeln auf Links

Ich verwende Attributselektoren, um externe Links zu markieren. Hierfür suche ich jetzt eine Erweiterung: Ich habe einen Share-Button von Add this integriert und in der Javascript-Box stören diese Markierungen. Wie kann der Code a[target=_blank]{} erweitert werden, so dass die Regel nicht für eine bestimmte Ziel-URL gilt?

Hier gibt es zwei mögliche Lösungen und jeweils helfen die Attributselektoren für Substrings, die in CSS3 frisch eingeführt wurden. Zum einen kann man eine bestehende Markierung für alle Links, deren href-Attribut mit einer bestimmten URL beginnt, einfach zurücksetzen …

/* Externe Links markieren... */
a[target="_blank"]{
    background: yellow;
}

/* ... und die Markierung wieder zurücksetzen */
a[href^="http://www.facebook.com"]{
    background: none;
}

… oder man greift zur Negations-Pseudoklasse (:not()) und wendet die Markierung gar nicht erst auf Links mit der betreffenden URL an:

/* All-in-one-Lösung */
a[target="_blank"]:not([href^="http://twitter.com"]){
    background: yellow;
}

Beide Lösungen führen zum gleichen Ergebnis, allerdings funktioniert die :not()-Variante im Internet Explorer erst ab Version 9.

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Formspring bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.

Mein größtes Problem war der Unity-Launcher, den ich aus alter Gewohnheit im Autohide-Modus betreibe. Bei Multi-Monitor-Setups wird, selbst wenn auf einem Monitor kein Launcher ist, die Maus an der entsprechenden Bildkante eingefangen. Resultat: man kann nicht mehr ohne weiteres die Maus von einem Monitor auf den nächsten schieben, da sie unterhalb einer gewissen Bewegungsgeschwindigkeit am Rand hängen bleibt. Sehr ekelhaft, aber auch leicht zu reparieren: den CompizConfig Configuration Manager installieren (sudo apt-get install compizconfig-settings-manager) und im Unity-Plugin unter „Experimental“ folgende Einstellungen vornehmen:

• Launcher Reveal Pressure: 1
• Launcher Reveal Edge Responsiveness: 8
• Launcher Capture Mouse: deaktivieren

Mit diesen Einstellungen verhält sich der Launcher bei Multi-Monitor-Setups wieder genau wie vor den Update.

Was ich noch nicht gelöst habe, ist die Hintergrundfarbe vom Dash und vor allem von den Notifications. In 12.04 wird diese ja automatisch aus dem Wallpaper errechnet, was bei mir leider im Farbton „Moppelkotze“ resultiert:

Die diversen Konfigurations-Tools, die vorgeben dies ändern zu können (Ubuntu Tweak, Unity-Plugin im CCSM) scheinen alle keinen Effekt zu haben. Weiß jemand von euch vielleicht wie oder ob man das hinkriegt? Denn bis auf diesen Schönheitsfehler finde ich nicht viel zu meckern: alles läuft und das nach nur minimalem Gefrickel sogar besser als vorher. Gefällt mir!

Dieser Artikel ist Teil einer Serie:

1. Fragen zu HTML5 & Co 1
2. Fragen zu HTML5 & Co 2
3. Fragen zu HTML5 & Co 3
4. Fragen zu HTML5 & Co 4
5. Fragen zu HTML5 & Co 5

In den letzten Wochen und Monaten habe ich wie gewohnt via E-Mail, Twitter, Formspring und andere Kanäle Fragen zu HTML5 gestellt bekommen und beantwortet. Da wie immer gilt, dass es keine dummen Fragen, aber sehr viel öffentliches Interesse gibt, präsentiere ich hiermit einen weitereren Teil der allseits beliebten Serie „Fragen zu HTML5 und Co“ mit den neuesten Fragen und Antworten rund um unser liebstes Hype-Thema und den diversen dazugehörigen Webtechnologien.

Section-Elemente in Header-Elementen?

Ein Section-Element kann ja ein Header- oder ein Footer-Element beinhalten. Geht es aber auch anders herum? Im konkreten Fall geht es um ein Header-Element mit einem Warenkorb- und Kundenbewertungsbereich. Wäre es semantisch korrekt dafür ein Section-Element zu verwenden?

Erlaubt es eine solche Konstruktion auf jeden Fall – ob sie auch semantisch korrekt ist, hängt vom betroffenen Inhalt ab, aber ich denke im genannten Fall passt es. Generell gilt: Header- und Footer-Elemente dürfen jedweden Flow-Content enthalten, der selbst kein Header- oder Footer-Element ist. Flow-Content umfasst dabei so ziemlich alles, was es für Content bestimmten HTML-Elementen so gibt.

Wie baut man große JavaScript-Apps?

Da ich viel mit Actionscript gearbeitet habe, habe ich immer noch nicht den Sprung zu JS gewagt, da ich immer noch das Gefühl habe, das JS mehr dieses Prototyping-Dingsda macht statt mit Klassen zu arbeiten. In AS und PHP zB. habe ich meine Klasse mit Constructor und den Methoden und Eigenschaften und kann das ganze schön in eine Datei packen und KlasseA nennen.

Wie sieht denn ein allgemeiner Workflow in JS aus? Ich sehe immer nur irgendwelche Codschnipsel, aber ich habe noch nicht wirklich begriffen, wie man komplexere Programme in JS wirklich umsetzen kann (z.B. nach MVC), also dass man die einzelnen Funktions- und Logikeinheiten sinnvoll organisiert.

Das „Prototyping-Dingsda“ in JS (prototypische Vererbung) ist eigentlich simpler und mächtiger als Veerbung via Klassen. Objekte erben direkt von anderen Objekten und die Zwischenkonstruktion „Klasse“ fällt einfach weg. Und das beste: Klassensysteme kann man via Prototypen implementieren. Wenn du also unbedingt möchtest, kannst du problemlos Klassen in JavaScript bekommen. Links:

• http://ejohn.org/blog/simple-javascript-inheritance/
• http://dustindiaz.com/klass
• http://mootools.net/docs/core/Class/Class
• http://code.google.com/p/base2/

Was App-Struktur angeht, kommt es drauf an, was du genau in JS machen möchtest. Serverseitige Umgebungen wie Node bieten z.B. ein Modulsystem. Ansonsten gibt es auch für den Browser viele fertige Lösungen aus der Dose. Diesen Artikel über RequireJS in Zusammenarbeit mit AMD (asynchronous module definition) würde ich mal exemplarisch durchlesen. Was MVCeske Konstruktionen angeht, gibt es auch mehrere Lösungen. Unter anderem diese hier sind empfehlenswert:

• Backbone
• Knockout.js
• JavaScript MVC

Für große Apps allgemein würde ich mir mal diese drei kurzen Talks reinziehen, die alle Themen rund um große JavaScript-Apps streifen.

Webcam-Chat mit HTML5?

Ich suche eine Möglichkeit, mit HTML5 Webcam-Chats zwischen bis zu vier Personen zu verwirklichen. Ich habe dabei die jQuery Webcam-API entdeckt, aber es erscheint mir, als ob es hier lediglich um die Möglichkeit geht die Webcam anzusprechen und es nicht möglich ist das Bild auch irgendwie an andere zu übertragen. Ist es nicht möglich, Webcam-Daten zu kopieren und vor allem an andere übertragen?

Was Webcam-Chats angeht, habe ich eine gute Nachricht und eine schlechte Nachricht. Die Gute ist, dass Webcam-Chat (inklusive Sound, d.h. Skype-klonen) tatsächlich bei den klugen Köpfen rund um HTML5 eine Rolle spielt. Es wird aktiv daran gearbeitet und das Ganze läuft unter dem Titel WebRTC. Die schlechte Nachricht ist, dass WebRTC noch eine in einer sehr frühen Phase steckt und noch nicht ernsthaft benutzbar ist – außer in Chrome-Nightlies läuft die API noch nirgendwo und ich möchte wetten, dass die ganze Technologie noch einige größere Änderungen vor sich hat. Da hilft, fürchte ich, erst mal nur Geduld.

Warum kein new Array() in JavaScript?

In diesem Artikel und dem besprochenen Buch heißt es Finger weg von new Array(). Wieso?

Neue Arrays macht man in JavaScript am einfachsten (weil am kürzesten) mit dem Literal []. Es gibt keinen Grund, sich mit new Array() einen Wolf zu tippen, denn das bringt gegenüber [] keine Vorteile. Im Gegenteil: new Array() macht, je nachdem wie viele Argumente man ihm mitgibt, sehr unterschiedliche und teils verwirrende Dinge:

var a = new Array(3);     // Leeres Array mit length = 3
var b = new Array(3, 14); // Array [3, 14]
var c = new Array(3.14);  // RangeError: Invalid array length

All den Stress hat man mit [] nicht – da kommt einfach ein Array mit genau den Elementen heraus, die man hineingesteckt hat.

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Formspring bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.

Man kann unter Zuhilfenahme dieses Bildchens sehr anschaulich und vor allem zeiteffektiv ein paar wichtige Dinge über HTML5 erklären. Zum Beispiel sieht man sehr schön

• das Verhältnis der beiden HTML5-Spezifikationen nebst den jeweiligen Web Developer Editions zueinander sowie zum Alltagsbegriff „HTML5“ (alles Teilmengen voneinander),
• dass neben W3C (blaue Kreise) und WHATWG (grün) noch viele weitere Parteien das Web aufmischen (orange) und dass HTML5 nicht alles ist, was das Web Neues zu bieten hat,
• den schieren Umfang des ganzen neuen Zeugs (jeder Kreis repräsentiert ein eigenes, unter Umständen sehr umfangreiches Spezifikationsdokument),
• dass es richtig komplizierte Sonderfälle in diesem ganzen Web-Zirkus gibt (die eingestellte Web SQL Database, die aus einer API und einem Protokoll bestehenden Web Sockets),
• und dass jQuery und Node.js wirklich nichts mit HTML5 zu tun haben und das auch bei CSS3 eine eher problematische Einordnung ist.

Da ich mindestens zwei mal pro Monat eine E-Mail bekomme, in der gefragt wird, wo man denn diese Grafik herkriegen kann und ob man sie in Slides/Büchern/Abschlussarbeiten verwenden darf, steht das gute Stück ab jetzt offiziell unter einer Creative Commons Namensnennung 3.0 Deutschland Lizenz und hat ein ein Github-Repository für Bugreports und Weiterentwicklung. Es gibt (mit Inkscape gebaute) SVGs sowie PNGs und jeweils eine Variante mit weißem und eine mit schwarzem Hintergrund. Macht damit was ihr wollt!

• 7. - 9. Mai 2012 in München: HTML5-Schulung bei der Open Source School. Mein drei­tä­gi­ges HTML5-Standardprogramm stattet die Teilnehmer im Druckbetankungsverfahren mit (so gut wie) allem aus, was man zu HTML5 wissen muss, von semantischem Markup bis hin zu Canvas-Frameworks. Die Themen sind im Einzelnen:
  • Hintergründe und Entstehungsgeschichte
  • Geolocation und Gerätesensorik
  • HTML5-Schnelleinstieg
  • Semantisches HTML5
  • HTML5-Formulare
  • Offline-Webanwendungen
  • Multimedia im Browser
  • Web Workers
  • Die File-API
  • Polyfills
  • Das Canvas-Element
  Geboten wird ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch gibt es obendrein.
• 10. -11. Mai 2012 in München: CSS3-Schulung bei der Open Source School. Mein zweitä­gi­ges CSS3-Standardprogramm katapultiert die Teilnehmer in das CSS3-Zeitalter, in dem Webfonts und Farbverläufe fließen. Das gesamte Programm:
  • Hintergründe und Entstehungsgeschichte
  • CSS3-Selektoren
  • Farben und Farbverläufe
  • Boxen und Rahmen
  • CSS3-Layout
  • Transformationen
  • Transitionen und Animationen
  • Schrifteinbettung und -gestaltung
  • Media-Queries
  Ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch als Bonus gibt es auch hier.

Dieser Artikel ist Teil einer Serie:

1. ES6 im Überblick
2. Block Scope und Konstanten

Anders als im ECMAScript 5 rüstet ES6 nicht nur hier und da ein paar Funktionen nach, sondern bietet für viele Neuerungen neue Syntax und Konzepte, wobei einschränkend gesagt werden muss, dass viele der „Neuheiten“ so neu gar nicht sind. Das Meiste ist irgendwo geklaut: aus proprietären Browser-Erweiterungen, aus CoffeeScript, anderen Programmiersprachen oder gar aus dem gescheiterten ES4-Standard. In diese Kategorie der nicht ganz so neuen Neuheiten fallen auch die neuen blockgebundenen Variablen (let) und Konstanten (const), um die es in diesem Artikel geht. Die neuen Features funktionieren zur Zeit in allem, was auf neuere V8-Engines aufsetzt, also Chrome und Node, wobei es nicht mehr lange dauern dürfte, bis auch andere JS-Implementierungen nachrüsten. Wenn es endlich so weit ist, haben die JavaScript-Programmierer dieser Welt zwei Probleme mit Variablen weniger.

Zwei Probleme mit Variablen

Problem Nummer 1 ist, dass in ECMAScript 5 und älter der Geltungsbereich von Variablen die Funktion ist, in der sie deklariert wurden. Wenn man den folgenden Schnipsel ausführt …

function foobar(foo){
    if(foo){
        var bar = 42;
    }
};

… wird der Code interprtiert, als hätte man das folgende geschrieben:

function foobar(foo){
    var bar;
    if(foo){
        bar = 42;
    }
};

Dieses Verhalten bringt es mit sich, dass man, wenn man Variablen innerhalb von Blöcken deklariert, damit auch die Umwelt außerhalb der Blöcke verunreinigt:

function foobar(foo){
    if(foo){
        var bar = 42;
    }
    // "bar" ist hier auch noch 42
};

Das mag zwar in vielen Fällen wie dem obrigen nicht groß stören, in anderen hingegen schon:

var bar = { 'hallo': 1337 };

function foobar(foo){
    if(bar[foo]){
        return bar[foo];
    }
    else {
        var bar = 42 * 666;
        return bar;
    }
};

var x = foobar('hallo'); // Na, wer weiß was hier passiert?

Selbst wenn dieses Verhalten nicht oft zu Problemen führt, so ist es doch weder ist es sonderlich intuitiv, noch wird es wirklich gebraucht. Im Gegenzug ist es recht mühsam, in ECMAScript 5 und älter Variablen auf Blöcke zu beschränken, denn außer sofort ausgeführten Funktionen hilft hier nichts:

function foobar(foo){
    whatever();
    if(foo){
        (function(){
            var bar = 42;
        })();
    }
    // "bar" ist hier undefined
};

Das funktioniert zwar, ist aber der Code-Eleganz nicht besonders zuträglich und für alle mit eher mittlguten JavaScript-Kenntnissen unnötig verwirrend.

Das zweite Problem ist, dass es in ECMAScript 5 und älter eben nur Variablen und keine Konstanten gibt. Es existieren zwar Konventionen, gemäß derer man Variablen durch Allcaps-Namen als „Konstanten“ kennzeichnet, doch das allein hält im Zweifelsfall niemanden davon ab, die „Konstante“ zu überschreiben:

var KONSTANTE = 42;

KONSTANTE = 1337; // Funktioniert!

Die einzige in ES5 denkbare Lösung besteht darin, mittels Property Descriptor die gewünschte Konstante als nicht-überschreibbare Eigenschaft auf einem Objekt anzulegen:

Object.defineProperty(window, 'KONSTANTE', {
    writable: false,
    enumerable: true,
    configurable: false,
    value: 42
});

KONSTANTE = 1337; // TypeError: Cannot assign to read only property 'KONSTANTE'

Auch hier gilt: das funktioniert zwar, aber als ersthafte Lösung kann man dieses Konvolut wohl niemandem verkaufen. ECMAScript 6 schafft nun die Probleme rund um Konstranten und var aus der Welt, indem mit let und const zwei Alternativ-Formen von Variablen eingeführt werden.

Lösung 1: let statt var

Verwendet man zur Deklaration einer neuen Variable das Schlüsselwort let statt var, so erhält man eine an den Block gebundene Variable, die jenseits ihrer Schleife oder Kontrollstruktur nicht sichtbar ist. Damit bleiben zum Beispiel die Zähler einer For-Schleife ausschließlich innerhalb der Schleife gültig:

for(let i = 0; i < 4; i++){
}
console.log(i); // ReferenceError: i is not defined

Hierfür braucht es nicht zwingend echte Kontrollstrukturen oder Schleifen, auch bei leeren Blöcken funktioniert let:

{
    let i = 42;
}
console.log(i); // ReferenceError: i is not defined

Aus der Blockbindung folgt, dass let-Deklarationen nur in einem Block, in Funktionscode oder auf Programmebene vorkommen dürfen:

if(true) var i = 42;    // Klappt
if(true) let i = 42;    // SyntaxError: Illegal let declaration in unprotected statement context
if(true){ let i = 42; } // Klappt

Ansonsten verhält sich let ziemlich genau wie var und unterliegt auch den gleichen Einschränkungen – auch let window = 42 kann in einem Browser das Window-Objekt nicht überschreiben. Insgesamt ist let also nichts weiter als ein repariertes var, dass im JavaScript-Code der Zukunft ersteres in den meisten Fällen anstelle von var ersetzt werden dürfte.

Lösung 2: const statt var

Mit const lassen sich echte Konstanten anlegen, die auch wirklich nicht überschrieben werden können:

const KONSTANTE = 42;
KONSTANTE = 1337; // TypeError: Cannot assign to read only property 'KONSTANTE'

Genau wie let-Variablen sind auch const-Konstanten an ihren Block gebunden:

if(true){
    const KONSTANTE = 42;
}
console.log(KONSTANTE); // ReferenceError: KONSTANTE is not defined

Anders als Variablen (egal ob let oder var) müssen Konstanzen logischerweise auch immer mit einem Wert initialisiert werden:

var foo;   // Kein Problem
let bar;   // Kein Problem
const BAZ; // SyntaxError: Unexpected token ;

Auch wenn JavaScript nun echte Konstanten kennt, ist es sinnvoll, auch bei deren Verwendung weiterhin den Bezeichner komplett groß zu schreiben – so ist immer klar, wann man es mit einer Variablen oder einer Konstanten zu tun hat.

Der Status

Über let und const besteht in der ES6-Arbeitsgruppe weitgehend Konsens und die noch offenen Fragen (nachzulesen auf den entsprechenden Wiki-Seiten) betreffen allesamt Sonderfälle. Aufhalten lassen werden sich diese Features nicht mehr. Und so zeigt die allmächtige Kompatibilitätstabelle schon recht viel grün, doch echte Unterstützung für let und const findet sich zur Zeit nur in den V8-Engines von Chrome ab Version 18 und Node.js. Ab Firefox Version 2.0 sowie einigen anderen Browsern existieren auch Implementierungen von let und const, die jedoch nicht mit dem ES6-Standard kompatibel sind und die man daher weiträumig umfahren sollte.

Dieser Artikel ist Teil einer Serie:

1. Fragen zu HTML5 & Co 1
2. Fragen zu HTML5 & Co 2
3. Fragen zu HTML5 & Co 3
4. Fragen zu HTML5 & Co 4
5. Fragen zu HTML5 & Co 5

Auch wenn das Weblog den Großteil der letzen Monate stillgelegt war, habe ich natürlich wieder per E-Mail, Twitter, Formspring und andere Kanäle so manche Frage zu HTML5 beantwortet. Diesmal war sogar eine Frage zu JavaScript dabei, um die ich mich natürlich auch gerne kümmere – auch in Sachen CSS, DOM und amderem Webkrempel kann man mich jederzeit löchern! Und weil einige der zuletzt eingegangenen Fragen wieder erheblich zu schade für fortwährende Geheimhaltung waren, werden sie hiermit als ein weiterer Teil der beliebten Serie „Fragen zu HTML5“ befreit.

HTML-Validierung

Nach der Umstellung des doctypes schlägt die Validierung unserer Seiten mit dem W3C-Validator an vielen Stellen fehl - einige davon konnte ich fixen, aber bei den Meta-Tags bin ich nicht ganz sicher, was ich tun soll. Beispiele:

Bad value DC.Subject for attribute name on XHTML element meta: Keyword dc.subject is not registered.
<meta name="DC.Subject" content="" />

Bad value DC.Date for attribute name on XHTML element meta: Keyword dc.date is not registered.
<meta name="DC.Date" content="2011-12-19T14:15:48" />

Die entsprechenden Meta-tags rauszuwerfen ist keine Option, da die SEO-Abteilung sie behalten möchte. Was tun? Sie bei der WHATWG selber definieren bzw. ändern wie in wiki.whatwg.org/wiki/MetaExtensions beschrieben?

Ich würde zu aller erst mal die Option „einfach ignorieren“ in den Raum stellen. Das, was der Validator hier bemängelt, sind allein ungültige bzw. unbekannte Attribut-Angaben, aber so lange nicht die Struktur des HTML kaputt ist, wird das keinerlei negative Folgen für Browser und 99,99% der anderen Endgeräte haben. Was der Browser nicht kennt, ignoriert er einfach. Und wenn die SEO-Abteilung der Meinung ist, diese Meta-Tags wären wichtig, spricht nichts dagegen, sie einfach drin zu lassen. Das macht am wenigsten Arbeit und hat trotzdem keine großen Nachteile.

Unabhängig davon ist der Validator in Sachen HTML5-Syntax auch nicht die letzte Instanz und er hinkt oft etwas hinter dem Standard her. Gerade was kleinere Features angeht (wie z.B. welche Attribute erlaubt sind oder wann man &-Zeichen escapen muss und wann nicht), gibt er oft falsche Auskunft. Das einzige was also wirklich zählt, ist was im Browser funktioniert und was im Standard steht.

Infos zu Browserunterstützung

Auf den WHATWG-Seiten kann ich herausfinden, welcher Tag in den aktuellen Versionen von Safari, Chrome, Firefox und IE unterstützt wird. In Ihrem Buch, z.B. auf Seite 92, 182-13, geben Sie aber die Browser-Versionen exakt an, z.B. Firefox 3.6. Wie kommen Sie zu diesen detaillierten Angaben im Vergleich zur Spezifikation? Haben Sie dies selbst ausprobiert oder steht dies auf einer Website?

Ich habe das seinerzeit selbst durchgetestet und aus diversen Quellen zusammengetragen. Mittlerweile gibt es mit caniuse.com aber eine hervorragende Webseite, die detaillierte Kompatibilitätstabellen zu allem Möglichen sammelt – HTML5, CSS3 und vielem mehr.

Zahlen parsen mit JavaScript

Kannst du mit sagen wieso parseInt('08') 0 ist und parseInt('02') 2?

Das ist einer der vielen „Bad Parts“ in JavaScript. Die Funktion parseInt() macht zwar die Strings zu Zahlen, aber Zahlen mit führender Null werden von Browsern als Oktalzahl behandelt. Das ist im Standard so gar nicht vorgesehen und damit ein Browserbug, der zum Glück vom Strict Mode in ES5 abgestellt wird.

Update-Aufforderungen

Was hältst du von Browser-Update-Aufforderungen in IE auf Seiten, die IE < 8 nicht unterstützen?

Eine Webseite (nicht Webapp) kann man immer in eine für alte Browser komumierbare Form bringen, zur Not, indem man alten IEs einfach alle Styles entzieht. Eine Update-Aufforderung bei gleichzeitig nicht mehr funktionierender Seite fände ich an dieser Stelle einfach nur faul. Wer sich die Mühe macht, eine Update-Aufforderung zu bauen, der kann auch schnell einen auf die Basics reduzierten IE6-Stylesheet anlegen.

Bei Webapplikationen ist das etwas anderes. Wenn bestimmte HTML5-Features zwingend gebraucht werden, ist es OK, entsprechende Systemanforderungen zu formulieren. Wenn das alle anderen Programme auf dieser Welt dürfen, warum nicht auch die Webapps?

Formularvalidierung steuern

Gibt es bei der HTML5 Formularvalidierung eigentlich auch die Möglichkeit, dass man bei dem Kick auf einen bestimmten Submit-Button nicht validiert? Also quasi ein novalidate-Attribute für einen Button bzw. Input-Submit.

Bei Formularen mit mehreren Seiten (z.B. Bestellvorgang) möchte ich einen Zurück-Button verwenden, bei welchem allerdings nicht zwangsläufig das ganze Formular ausgefüllt sein muss. Dennoch sollen bereits ausgefüllte Felder übermittelt werden, was einen normalen Link bzw. die history ausschließt. Hast du eine Idee?

Eine solche Möglichkeit existiert, funktioniert aber nur in wenigen Browsern. Es gibt das novalidate-Attribut für Formulare, mit dem man die Validierung für das gesamte Formular deaktivieren kann und es gibt das formnovalidate-Attribut für Submitbuttons. Wenn man dieses für die speziellen Submits verwendet (also für die, die keine Validierung auslösen sollen) findet die Prüfung nur beim normalen, finalen Submit sattt und nicht mehr bei den Zwischenschritten. Alle weiteren Details verraten die Spezifikationen.

Webfonts und Canvas

Gibt es eine Einschränkung für das Verwenden von Schriftarten in Canvas-Elementen? Ich würde gerne Googles Webfonts verwenden …

Eine Einschränkung gibt es an sich nicht. Das Problem mit Webfonts und Canvas ist nur, dass die Webfonts vollständig geladen sein müssen, bevor man sie auf der Canvas verwenden kann. Und soweit ich weiß, gibt es keine native Möglichkeit in allen Browsern zuverlässig den Zeitpunkt abzupassen, ab dem die (normal via @font-face in CSS eingebetteten) Webfonts da sind. Die Verwendung von Font.js oder Googles WebFont Loader könnte Abhilfe schaffen.

Weitere Fragen?

Eure Fragen zu HTML5, CSS und anderen Webthemen beantworte ich gerne! Einfach eine E-Mail schreiben oder Formspring bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.

Dieser Artikel ist Teil einer Serie:

1. ES6 im Überblick
2. Block Scope und Konstanten

ECMAScript 5 darf man spätestens seit dem Erscheinen des Internet Explorer 9 getrost als die aktuelle, tatsächlich benutzbare Version von JavaScript bezeichnen. Alle neueren Versionen der verbreiteten Browser sowie auch Node.js unterstützen den neuen Standard so weit, dass sich Entwickler nur noch von ganz alten Browser-Fossilien aufgehalten fühlen dürfen. Damit wird es also höchste Eisenbahn, sich mit der nächsten Java-Script-Version, ECMAScript 6 (auch Harmony genannt) zu befassen. Dieser Artikel ist der Auftakt zu einer Serie, die der Reihe nach der einzelnen ES6-Features unter die Lupe nimmt, sobald sie in mindestens einem Browser vernünftig implementiert sind. Dieser Beitrag betrachtet zunächst nur das Drumherum; richtig technisch wird es erst im nächsten Teil.

Geschichtlicher Überblick

Wie in der Artikelserie zu ECMAScript 5 beschrieben, handelt es sich bei ES5 um ein ein eher vorsichtiges Update, bei dem die Wahrung der Abwärtskompatibilität über allem steht. Dies ging naturgemäß so manchen Entwickler nicht weit genug und so wurde gefordert, man möge doch bitte die große Axt herausholen und JavaScript von Grund auf reformieren. Das ist allerdings nicht ganz so einfach wie es sich anhört. Schon Version 4 von ECMAScript sollte mit allerlei neuen Features aufwarten, doch zwischen den verschiedenen Interessengruppen kam es nicht zur Einigung. Nach Meinung Einiger uferte das Updatepaket aus und man konnte sich nicht darüber verständigen, wie weit und wie schnell man die Entwicklung vorantreiben sollte.

Als klar wurde, dass es sehr Unterschiedliche Auffassungen über die Zukunft von ECMAScript gab, schwiegen sich die an der Arbeitsgruppe beteiligten Partien zunächst ein Jahr lang gegenseitig an. Da sich aber auch dieser Zustand nicht als besonders vielversprechend heraussetellte, einigte man sich schließlich darauf, die Entwicklung der Sprache in kleineren Schritten voranzutreiben. Zunächst wurde mit ECMAScript 5 die Sprache vor allem ausgemistet. Die wenigen neuen Features waren entweder schon praxiserprobt (z.B. Function.prototype.bind) oder wurden mit viel Mühe so konzipiert, dass sie unter keinen Umständen mit bestehenden Scripts im Web kollidieren konnten (z.B. Strict Mode, Objekterweiterungen).

Mit ES5 wurde ein Fundament gelegt, aus das zukünftige Versionen der Sprache aufsetzen konnten, was mit ES6 nun langsam Realität wird. Zwar kommt die Anzahl der Neuerungen für die sechste Version der Sprache nicht an das heran, was mit ES4 geplant war, aber für Web-Verhältnisse kann sich der Umfang des Gebotenen durchaus sehen lassen.

Ein Rüstprogramm für JavaScript

ES6 ist ein vergleichsweise großes Rüstprogramm für JavaScript. Das Standardisierungskomitee um Brendan Eich war teilweise durchaus willens, auch radikalere Umbauten vorzunehmen und so zum Beispiel Köpfe von Kontrollstrukturen ohne Klammern zuzulassen:

if foo > 42 {
    bar++;
}

Obwohl diese eine Änderung aller Voraussicht nach nun nicht den Weg in den Standard finden wird, demonstriert sie doch sehr schön die Geisteshaltung, mit der an das Projekt ES6 herangegangen wurde: JavaScript sollte gründlich um- und aufgebaut werden! Letztlich sind es wesentlich mehr Aus- als Umbauten geworden; bestehende Scripts samt und sonders nicht mehr lauffähig zu halten, war dann doch etwas viel verlangt. Die komplette Liste der Features, die sich (ziemlich sehr) sicher im neuen Standard wiederfinden werden gibt es im ECMAScript-Wiki. Einige Highlights:

• Features, die man für selbstverständlich halten würden, die aber bisher immer gefehlt haben (z.B Konstanten und Vorgabewerte für Funktionsargumente)
• Zusätzliche Datenstrukturen wie Maps und Sets
• Zahlreiche aus Python und ähnlichen Sprachen gemopste Features (z.B. Generatoren und Iteratoren)
• Ein Modulsystem, Proxies, Binärdatentypen und weitere Neuerungen
• Ein Klassensystem
• Sowie auch eine Handvoll Bugfixes (z.B. gibt typeof null in ES6 sinnvollerweise auch tatsächlich 'null' anstelle von 'object' zurück)

Wie immer bei Webstandards müssen wir natürlich auch das, was auf dem Papier steht, mit dem vergleichen, was in der Realität existiert. Dort ist zwar noch nicht viel von dem neuen Standard angekommen, doch das was schon da ist, kann sich in aller Regel sehen lassen.

Status und Unterstützung

ECMAScript 6 selbst ist Stand Anfang 2012 noch kein fertiger Standard, aber die meisten Teile der Spezifikationen sind schon recht stabil. Anders als bei anderen Webstandards funktioniert JavaScript wirklich fast genau so, wie man es von einem Standard erwartet: erst kommt das Papier, dann folgen die Implementierungen. So gibt es verglichen mit den ebenfalls unfertigen Standards HTML5 und CSS3 bisher nur punktuelle Browserunterstützung.

In Chrome Canary, einem experimentelle Chrome-Build, findet man (Stand Anfang 2012) von allen Browsern die meisten ES6-Features. Um in den Genuss von ES6 zu kommen, muss man unter about:flags den Punkt „Enable Experimental JavaScript“ aktivieren:

Danach stehen in allen Scripts, die im Strict Mode ausgeführt werden, die in Chrome Canary vorhandenen ES6-Features zur Verfügung. Auch in anderen V8-basierten Umgebungen kommt man in den Genuss der Features von Chrome – in Node.js lassen sich verschiedene ES6-Aspekte per Startparameter aktivieren (z.B. --harmony_weakmaps für Weak Maps).

Manche JS-Engines stellen die Neuheiten auch ohne zusätzliche Arbeit bereit, so zum Beispiel der Firefox. Es ist realistischerweise davon auszugehen, dass ich all diese Details zur Aktivierung von ES6 im Wochentakt ändern werden, doch vom Experimentieren mit den neuen Features muss das nicht abhalten – denn diese selbst sind schließlich weitgehend stabil.

Problematisch ist allein die fehlende Dokumentation. Neben dem Standard selbst gibt zur Zeit so gute wie gar keine Quellen, aus denen man Infos über ES6 beziehen könnte (z.B. Browser-Sourcecode und dazugehörige Unit Tests), aber genau dafür ist schließlich diese Artikelserie da.

Wie geht es weiter?

Dieser Artikel ist der Auftakt zu einer Serie, die die neuen Features von ES6 genauer beleuchtet. Zur Vorbereitung empfehle ich, die Artikelserie zu ES5 zu lesen – es ist schließlich immer sinnvoll, den ersten Schritt vor dem Zweiten zu tun. Die Serie wird nach und nach neue Teile erhalten wenn immer mehr ES6-Features in den Browsern verfügbar werden, wobei als erstes Thema voraussichtlich Block Scope und Konstanten auf der Agenda stehen – irgendwann in den nächsten Tagen.

Ziel und Ausgangslage

Das Ziel ist im diesem Beispiel, eine Webapp zu bauen, die drei durch JavaScript definierte Zustände hat: entweder steht in einem <p>-Element der Text „Foo“ oder „Bar“ oder das Element ist leer. Mittels Links soll zwischen den Zuständen hin- und hergeschaltet werden können. Üblicherweise würde man diese Webapp, die allein aus der Datei index.html besteht, in etwa wie folgt bauen:

<!doctype html>
<title>FooBar Beta 2.0</title>

<p>
    <a onclick="foo()" href="#">Foo-Zustand</a>
    <a onclick="bar()" href="#">Bar-Zustand</a>
</p>

<p id="content"></p>

<script>
    var content = document.getElementById('content');
    var foo = function(){
        content.innerHTML = 'Foo';
        return false;
    };
    var bar = function(){
        content.innerHTML = 'Bar';
        return false;
    };
</script>

Die Links lassen sich nun zwar anklicken um zwischen „Foo“ und „Bar“ hin- und her zu schalten, aber es fehlen eben die URLs für die beiden Zustände und auch der Zurück-Button des Browsers macht nicht das, was er soll. Das wollen wir ändern.

URLs für die Zustände

Wenn wir unsere beiden Links mit echten URLs ausstatten …

<p>
    <a onclick="foo()" href="foo">Foo-Zustand</a>
    <a onclick="bar()" href="bar">Bar-Zustand</a>
</p>

… ändert sich zunächst nichts, denn wenn die Links angeklickt werden, werden nur die Onclick-Handler aktiv. Die URLs selbst funktionieren nicht, denn unter diesen Adressen sind natürlich keine HTML-Seiten zu finden. Und das soll auch so bleiben; foo und bar sollen schließlich beide keine eigenen Dokumente sein, sondern unterschiedliche Zustände für index.html repräsentieren. Also leiten wir einfach die URLs für die beiden Zustände auf unsere App-Datei um:

RewriteEngine on
RewriteRule foo$ index.html [L]
RewriteRule bar$ index.html [L]

Nun führen alle URLs auf unsere Webapp. Um die App die beiden Zustände repräsentieren zu lassen, müssen wir nur noch die jeweilige URL auslesen und den entsprechenden Inhalt anzeigen:

// Beim laden der Seite die URL parsen und den richtigen Inhalt anzeigen
window.addEventListener('load', function(){
    // Letzte drei Zeichen der URL sind entweder "foo" oder "bar"
    var zustand = window.location.href.substr(-3);
    // Je nach URL mit Foo- oder Bar-Zustand starten
    if(zustand === 'foo'){
        foo();
    }
    else if(zustand === 'bar'){
        bar();
    }
}, false);

Wenn wir nun noch die onlick-Handler aus den Links entfernen …

<p>
    <a href="foo">Foo-Zustand</a>
    <a href="bar">Bar-Zustand</a>
</p>

… funktioniert die App inklusive URLs! Das ist allerdings auch kein Wunder, denn im Prinzip haben wir die App einfach de-ajaxifiziert. Jeder Klick auf die Links lädt jetzt die Seite neu, die dann wiederum die URL ausliest und per JavaScript den richtigen Content lädt. Wie re-ajaxifizieren wir nun die App so, dass sie sowohl URLs benutzt als auch nicht ständig neu lädt? Hier kommt die History API ins Spiel.

Das History-Script

Die meisten werden wissen, dass man die Browser-History per JavaScript ansprechen kann um zum Beispiel mit window.history.back() die Funktionalität eines Zurück-Buttons nachzubilden. Seit einiger Zeit erlauben moderne Browser nicht nur das Auslesen der History, sondern auch deren Manipulation. Wie immer bietet MDN einen detaillierten und gleichzeitig verbraucherfreundlichen Überblick, aber ganz kurz gesagt bietet die History-API folgende neuen Features:

• mit window.history.pushState() kann man einen neuen Eintrag in der Browser-History anlegen. Der Funktion übergibt man ein Status-Objekt, einen Titel und eine URL, die den neuen Status repräsentiert
• window.history.replaceState() ersetzt den aktuellen History-Eintrag, statt einen neuen anzulegen
• Das auf window feuernde popstate-Event teilt mit, wenn der aktuelle History-Eintrag wechselt, also wenn zum Beispiel der Nutzer auf den Zurück-Button klickt und damit einen Schritt in der History zurück geht.

Wenn wir nun möchten, dass unsere Links beim Anklicken nicht nur den Zustand ändern, sondern auch neue History-Einträge anlegen, ist das mit window.history.pushState() ein Kinderspiel:

// Beim Link-Klick den richtigen Inhalt anzeigen und die History anpassen
document.querySelector('a[href=foo]').addEventListener('click', function(evt){
    evt.preventDefault(); // Dies verhindert den "normalen" Aufruf der Link-URL
    history.pushState(null, '', 'foo'); // Neuer History-Eintrag "foo"
    foo();
});
document.querySelector('a[href=bar]').addEventListener('click', function(evt){
    evt.preventDefault(); // Dies verhindert den "normalen" Aufruf der Link-URL
    history.pushState(null, '', 'bar'); // Neuer History-Eintrag "bar"
    bar();
});

Die ersten beiden Argumente von window.history.pushState() sind ein Status-Objekt und der Titel für den Histroy-Eintrag. Beides brauchen wir in unserem Fall nicht; der Titel ist sowieso recht nutzlos und das Status-Objekt, das normalerweise den Zustand der App mit einen History-Eintrag verknüpfen würde (ändert sich der aktuelle History-Eintrag, dann ändert sich auch das Status-Objekt entsprechend) brauchen wir auch nicht. Unser App-Status ist komplett aus der URL abzulesen, also übergeben wir der Funktion nur die jeweiligen URLs foo und bar. Da wir ja schon den Code zum Parsen dieser URL im load-Event haben, brauchen wir diesen nur so umzubauen, dass er auch auf das popstate-Event reagiert.

// Wenn sich die History ändert oder die Seite neu lädt, den
// richtigen Zustand herstellen
var changeState = function(){
    // Letzte drei Zeichen der URL sollten entweder "foo" oder "bar" sein
    var zustand = window.location.href.substr(-3);
    // Je nach URL mit Foo-, Bar- oder Leer-Zustand starten
    if(zustand === 'foo'){
        foo();
    }
    else if(zustand === 'bar'){
        bar();
    }
    else {
        content.innerHTML = '';
    }
};
window.addEventListener('load', changeState, false);
window.addEventListener('popstate', changeState, false);

Der Statuswechsel wird nun nicht nur beim Laden der Seite ausgeführt, sondern auch, wenn sich der Nutzer durch die History bewegt. Es ist beim Umbau einzig darauf zu achten, dass der Zustand neben „Foo“ und „Bar“ nun ja auch via Zurück-Button wieder auf „Leer“ gesetzt werden kann, ansonsten bleibt alles beim Alten. Fertig ist die reine JS-App mit echten URLs und voller History-Funktionalität!

Browser, Tools und Links

Die History API wird von allen vernünftigen aktuellen Browsern unterstützt und ab Version 10 auch vom Internet Explorer, doch die einzelnen Implementierungen unterscheiden sich auf recht lästige Art und Weise. So feuern Beispielsweise einige Browser das popstate-Event beim Laden der Seite oder wenn sich der Hash ändert, andere nicht. Um sich all diese Probleme vom Leib zu halten und für ältere Browsern keine Extrawürste braten zu müssen, empfiehlt sich der Einsatz von History.js. Hiermit erhält man eine gemeinsame History-API für alle Browser, die sich genau wie das Original verhält, sämtliche Macken repariert und die auch mit allen gängigen JavaScript-Frameworks klarkommt. Weitere Links, die von Interesse sein könnten:

• Spezifikationen von W3C und WHATWG
• Liste der Unterschiede zwischen den diversen Browsern
• URI.js ist das Werkzeug der Wahl zum Parsen von URLs
• History.js vereinheitlicht die verschiedenen Browser