Peter Kröner • Webtechnologie • Weblog

Ubuntu 13.04 mit Konfiguratoren und Patches zurechtbiegen

Peter Kröner — Mi, 08 Mai 2013 15:33:54

Man kann es mit Ubuntu als Betriebssystem vergleichsweise gut aushalten, weil es gut funktioniert. kann man so ziemlich alles machen, und alle Dinge tun was sie sollen. Allein, die Art und Weise wie sie tun, das ist teilweise ganz schön diskutabel und so manche Design-Entscheindung verleitet geradezu zum Fazialpalmieren. Meine Wenigkeit erschlägt das Ganze immer mit ein paar zusätzlichen Stücken Software, die ich im Folgenden einfach mal aufliste – jedenfalls die Software, die ich im Moment bei Raring Ringtail 13.04 im Einsatz habe. Falls ihr noch mehr in dieser Richtung vorschlagen wollt: Ab damit in die Kommentare!

Neuen Nautilus loswerden: in Ubuntu 13.04 wird aus unerfindlichen Gründen Nautilus 3.6 verwendet, eine schlecht integrierte, fehlgeleitete Karikatur des vorherigen Dateimanagers mit der Versionsnummer 3.4 – hässliches Aussehen, Funktionen fehlen, Hotkeys tun es nicht mehr usw. Einen gepatchten, zu Ubuntu 13.04 kompatiblen Nautilus 3.4 gibt es bei Webupd8. Installieren und alle Probleme verschwinden.
Unity konfigurieren: Unsettings ist ein GUI zur Konfiguration von Unity. Neuerdings gibt es mit dem Unity Tweak Tool auch eine offizielle Lösung, aber warum die nicht standardmäßig installiert ist, ist mir schleierhaft. Aber beide Tools funktionieren ganz gut. Das Wichtigste ist die Auswahl der passenden Hintergrundfarbe für das Dash.
Gepatchtes Notify-OSD: Die Ubuntu-Notifications sind in ihrem Auslieferungszustand nicht konfigurierbar, also müssen eine gepatchte Version und ein damit kompatibler Konfigurator) her. Auch hier: Hintergrundfarbe das wichtigste, Kontrolle über Positionierung und Timeout nice to have.
Compiz konfigurieren: Falls man auf die (aus Canonical-Sicht wohl völlig abwegige) Idee kommen sollte, seinen Window Manager konfigurieren zu wollen: sudo apt-get install compizconfig-settings-manager && ccsm

Das ist ungefähr der Werkzeugkasten, mit dem ich mir alle halbe Jahr, nach jedem Release, den Desktop wieder in genehme Form bringe. Ich verstehe nicht, warum man die Konfiguratoren nicht zum Standard macht bzw. eigene bereitstellt. Bei rechtlichen Fragen (Codecs usw.) habe ich vollstes Verständnis, aber hier muss man einfach Böswilligkeit und/oder Arroganz unterstellen. Canonical hält mich anscheinend für blöder als ich bin und ihre Designer für besser als sie sind. Grr … aber hey, immerhin kann man die Sachen patchen und alles andere fluppt ja ganz gut. Und alles zu patchen hat mich gestern abend auch nur 30 Minuten gekostet.

Pik7 - Ein HTML5-Präsentationsframework für Nerds

Peter Kröner — Di, 07 Mai 2013 16:07:00

Die letzten Jahre habe ich ständig Seminare und Vorträgen zu HTML5, CSS3, JavaScript und verwandten Themen gegeben. Bei diesen Themen ist es natürlich naheliegend, HTML/JS-Demos und -Codeschnipsel direkt in die Präsentation einzubetten. Auf HTML fußende Präsentationstools, mit denen das theoretisch denkbar wäre, gibt es wie Sand am Meer. Allerdings haben all diese meine dringendsten Präsentationsprobleme nicht gelöst, weswegen ich (nach mehreren Anläufen) mein eigenes Tool geschrieben habe. Die Hörsuppe hat mich vor ein paar Tagen dazu veranlasst, dem Ganzen mal ein ordentliches Release zu gönnen: Pik7 v. 1.0.0 ist da!

Ich bin nicht restlos davon überzeugt, dass irgendwer außer mir Pik7 einsetzen sollte, weil ich doch sehr spezielle Primärziele damit hatte:

Performance. Dinge wie mein Canvas-Intensivkurs haben deutlich mehr als 100 Slides, auf denen zu allem Überfluss auch noch allerhand Animationen usw. ablaufen. Das brauche ich in flüssig.
Presenter View. Ein aus „richtigen“ Präsentationstools wie Power Point bekanntes Feature, das auf einem Zweitbildschirm nicht für das Publikum gedachte Infos anzeigt – so kann der Vortragende zum Beispiel sehen, welche Slide als nächste dran ist und wie viel Zeit er noch hat. Bei der Masse meiner ganzen Folien darf dieses Feature nicht fehlen.
Druckbarkeit. Ich brauche PDF-Fassungen all meiner Slides. Druckbare Präsentationen + Chromes „print to PDF“ = Problem erledigt. Mit ein bisschen JavaScript und CSS kann man außerdem mehrere verschiedene PDFs erzeugen, z.B. einen Cheat Sheet für den Workshop und eine Komplettfassung für das spätere Nacharbeiten.
Einfache Programmier- und Stylebarkeit. Versteht sich von selbst: simple Themes, JavaScript-Events beim Folienwechsel usw.
Nobrainer-Funktionen für Nerds. Eingebautes Syntax-Highlighting. Eingebautes prefix-free. Auto-Synchronisation von mehreren offenen Präsentationen und Presenter Views. Ich muss kompliziertes Zeugs erzählen, ich habe keine Zeit komplizierte Tools zu bedienen.
Kein Firlefanz. Ich brauche weder fancy 3D-Animationen noch verschachtelte Slides noch eine Funktion, die mich Bullet Points nach und nach einblenden lässt. Die könnte man sicher alles einbauen, aber ich habe daran erst mal keinen Bedarf.

Kleiner Screencast mit den wichtigsten Features:

Da es, zumindest als ich anfing meine eigenen Tools zu basteln, diese Features in dieser Kombination nirgendwo zu finden gab, musste ich eben selbst ran. Pik7 ist selbstverständlich Open Source (MIT), liegt auf Github rum oder kann von pik.peterkroener.de heruntergeladen werden. Eine Präsentation zu erstellen ist recht einfach …






First Slide
Second Slide

… aber wie schon gesagt: ich bin nicht sicher, ob ich Pik7 wirklich empfehlen sollte. Zu den Nachteilen gehört unter anderem der etwas bei HTML-Slides übliche, mühsame Folienbau (Snippets für ST2 liegen aber bei) und dass zwingend ein Websever benötigt wird. Ein kleiner Node.js-Server wird zwar mitgeliefert, ist aber sehr spartanisch gehalten. Außerdem fehlen, wie erwähnt, Animationen und Co. Aber falls ihr euer Glück mit Pik7 versuchen wollt, werde ich euch nicht aufhalten.

Fragen zu HTML5 & Co beantwortet 9 - Leerzeichen, Canvas-Resizing, Slashes, Fullscreen-Video unter iOS

Peter Kröner — Di, 26 Mär 2013 14:21:00

Dieser Artikel ist Teil einer Serie:

Ich bin zwar kein Doktor und draußen ist auch gerade alles andere als Sommer, aber Fragen beantworte ich trotzdem gern. Bevorzugt solche zu HTML5, CSS3, JavaScript und anderen Themen rund um Webentwicklung. Die folgenden vier Fragen sind alle in den letzten Wochen via Twitter und E-Mail an mich herangetragen worden, was genau die beiden Kanäle sind, über die ich auch euch gerne die Fragen beantworte, die euch unter den Nägeln brennen. Einfach anschreiben!

Leerzeichen bei mobiler Datenverbindung verschwunden?

In mobilen Browsern (Verbindung über EDGE/3G/LTE) werden manchmal Leerzeichen aus meiner Webseite entfernt. Weißt du etwas darüber? Ist das vielleicht eine Art von Kompression?

Ohne es konkret testen zu können ist eine Antwort schwer, aber es kann durchaus sein, dass Mobilfunkanbieter das HTML einer Seite komprimieren, um hier und da ein paar Bytes zu sparen. Es ist jedenfalls nicht unüblich, dass die Provider in auszulieferndes Markup eingreifen. Besonders problematisch wird das Ganze, wenn, wie im verlinkten Artikel beschrieben, der Inhalt verändert wird, aber auch wenn „nur“ komprimiert (d.h. Whitespace zwischen Tags entfernt) wird, kann es durchaus zu sichtbaren Veränderungen in der Seite kommen, denn egal ist solcher Whitespace bei HTML nicht. Vergleichen wir doch mal:



Whitespace ist wichtig


Mit Whitespace

    Test
    Test
    Test



Ohne Whitespace
TestTestTest

Der Unterschied zwischen den beiden Absätzen ist an im gerenderten Endergebnis sichtbar und kommt daher, dass die Leerzeichen und Zeilenumbrüche zu zusätzlichen Textknoten zwischen den Elementen führen. Man beachte die childNodes-Eigenschaft im DOM:

Streicht ein übereifrig optimierender Mobildatendienstleister diese Leerzeichen weg, hat man natürlich plötzlich ein ganz anderes DOM und das kann ein handfestes Problem werden. Schnelle Abhilfe schafft möglicherweise die Codierung von Leerzeichen als Entity ( ) an kritischen Stellen.

Bilder und Videos per Canvas verkleinern

Vielen Dank für das Tutorial! Eine Frage hätte ich allerdings: was müsste ich machen, um das Video oder das Bild in eine kleine Canvas zu skalieren, also z.B. statt 400×300 in ein 40×30, wenn die Originaldatei aber 400×300 hat?

Das ist zum Glück ganz einfach. Die drawImage-Methode kann man nicht nur mit zwei Parametern (Bild, X-Koordinate, Y-Koordinate) aufrufen, sondern auch mit vier oder acht. Die beiden zusätzlichen Parametern bestimmen dann die Höhe und Breite des gemalten Bildes und wenn die Quelle andere Maße hat, wird sie automatisch gestreckt oder verkleinert. Außerdem kann man auch nur einen Ausschnitt aus der Quelle verwenden. Ein Bild sagt mehr als tausend Worte; der Aufruf context.drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh) bedeutet:

Leider wird diese Technik noch viel zu selten genutzt. Warum zum Beispiel sollte man bei Bilduploads eine viel zu große Datei hochladen, nur um sie dann auf dem Server von einem PHP-Script kleinrechnen zu lassen? Das kann man dank HTML5 viel besser auf dem Client erledigen.

End-Slashes für Leer-Elemente

Hallo, ich beobachte, dass häufig ein End-Slash im IMG-Tag gesetzt wird (). Bisher funktionieren auch die alten Tags ohne „/“. Kann es sein, dass der End-Slash zukünftig zwingend geschrieben werden muss? Und wenn ja, ab wann?

Nein, dieser schließende Slash wird voraussichtlich nie auf breiter Front Pflicht werden. Der Slash rührt daher, dass das W3C zwischenzeitlich mal plante, HTML auf XML-Basis neu aufzustellen – XHTML sollte der neue Standard werden. Dort wäre dann schließende Slash für Elemente wie Pflicht geworden. Diese XML-Umstellung hat aber aus einer ganzen Reihe von Gründen nicht so recht funktioniert und heute (d.h. in HTML5) ist der Slash damit wieder optional. Die HTML5-Parser in modernen Browsern werden durch ihn nicht gestört, benötigen ihn aber auch nicht. Es ist buchstäblich völlig egal ob man ihn verwendet oder nicht.

Es existiert zwar auch XHTML5, wo der Slash Pflicht wäre, aber wegen vieler vieler Problem damit (u.A. funktioniert es nicht im Internet Explorer 6, 7 und 8) ist die Verwendung von XHTML5 nicht zu empfehlen. Man nur Nachteile, keine Vorteile.

Inline-Video mit HTML5 auf dem iPhone

Gibt es irgendwie die Möglichkeit, mit HTML5 eingebundene Videos auf dem iPhone inline d.h. ohne automatischen Fullscreen darzustellen?

Zunächst sollten wir festhalten, dass sich das iPhone nicht direkt unkorrekt verhält, wenn es Videos ausschließlich im Vollbild abspielt. Die in den Spezifikationen festgeschriebenen Regeln lassen sich mit geringem Aufwand so weit dehnen, dass dieses Verhalten standardkonform erscheint. Zitat:

User agents may allow users to view the video content in manners more suitable to the user (e.g. full-screen or in an independent resizable window). As for the other user interface features, controls to enable this should not interfere with the page's normal rendering unless the user agent is exposing a user interface. In such an independent context, however, user agents may make full user interfaces visible, with, e.g., play, pause, seeking, and volume controls, even if the controls attribute is absent.

Wenn der Browser ein Interface mit Steuerungselementen für das Video anzeigt, darf er das im Fullscreen-Modus machen. Und wenn der Browser im Fullscreen-Modus ein Video anzeigt, soll er dort auch ein Interface mit Steuerungselemente anzeigen, selbst wenn das dafür normalerweise nötige controls-Attribut auf dem Video-Element gar nicht gesetzt ist. Und so startet iOS auf iPhone und iPod Touch jedes Video im Vollbild, da es schließlich ein Steuerungsinterface zeigt, das es auch in Abwesenheit des controls-Attributs anzeigen darf, da das im Vollbild passiert. Richtig falsch ist das also nicht.

Kann man denn etwas dagegen tun? Leider nicht. Es gibt zwar das proprietäre HTML-Attribut webkit-playsinline, aber das scheint nur für native Apps mit UIWebViews gedacht zu sein und funktioniert nicht auf iPhones und dem iPod Touch.

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld mit der Antwort haben. Ansonsten kann man mich natürlich auch mieten!

Über die verschiedenen Zukunftsprognosen für eine Welt ohne Presto

Peter Kröner — Do, 14 Feb 2013 14:58:00

Wie den wenigsten Webdesignern und -entwicklern entgangen sein dürfte, hat Opera angekündigt, in all ihren Produkten die hauseigene Presto-Engine gegen Webkit auszutauschen. So richtig habe ich die Gründe aus den entsprechenden Blogposts nicht herauslesen können, aber die wohl (für Nicht-Opera-Mitarbeiter) auch nicht so wichtig ist, wie die web-weiten Folgen dieses Schritts. An Prognosen hierüber herrscht kein Mangel – von goldener Zukunft bis hin zum Untergang der Webstandards lässt sich so ziemlich jede Aussage im Web finden. Eine besonders schöne Fundgrube stellt Hacker News dar. Ich habe zur Zeit noch keine fertige Meinung zu dieser Angelegenheit und möchte mich an dieser Stelle darauf beschränken, ein paar meiner Meinung nach leicht abenteuerliche Vorstellungen über die Folgen der Webkit-Entscheidung zu besprechen.

Alles wird besser! Auf dem Holzweg sind meines Erachtens vor allem jene, die glauben, dass es Entwicklern mit einer Engine weniger einfacher fallen wird, Web-Frontends zu bauen. Zum einen haben viele nicht ganz so professionelle Entwickler Opera ob seines eher geringen Marktanteils ohnehin völlig ignoriert. Alle, die ihre Werke auch in Opera getestet haben, werden gemerkt haben, dass dieser Browser sich seit jeher sehr standardkonform verhielt und selten die ganz großen Probleme machte (und wenn, dann hat selbst ein mittelschwerer Darstellungsfehler aufgrund des geringen Marktanteils wohl kaum fatale Auswirkungen auf das Gesamtprojekt gehabt). Und vor allem: um zu behaupten, dass es zwischen Browsern, die eine gemeinsame Engine haben, keine großen Unterschiede gibt, muss man die diversen Mobile-Browser ignorieren. Die verwenden zwar fast alle Webkit als Engine, aber in so unterschiedlichen Versionen und Zusammensetzungen mit anderen Komponenten, dass man davon als Webentwickler nicht wirklich viel merkt.

Das Ende ist nah! Die Apokalyptiker-Fraktion sieht hingegen eine neue Browsermonokultur unmittelbar vor der Tür stehen. Das ist, Stand heute (mit neben Webkit noch Gecko und Trident als relevanten Browserengines), natürlich noch längst nicht der Fall. Allerdings kann man das Ende von Presto schon als Wegfall eines Glieds aus der Monokultur-Abwehrkette interpretieren. Immerhin reicht es jetzt, wenn entweder Mozilla oder Microsoft aus dem Browsermarkt ausscheiden oder selbst zu Webkit wechselt, denn das dann bestehende Engine-Duopol könnte sich aufgrund des Übergewichts der Webkit-Browser als instabil erweisen. Aber selbst dann ist nicht gesagt, dass das Web im Innovationsstillstand versackt – die Konkurrenz durch die nativen Plattformen könnte das verhindern. Die Frage ist natürlich, wie der weitere Fortschritt dann aussehen könnte, was uns direkt zu Prognose Nummer drei bringt …

Gut für Webstandards! Manche sagen auch, weniger Engines seien besser für die Entwicklung und Durchsetzung von Standards. Ich weiß nicht so recht. Wenn man der Presto-Engine etwas nicht vorwerfen kann, dann sind das gewohnheitsmäßige Standards-Abweichungen. An dieser Front war Opera sicher nie das größte Problem. Andersherum könnte durchaus ein Schuh draus werden, denn Webstandards richten sich oft nach den Implementierungen – was in allen Browsern vorhanden ist, und sei es noch so größer Käse, wird früher oder später Standard. So war es zum Beispiel mit

oder der grausligen Drag & Drop-API. Mit nun einer Engine weniger fällt es vielleicht etwas leichter, Fakten zu schaffen, die dann in einem Standard münden. Das kann man durchaus gut finden weil es schneller gemeinsame APIs produziert, andererseits ist ein hohes Tempo ein Risiko für die Qualität dieser gemeinsamen Features. Allerdings hat Opera nun auch nicht all seine Entwickler entlassen, sondern lässt diese jetzt an Webkit mitbasteln, d.h. die Stimmen der Vernünftigen, die einst für Presto sprachen und programmierten, sind weiterhin zu hören. Ob das reicht wird man sehen.

Ich selbst habe, wie eingangs erwähnt, noch keine fertige Meinung zu diesem Schritt von Opera. Zu bejubeln finde ich nichts, aber die auch den unmittelbaren Weltuntergang vermag ich nicht festzustellen. Klar, im Prinzip sind das WWW der Webkit-Hegemonie einen Schritt näher gekommen, aber dass demnächst wirklich Mozilla und/oder Microsoft zumachen, fällt mir schwer zu glauben. Und beide haben einen ganz gesunden Marktanteil und können mit jeder Version steten Fortschritt vermelden. Selbst was die Entwicklung von Standards angeht, muss sich erst mal zeigen ob sich überhaupt etwas ändert. Das halte ich zwar noch am wahrscheinlichsten (jedenfalls wahrscheinlicher als eine Browser-Einheitsfront) aber wie genau sich das auswirkt, ist reine Spekulation.

Mein Fazit: Interessante Entwicklung, aber (noch) kein Grund die Gelassenheit zu verlieren.

Indexed DB, die neue HTML5-Datenbank im Browser. Teil 2: Browsermacken, Tools und Polyfills

Peter Kröner — Do, 24 Jan 2013 14:28:00

Nachdem wir in Teil 1 dieses Artikels die wichtigsten Parts der Indexed Database API kennen gelernt haben und auch erfahren haben, dass dieses Feature bisher nur in Chrome, Firefox und IE 10 zu finden ist, stellt sich die übliche HTML5-Fragen: kann man das Ganze überhaupt benutzen? Ja, man kann. Für die Browser ohne Unterstützung für Indexed DB gibt es gute Polyfills und die wenigen Macken, die die vorhandenen Implementierungen haben, lassen sich recht einfach ausmerzen. Ein wenig problematischer ist der noch herrschende Mangel an Tools und Libraries. Aber alles der Reihe nach …

Polyfill(s) für Safari, Opera und andere

Opera und Safari inklusive Mobile-Varianten unterstützen die Indexed Database API nicht. Was sie allerdings unterstützen, ist Web SQL, dieser aufgegebene Nun-doch-nicht-Standard für relationale Datenbanken im Browser. Es ist dann ziemlich naheliegend, einen Polyfill zu bauen, der die Funktionalität von Indexed DB mittels Web SQL herstellt, was IndexedDBShim.js in gewohnt unkomplizierter Manier macht:

Mit dieser Zeile Code im HTML läuft die Datenspeicherung dann auch in Opera, Safari, iOS, alten Android-Versionen und auch sonst fast allen Browsern, die zwar Web SQL unterstützen, denen es aber an Indexed DB gebricht.

Es gibt neben IndexedDBShim.js noch einen alternativen Polyfill aus der Feder Facebooks, den ich allerdings nicht getestet habe.

Härtefall 1: Android-Browser

Im Standard-Android-Browser (nicht mobile Chrome) ab Version 4 ist Indexed DB implementiert. Dummerweise basiert diese Implementierung aber auf einer älteren, nicht mit anderen Browsern kompatiblen Version der Spezifikationen. Der bequemste Ausweg aus diesem Problemchen ist, den Polyfill statt der nativen, aber fossilen Implementierung zu verwenden, denn Web SQL macht Android sehr viel richtiger als Indexed DB.

Ob eine Implementierung von Indexed DB veraltet ist, lässt sich am Vorhandensein von window.IDBVersionChangeEvent ablesen. Diese Variable wird nur von der aktuellen Version der Spezifikation beschrieben; ein Browser, der sie nicht hat, hat entweder gar keine Indexed DB oder eine alte Version. Der Rest ist dann ganz einfach:

// Keine (aktuelle) Implementierung von Indexed DB vorhanden?
var requireShim = typeof window.IDBVersionChangeEvent == 'undefined';

// WebSQL vorhanden?
var supportsWebSql = typeof window.openDatabase != 'undefined';

if(requireShim && supportsWebSql){
  window.shimIndexedDB.__useShim(); // Verwendung des Polyfills erwzingen
}

Damit sind Android-Browser und auch alle anderen Fossilien, die eine alte Variante von Indexed DB mit sich herumschleppen, bedient.

Härtefall 2: Tools

Chrome bietet ein komfortables, in den Web Inspector einbgebautes UI zur Betrachtung von Indexed DB-Datenbanken im Resouces-Tab:

Und das war es dann auch schon mit guten Nachrichten von der Tool-Front, denn weder Firefox noch Internet Explorer können mit nativen Tools aufwarten. Am nächsten kommt man dem im Firefox noch mit dem Addon SQLite Manager, denn unter der Haube speichert dieser Browser die Indexed Database in einer SQLite-Datenbank. Diese befindet sich in aller Regel im Profil-Verzeichnis der jeweiligen Firefox-Users im Unterverzeichnis indexedDB// und hat den Namen .sqlite. Da sich SQLite und Indexed DB in ihrem Wesen stark unterscheiden, ist der SQLite Manager nicht wirklich ein super-komfortables Tool, aber er ist besser als gar nichts.

Stichwort „gar nichts“: für den IE 10 scheint es gar kein browserbasiertes Tool zu geben. Das nächstbeste sind sind diverse Ansätze für in HTML eingebaute Scripts, die dann einen Inspector-UI in die Seite rendern. Zu nennen wäre da vor allem der IDBExplorer, den ich allerdings nicht gründlich genug gestestet habe, um eine Aussage über dessen Tauglichkeit zu machen.

Härtefall 3: Libraries

Dem Indexed DB-Universum fehlen noch vernünftige Libraries. Zwar ist die API nicht schlecht, aber mehr Komfort und Funktionalität darf man sich als Entwickler durchaus wünschen. Zum Beispiel wäre ein Möglichkeit zur Definition von Schemata (inklusive Validierung, Defaultwerten und Virtuals) ganz wünschenswert und auch eine etwas mehr an moderne Befindlichkeiten angepasste API (Stichwort Verkettung) würde sicher Abnehmer finden. Außer Ansätzen ist in dieser Richtung aber bisher noch nicht viel zu finden.

Am nächsten kommen dem gewünschten Featureset noch db.js und IDBWrapper, die beide verkettbare APIs herstellen. Statt sich mit Transaktion und onsuccess-Callbacks herumzuschlagen, schreibt man einfach herunter, was man mit der Datenbank anstellen möchte:

// Beispiel mit db.js
server.people.add({
  firstName: 'Aaron',
  lastName: 'Powell',
  answer: 42
}).done(function(item){
  // item stored
});

Und das wäre eigentlich schon alles, was ich in Sachen Libraries auftreiben konnte. Aus der Ecke der Microsoft-Fans kommt außerdem noch Linq2IndexedDB, das aber in einem Maße unterdokumentiert ist, dass wir am besten so tun, als hätte ich es gar nicht verlinkt.

Fazit

Unter zuhilfenahme aller Polyfills und Tricks sieht es mit der Browserunterstützung für Indexed DB eigentlich vergleichsweise gut aus:

Browser	Unterstützung ab Version
Firefox	4*^† / 16+
Chrome	11^† / 23 / 24+
Safari	- (< 5.1+)
Opera	- (< 12.1+)
Internet Explorer	10+
Mobile Safari	- (< 5.1+)
Android Browser	4.?^† (2.1+)

* Mit Vendor-Prefix
^† Implementierung entspricht nicht aktuellen Specs
In Klammern: mit Polyfill

Klar: die üblichen schwarzen Schafe, die alten IE und das, was bei Android als Browser durchgeht, sind mal wieder die Fortschrittsverhinderer. Richtig ruhmvoll ist natürlich auch das Abschneiden von Opera und Safari nicht, aber der recht gute Polyfill (bzw. die verschiedenen Polyfills) lindert den Schmerz doch erheblich. Dramatischer erscheint mir das Fehlen an richtig guten Tools für Indexed DB – die Browser mit nativer Unterstützung sowie interessierte JavaScript-Nerds mit Datenbank-Wissen sollten an dieser Front dringend nachrüsten. Ich hätte gern sowas wie Mongoose für Indexed DB.

Alles in allem lässt sich sagen, dass Indexed Database nach HTML5-Maßstäben eine bereits relativ runde Sache ist. Die Spezifikationen sind recht stabil und die Funktionen in allen Browserfamilien zum funktionieren zu bekommen. Allein in Sachen Tools und Libraries fehlt es noch, aber das sollte ein im Laufe der Zeit lösbares Problem sein.

Ein und Link eine Warnung

Da diese beiden Artikel hier nur einen sehr sehr grober Überblick geben konnten, möchte ich gern noch auf die wie immer erstklassige MDN-Dokumentation zum Thema hinweisen, die aktuell und auch sehr vollständig ist. Und zum Abschluss noch eine Warnung: ähnlich wie die Implementierung im Android-Browser gibt es auch Artikel zu Indexed DB, die auf einer heute veralteten Fassung der Spezifikationen basieren. Diese Artikel kann man daran erkennen, dass in ihnen eine setVersion()-Funktion besprochen wird, die es in der aktuellen Fassung nicht mehr gibt. Wenn ihr also in einem Artikel zu Indexed DB über setVersion() stolpert, lest lieber anderswo weiter.

Indexed DB, die neue HTML5-Datenbank im Browser. Teil 1: ein kurzer Überblick

Peter Kröner — Mo, 21 Jan 2013 15:06:00

Die Indexed Database API (kurz Indexed DB) nimmt in der Web-Plattform die Rolle der dicken Datenbank ein. Während Web Storage als Cookie-Ersatz eingeplant ist und nicht als zuverlässiger Datenspeicher für große Applikationen taugt, ist Indexed DB genau dafür gedacht. Anders als bei Web Storage kann Indexed DB neben Strings auch Zahlen, Objekte und Arrays persistent speichern und selbst Blobs stellen kein Problem dar. Darüber hinaus können die gespeicherten Inhalte einfach aus der Datenbank herausgepickt werden und über Teile der Daten zu iterieren ist auch möglich – wie es bei einer richtigen Datenbank eben sein sollte. Damit stellt diese API einen wichtigen Mosaikstein im HTML5-Universum dar, denn einen anderen großkalibrigen Datenspeicher für offlinefähige Webapps wird es so bald nicht nicht browserübergreifend geben.

Nachdem ich fast zwei Wochen lang nichts weiter getan habe, als in den Spezifikationen und Implementierungen von Indexed DB herumzustochern, wird es Zeit, Bericht zu erstatten. Dieser erste Teil behandelt das Wesen der API gemäß der Spezifikationen. Das hier durchexerzierte Beispiel sollte aus dem Stand in aktuellen Chrome- und Firefox-Versionen sowie im Internet Explorer 10 funktionieren – wie man Indexed DB auch allen anderen Browserfamilien beibringt und was es an Fallstricken und Tools gibt, folgt im zweiten Teil.

Wieso Indexed DB?

IndexedDB ist eine NoSQL-Datenbank, ähnlich wie die in der Open-Source-Welt bekannten CouchDB und MongoDB. Solche Datenbanken haben anders als z.B. MySQL keine festen Datenbanktabellen, sondern bestehen aus Ansammlungen von „Dokumenten“ (meist JSON-Objekte) als Datensätzen. Innerhalb einer solchen Ansammlung können die einzelnen Datensätze bei Bedarf unterschiedlich aufgebaut sein, was mit einer starren Tabellenstruktur wie in den bekannten SQL-Datenbanken nicht ohne weiteres möglich ist. Der Preis für diese Flexibilität ist natürlich, dass die Applikation, die mit der Datenbank arbeitet, für alle unterschiedlich aufgebauten Dokumente gerüstet sein muss – die Datenbank wird im Vergleich zu SQL also konzeptionell vereinfacht, die Applikation potenziell komplexer. Behauptungen, nach denen das eine Modell skalierbarer oder performanter sei als das andere, dürften für die Arbeit im Webbrowser wohl erst mal von untergeordneter Bedeutung sein.

Obwohl NoSQL zur Zeit recht hip ist (in dem Rahmen, in dem Datenbanken hip sein können), ist es dennoch im Vergleich zu SQL die eher ungewöhnliche Lösung. Warum kommt gerade die in unsere Browser? Es gab mit Web SQL Database mal einen Ansatz, SQL-Datenbanken im Rahmen von HTML5 zu standardisieren, was aber 2010 gescheitert ist. Alle Browserhersteller, die an Web SQL interessiert waren, haben als Basis ihrer Umsetzung SQLite gewählt, ein bewährtes Open-Source-Datenbanksystem. In Folge traten auf dem Weg zur Standardisierung zwei Probleme auf:

Hätte ein Browserhersteller ein anderes System als SQLite als Datenbank-Backend gewählt, wäre dessen Subset der SQL-Syntax nicht das gleiche gewesen, wie das der anderen Browser und die Implementierungen wären nicht kompatibel gewesen
Solange nicht zwei voneinander unabhängige Implementierungen einer Technologie vorliegen, kann diese nicht zum Webstandard erhoben werden

Aus dieser Zwickmühle gab es nur einen Ausweg: hinfort mit Web SQL, her mit einer von Grund auf neuen Lösung. Die Spezifikationen für Indexed DB beschreiben ein komplett eigenes NoSQL-System, von der Browser-API bis hin zu den Algorithmen der einzelnen Datenbank-Operationen. Jeder Browserhersteller kann anhand dessen seine eigene Implementierung bauen, die dann trotzdem kompatibel zur Konkurrenz ist und auf dem Weg zum Webstandard nicht stört.

Hallo Welt mit Indexed DB I: Datenbank und Object Stores

Die API von Indexed DB in ihrer Gesamtheit ist recht komplex, weswegen wir uns in diesem Post auf das Durchexerzieren eines einfaches Schreiben-Lesen-Löschen-Beispiels beschränken, bei dem wir lediglich die Namen toller Browser-Features in einer Datenbank ablegen. Wie jede NoSQL-Datenbank hat auch Indexed DB seine ganz eigene Terminologie. Diese wird in den Spezifikationen umfassend erklärt; die wichtigsten Begriffe sind die Folgenden:

Datenbanken enthalten Object Stores
Object Stores entsprechen Datenbank-Tabellen und enthalten Datensätze
Ein Datensatz ist ein Key mit einem dazugehörigen Wert
Ein Key kann ein String eine Zahl oder ein Array sein und identifiziert einen Datensatz
Werte können alles mögliche sein: Strings, Zahlen, Objekte, Arrays, Blobs …
Transaktion sind ein Set gemeinsam durchgeführter Operationen
Cursor sind ein Iterationsmechanismus für größere Mengen von Datensätzen

Um etwas mit Indexed DB zu machen, braucht es zunächst eine Datenbank. Eine solche lässt sich ganz einfach per window.indexedDB.open() öffnen bzw. erzeugen:

// Datenbank anlegen
var request = indexedDB.open('html5', 1);

Die Datenbanken sind nach Origin (Kombination aus Host, Protokoll und Port einer Webapp) getrennt, d.h. foo.com kann nicht die Datenbank von www.bar.de öffnen.

Das erste Funktionsargument von indexedDB.open() ist der Name der Datenbank, das zweite die Versionsnummer. Diese Nummer wird für die interne Versionierung der Webapp verwendet – wann immer man Änderungen an der Struktur der DB vornehmen möchte, ändert man diese Zahl. Diese Änderung hat dann Auswirkung auf die Events der Datenbank-Anlege-Operation. Wie der obrige Code mit seinem var request bereits erahnen lässt, wird in der Zeile mit indexedDB.open() nicht wirklich die Datenbank angelegt, sondern es wird ein entsprechender asynchroner Request gestartet. Ist dieser abgeschlossen, feuern die folgenden Events auf dem request-Objekt:

error wenn etwas beim Anlegen der Datenbank schiefgelaufen ist
upgradeneeded wenn die Datenbank-Version sich geändert hat oder die Datenbank erstmals angelegt wurde
success wenn die Datenbank geöffnet wurde (nach einem eventuellen upgradeneeded-Event)

Das upgradeneeded-Event ist von besonderer Bedeutung, denn nur im Event Handler von upgradeneeded können Änderungen an der Datenbankstruktur durchgeführt werden – versucht man z.B. einen neuen Object Store außerhalb von upgradeneeded anzulegen, setzt es eine Exception.

Beim ersten Aufruf unseres Beispiels legt der Browser die Datenbank „html5“ neu an, d.h. das upgradeneeded-Event feuert. Wir nutzen dies, um in der Datenbank einen Object Store anzulegen, der unsere liebsten HTML-Features enthalten wird:

// Änderungs/Erzeugungs-Event
request.onupgradeneeded = function(){
  console.log('Datenbank angelegt');
  var db = this.result;
  if(!db.objectStoreNames.contains('features')){
    store = db.createObjectStore('features', {
      keyPath: 'key',
      autoIncrement: true
    });
  }
};

Mit der createObjectStore()-Methode der frisch angelegten Datenbank (this.result im Event Handler) lassen sich neue Stores anlegen. Als Argumente werden ein Name sowie ein Konfigurations-Objekt übergeben, das in unserem Fall nur die Durchnummerierung der Datensätze festlegt. Hier entscheiden wir uns für automatisch generierte fortlaufende Nummern (autoIncrement: true) im Feld key unserer Einträge (keyPath: 'key').

Nach dem upgradeneeded-Event (oder sofort, wenn es keine DB-Änderungen gab) feuert das success-Event, sofern sich die Datenbank fehlerfrei öffnen ließ:

// Öffnungs-Event (feuert nach upgradeneeded)
request.onsuccess = function(){
  console.log('Datenbank geöffnet');
  var db = this.result;
  ...
}

Ab hier können wir mit Indexed DB in die Vollen gehen und nach Herzenslust Datensätze speichern, auslesen und löschen.

Hallo Welt mit Indexed DB II: Operationen und Transaktionen

Als Beispiel-Datensatz nehmen wir das denkbar einfachste JavaScript-Objekt:

// Zu speichernder Datensatz
var item = { title: 'Web Storage' };

Um mit Datensätzen in Indexed DB zu arbeiten, braucht es immer die gleichen vier Schritte:

Transaktions-Objekt erstellen
Object Store(s) auswählen
Operation(en) starten (put, delete usw.)
Events abwarten

Ein Transaktions-Objekt erhält man, indem man db.transaction() mit den Namen der betroffenen Object Stores sowie den gewünschten Berechtigungen (readonly oder readwrite) füttert:

// Speicher-Transaktion
var trans = db.transaction(['features'], 'readwrite');

Ab dann ist alles weitere ganz einfach: aus dem Transaktions-Objekt die jeweiligen Object Stores herauspicken (trans.objectStore('storeName')), die gewünschten Operationen veranlassen und auf das success-Event warten:

var store = trans.objectStore('features')
var request = store.put(item); // `item` in dem Store ablegen

// Erfolgs-Event
request.onsuccess = function(evt){
  console.log('Eintrag ' + evt.target.result + ' gespeichert');
  ...
};

Das gleiche Prinzip greift, wenn Einträge aus eine Object Store ausgelesen werden sollen. Im einfachsten Fall, wenn nur ein Datensatz mit bekanntem Key ausgelesen werden soll, braucht es nur ein store.get(42) um z.B. den Eintrag mit dem Key 42 auszulesen.

Wenn es ein bisschen mehr sein darf, werden Cursor und Key Ranges benötigt. Nachdem die Auslese-Transaktion eröffnet und der Object Store gewählt wurde …

var trans = db.transaction(['features'], 'readonly');
var store = trans.objectStore('features');

… muss Indexed DB mitgeteilt werden, für welchen Daten-Ausschnitt wir uns interessieren. Key Ranges sind hier das Mittel der Wahl. Mit einer der Methoden von window.IDBKeyRange lassen sich verschiedene Objekte erzeugen, die solche Ausschnitte beschreiben. Diese Objekte können zwei fixe Grenzwerte haben („alle Einträge von 23 bis 42“) oder nach oben oder unten offen sein (z.B. „alle Einträge ab 42“). Beispiele:

IDBKeyRange.lowerBound(0) für alle Einträge von 0 bis Ende
IDBKeyRange.upperBound(10) für alle Einträge bis 10
IDBKeyRange.only(23, 42) für alle Einträge zwischen 23 bis 42

Diese Grenzwerte beziehen sich in unserem Fall auf den Key der Datensätze; möchte man anhand anderer Felder durch die Datensätze rattern, kombiniert man Key Ranges mit Indizes. In jedem Fall öffnet man mit openCursor()-Methode von Store oder Index einen Cursor (ggf. mit Richtungsangabe), dessen success-Event für jeden Datensatz einmal feuert. In unserem Fall machen wir es uns so einfach wie möglich:

// Cursor für alle Einträge von 0 bis zum Ende
var range = IDBKeyRange.lowerBound(0);
var cursorRequest = store.openCursor(range);

// Wird für jeden gefundenen Datensatz aufgerufen... und einmal extra
cursorRequest.onsuccess = function(evt){
  var result = evt.target.result;
  ...
};

Das success-Event feuert für jeden Datensatz sowie wenn alle Datensätze abgearbeitet wurden nochmal. Für gefundene Datensätze ist die target.result-Eigenschaft des Event-Objekts der gefundene Eintrag, beim letzten Event null. Mit dem Datensätzen kann dann die gewünschte Arbeit verrichtet werden und am Ende der Cursor mittels target.result.continue() zum nächsten Eintrag bewegt werden.

In unserem simplem Beispiel machen wir nichts weiter, als den Eintrag in die Konsole zu schreiben und ihn dann gleich wieder zu löschen:

if(result){
  console.log('Eintrag gefunden:', result.value);

  // Eintrag wieder löschen
  var trans = db.transaction(['features'], 'readwrite');
  var store = trans.objectStore('features');
  var key = result.value.key;
  var request = store.delete(key);
  request.onsuccess = function(evt){
    console.log('Eintrag ' + key + ' gelöscht');
  }
  
  // Cursor zum nächsten Eintrag bewegen
  result.continue();

}

Und fertig! Damit haben wir nur ein sehr sehr simples Beispiel (Demo, Gist) geschaffen, aber eines, das zumindest die wichtigsten Eckpunkte von Indexed DB demonstriert. Und so richtig schwer war es ja nicht – Indexed DB folgt dem löblichen Trend moderner HTML5-APIs, möglichst einfache Schnittstellen für die Webapps von morgen bereitzustellen. Bleibt nur die ewige Frage nach der Browserunterstützung …

In welchen Browser funktioniert Indexed DB?

Grundsätzlich ist diese Frage leicht zu beantworten: in Chrome, Firefox und IE 10 gibt es Unterstützung, ansonsten sieht es finster aus. In allen drei Browsern ist die API mittlerweile ohne Vendor-Prefix benutzbar und es wird allenthalben davon ausgegangen, dass das auch so bleibt, d.h. dass die aktuelle Spezifikationen den Stand des späteren Standards wiederspiegeln.

Problematisch sind alle Browser, die nicht Chrome, Firefox oder IE 10 sind, wobei „problematisch“ gewohnt relativ ist. Zum einen lässt sich Indexed DB per Polyfill für die meisten Browser nachrüsten, zum anderen gibt es durchaus, anders als es Caniuse (noch) angibt, Indexed DB in Android-Browsern ab Version 4 – wenn auch in einer Version aus der frühen Kreidezeit. Alles kein Problem, alles zu fixen, alles in Teil 2 dieses Artikels beschrieben.

Termine für Januar, Februar und März 2013

Peter Kröner — Mi, 16 Jan 2013 13:37:00

Der Erklärbär ist wieder auf Tour! Falls ihr euch mit HTML5- und CSS3-Wissen betanken lassen möchtet, habe ich im ersten Quartal exakt je eine solche Gelegenheit für euch auf Lager:

4. - 6. Februar in München: HTML5-Schulung bei der Open Source School. Mein bewährtes dreitägiges 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-Programmierung ist alles dabei. Geboten wird ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch gibt es obendrein.
7. - 8. Februar in München: CSS3-Schulung bei der Open Source School. Mein zweitägiges CSS3-Standardprogramm katapultiert die Teilnehmer in das CSS3-Zeitalter, in dem Webfonts und Farbverläufe fließen. Einen großer Praxisanteil, kleine Arbeitsgruppen und ein Buch als Bonus gibt es auch hier.

Das HTML5-Programm wird zur Zeit grundlegend aktualisiert, unter anderem kommen mittlerweile auch Indexed DB, getUserMedia und viele andere neuere Spielereien vor, die nicht im Buch stehen.

Ein neues Element für HTML5:

Peter Kröner — Mi, 02 Jan 2013 14:59:00

Wie sicher den Wenigsten entgangen ist, wird fleißig an einem neuen Element für HTML5 gearbeitet. Das

-Element soll for the identification of the main content area of a document genutzt werden und damit die bekannten HTML5-Elemente

und Konsorten ergänzen. Stand heute ist das Ganze eigentlich noch nichts weiter, als ein Vorschlag zur Erweiterung des bestehenden Standards, doch da weitgehend Konsens über die Einführung des neuen Elements besteht, kann man sich

durchaus schon genauer anschauen.

Wozu
?

Das neue Element bietet genau wie alle anderen neuen HTML5-Elemente zwei Dinge: zum einen ist es ein zusätzliches Sprachmittel für die Auszeichnung von Website-Teilbereichen, zum anderen hat es eingebaute ARIA-Funktionen, die wenn das neue Element korrekt benutzt wird, automatisch der Barrierefreiheit der Seite guttun. In Sachen Optik und Verhalten entspricht es genau wie

und Konsorten dem, was man vom guten alten

kennt.

Gedacht ist

für die Auszeichnung des jeweiligen Hauptinhalts einer Seite; im Falle eines Blogs wäre das zum Beispiel die Spalte mit allen Artikeln:



Katzenbilder24.com


  Katzenbilder-Blog
  
    
      Start
      Über
    
  



  
    Flauschiges Kätzchen
    Text, Bild...
  
  
    Pelziges Kätzchen
    Text, Bild...
  



  
    Tagcloud
    Tags, Tags, Tags
  
  
    Blogroll
    Links, Links, Links

Anders als

hat

keinen Einfluss auf die Überschriftenstruktur (Outline) einer Webseite und es darf auch nicht in anderen Abschnitts-Elementen vorkommen – es soll den Hauptinhalt einer Seite markieren, nicht den Hauptinhalt eines Abschnitts der Seite. Ein korrekt verwendetes

-Element hat demnach keine

oder

-Elemente als Vorfahren und ist das einzige Element seiner Art auf der Seite.

Als Bonus hat

, wie alle anderen neuen HTML5-Elemente auch, fest eingebaute ARIA-Eigenschaften. Das bedeutet im Endeffekt, dass man bei der korrekten Verwendung von

ohne zusätzlichen Aufwand eine zugänglichere Webseite erstellt, da das neue Element automatisch ein role="main" trägt. Dank

wird es in Zukunft ziemlich schwierig, diese Annotation zu vergessen.

Braucht man
überhaupt?

Einige haben argumentiert, dass man das neue Element gar nicht bräuchte, denn es wäre ja möglich, den Hauptinhalt einer Webseite einfach dadurch zu kennzeichnen, dass man ihn „den Rest“ sein lässt. Beispiel:



Katzenbilder24.com


  Katzenbilder-Blog
  
    
      Start
      Über
    
  



  Flauschiges Kätzchen
  Text, Bild...


  Pelziges Kätzchen
  Text, Bild...



  
    Tagcloud
    Tags, Tags, Tags
  
  
    Blogroll
    Links, Links, Links

Auch ohne

ist klar, was hier der Hauptinhalt ist; alles, was nicht in

und

steht, also die Ansammlung der Article-Elemente. Dank role-Attribut ist auch der Barrierefreiheit so viel Genüge getan, wie es mit dem neuen Element der Fall wäre. Es gibt aber vier gute Argumente, die für die Einführung des neuen Elements sprechen:

Ein Bereich, der der Hauptinhalt einer Webseite ist, kommt auf vergleichsweise vielen Webseiten vor. Vermutlich auf den meisten. Insofern ist es naheliegend, hierfür ein eigenes Element einzuführen, denn schließlich haben andere häufig auftretende Konstruktionen wie z.B. Navigationen ja auch ihre eigenen Elemente.
Aus eigener Erklärbär-Erfahrung kann ich berichten, dass HTML5-Neulinge, wenn man sie Markup schreiben lässt, fast immer den Hauptinhalt in ein Extra-Element Marke
kapseln. Es scheint so zu sein, dass es autorenfreundlich wäre, dafür ein passendes Werkzeug d.h. das neue Element bereitzustellen.
Es wäre zwar möglich, manuell role="main"-Attribute zu vergeben, aber es ist zu bezweifeln, dass das wirklich auf breiter Front passiert. Mit dem neuen Element kann das nicht mehr vergessen werden, was (korrekte Verwendung des Elements vorausgesetzt) ohne zusätzlichen Aufwand der Zugänglichkeit der Webseite guttäte – weniger Arbeit für den Autoren, mehr Spaß beim Benutzer.
Die HTML Design Principles sagen ganz klar: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity

Bis auf die theorietreue Sparsamkeitsfraktion würden also alle Beteiligten von der Einführung des

-Elements profitieren. Bleibt also nur die Frage: wann kommt die Einführung?

Welche Browser unterstützen
?

Zur Zeit gibt es das neue (wirklich sehr neue) Element nur als Experimental-Implementierung in Preview-Versionen von Firefox und Chrome. Das ist allerdings nicht zwingend ein Problem, da die Funktionalität von

händisch nachgerüstet werden kann. Vorausgesetzt der Browser verarbeitet das Element prinzipiell richtig (was alle Browser außer IE 6, 7 und 8 machen sollten), so muss es nur richtig formatiert und mit den passenden ARIA-Attributen versehen werden. Heißt also: display:block im CSS vergeben und bei der Benutzung in HTML nicht das Attribut role="main" vergessen. Dies wird zwar, sobald alle Browser das neue Element nativ unterstützen, doppelt gemoppelt sein, aber das ist, wenn überhaupt, ein Problem, dessen Lösung man sicher guten Gewissens auf diesen fernen Zeitpunkt vertagen kann.

Wie immer gilt aber, dass in Sachen HTML5-Markup keine übermäßige Eile geboten ist. Alle „alten“ Webseiten werden auch in Zukunft ohne

ganz wunderbar funktionieren – nur wenn ein Redesign ansteht, lohnt es sich, über den Einsatz des neuen Elements nachzudenken.

HTML 5 wird 2014 Webstandard - Was bedeutet das, was ändert sich?

Peter Kröner — Do, 29 Nov 2012 15:07:00

Man liest, das W3C plane HTML 5.0 im vierten Quartal 2014 fertig, d.h. in einen stabilen Webstandard verwandelt zu haben. Features die sich nicht in diesen Zeitplan quetschen lassen, sollen nach HTML 5.1 verschoben werden, mit dem dann Ende 2016 zu rechnen ist. Das klingt erst mal recht unkompliziert, aber da allerorten mit dem Begriff „HTML5“ etwas unbedacht umgegangen wird (auch in dem W3C-Plandokument) ist etwas unklar, was konkret denn nun 2014 fertig sein soll. Und natürlich lohnt es sich zu fragen, welche Auswirkungen diese Erhebung zum Standard denn haben wird. Ich hatte das bereits in der letzten Folge von Working Draft aufgedröselt, aber der Vollständigkeit halber möchte ich hier nochmal aufschreiben, was es mit diesem Plan auf sich hat und was er für HTML5 zu bedeuten hat.

HTML5 oder HTML 5?

Man kann „HTML5“ entweder mit oder Leerzeichen vor der Fünf scheiben. Die Schreibweise ohne Leerzeichen ist im WHATWG-Lager usus, Freunde des W3C haben es lieber mit Leerzeichen. Die WHATWG ist, wir erinnern uns, jene Arbeitsgruppe der Browserhersteller, die ursprünglich die Entwicklung der ganzen schönen neuen Webtechnologien losgetreten hatten. Die HTML-Arbeitsgruppe des W3C befasst sich mit einem Teilaspekt der WHATWG-Spezifikationen – jenem, der sich vorrangig mit HTML5 im Sinne von HTML befasst. Von diesen beiden Arbeitsgruppen ist weiterhin der allgemeine Sprachgebrauch zu unterscheiden, der den Begriff HTML5 noch viel weiter fasst. Ein Bild sagt mehr als tausend Worte:

Der große grüne Kreis ist die Spezifikation der WHATWG, und der große blaue Kreis innen ist die Spezifikation des W3C. Wenn man die Inhaltsverzeichnisse beider Spezifikationen vergleicht, wird der Unterschied klar: währen die WHATWG auch diverse JavaScript-APIs spezifiziert, enthält das W3C-Dokument fast nur HTML im Sinne von HTML. Das heißt aber nicht, dass das W3C sich nicht auch um die JS-Apis kümmern würde, nur ist es eben so, dass einiges, was bei der WHATWG Teil von HTML5 ist, beim W3C in einem eigenen Spezifikationsprozess bearbeitet wird (z.B. der Canvas 2D-Context bei WHATWG und W3C). Der große gelbe Kreis bildet den allgemeinen Sprachgebrauch ab, der unter HTML5 alles vereinigt, was es schönes neues im Browser gibt, von HTML-Tags bis hin zu clientseitigen Datenbanken. Das ist das, was Otto Normalverbraucher mit „HTML5“ meint.

Was wurde beschlossen (und wie schreibt man es)?

Das, was das W3C in seinem Plan für 2014 anpeilt, ist die Anfertigung eines Snapshots vom Dokument der W3C HTML-Arbeitsgruppe (großer blauer Kreis). Die Spezifikationen sollen bis Ende 2014 so weit stabilisiert werden, dass man es zur Recommendation, d.h. zu fertigen Standard erklären kann. Alle anderen Dokumente inklusive der HTML5-Spezifikationen der WHATWG sind davon nicht betroffen. Weil das W3C-Dokument sich vor allem um Parser und HTML-Tags und weniger um Browser-APIs dreht, würde dieser neue Webstandard dann auch tatsächlich eine neue Version von HTML darstellen. Dieser neue Standard hätte dann auch die Schreibweise „HTML 5“ verdient – hier wäre die 5 eine echte Versionsnummer und nicht wie bei „HTML5“ nur Teil eines Namens. Und wenn man schon wieder Versionsnummern hat, so spricht auch nichts mehr gegen Folgeversionen wie 5.1 und weiteres.

Es wäre natürlich praktisch, wenn sich die Welt darauf einigen könnte, die Schreibweise „HTML5“ für die Buzzword-Bedeutung der neuen Technologien zu reservieren und „HTML 5“ bzw. „HTML 5.0“ für die W3C-Spezifikationen zu verwenden (das W3C wirft beides in seinem Plan-Dokument wild durcheinander). So würde uns einerseits der liebgewonnene Oberbegriff erhalten bleiben, andererseits könnte man über die nächste Version einer Auszeichnungssprache sprechen (oder eher schreiben), ohne sich dem Verdacht auszusetzen, ein JavaScript-Supernerd oder gar ein überhypter Nichtsblicker zu sein. Ob es soweit kommt, wird die Zeit zeigen, aber ich werde dieses System auf jeden Fall in Zukunft verwenden.

Dokumente und Recommendations hin oder her: was ändert sich denn nun durch die Standardisierung einer neuen HTML-Version? Eigentlich nichts.

Was sind die Auswirkungen?

Webstandards sind praktisch immer deskriptiv und nicht normativ. Eine Technologie wird nicht zum Standard, indem das W3C sie aufschreibt und folgsame Browserhersteller sie implementieren, sondern es läuft fast immer umgekehrt. Die Programmierer von Browser A erfinden ein neues Feature, die Programmierer von Browser B implementieren etwas ähnliches, man einigt sich auf einen einheitlichen Kompromiss und das W3C schreibt das Endergebnis auf. Somit dürfte klar sein, dass in dem fertigen Standard nichts drin stehen wird, was neu ist, sondern er wird die dann bestehende Browser-Realität abbilden und für die Zukunft festschreiben.

Für Webentwickler gibt es also eigentlich nichts, was sich im Q4 2014 ändert. Falls auch dann jemand noch den Internet Explorer 8 unterstützen muss (Gott bewahre!), so wird er sich nichts davon kaufen können, dass es eine Recommendation für

gibt, denn dieses Feature wird der IE8 auch 2014 nicht unterstützen. Auch wird die Standardisierung von HTML 5.0 nicht das Ende des zur Zeit chaotischen Entwicklungsmodells oder des allgemein „unfertigen“ Eindrucks der Web-Plattform bedeuten. Zwar wird dann einiges in Browsern möglich sein, was heute nur in Chrome-Nightlies funktioniert, doch dafür werden sich die Browser-Programmierer bis dahin neue Features ausgedacht haben, über deren Nichtfunktionieren wir uns dann aufregen können.

Wenn also aus „HTML5“ demnächst „HTML 5.0“ wird und es mit dem Recommendation-Stempel versehen wird, heißt es also aus der Perspektive der Webentwickler mal wieder: Raider heißt jetzt Twix … sonst ändert sich nix.

Fragen zu HTML5 & Co beantwortet 8 – CORS, Z-Index, Drag & Drop, Default-Styles

Peter Kröner — Mo, 29 Okt 2012 10:33:58

Dieser Artikel ist Teil einer Serie:

Es hat etwas gedauert, aber ich habe wieder vier Fragen und Antworten zu HTML5, CSS3 und Konsorten für euch zusammengekratzt. Warum kriege ich in letzter Zeit so wenig Fragen? Ihr wisst doch: eine E-Mail oder ein Tweet genügen!

How to CORS?

Ich möchte einen XMLHttpRequest an eine API machen, von der ich einen JSON-String abfragen werde. Wie bekomme ich das hin, dass ich keine Probleme mit Cross-Domain bekomme?

Normalerweise werden durch die Same-Origin-Policy (also durch den Browser) Zugriffe unterbunden, die von einer Webseite aus auf eine andere Webseite mit andere Domain unternommen werden. Die Technologie um das zu ändern heißt Cross-Origin Resource Sharing (CORS) und wird bereits von vielen Bowsern unterstützt. Um sie zu aktivieren muss man aber am Server Hand anlegen und einen speziellen Header verschicken – enable-cors.org erklärt wie das geht. Möchte man auch alte Internet Explorer mitschleifen, braucht man neben dem normalen Ajax-Code auch das IE-spezifische XDomainRequest-Objekt. Genaueres dazu weiß das CORS-Tutorial von HTML5 Rocks.

Z-Index und Opacity

Ich bin gerade mit dem nachlesen der siebten Fragerunde zu HTML5 und Co auf deinem Blog fertig geworden. Zum Thema, Transformation und z-Index war ich sehr verwundert, konnte mich aber an ein ähnliches Problem erinnern. Ich habe einfach mal die transformation-Anweisungen durch eine opacity-Angabe ersetzt. Siehe da ich habe das selbe Problem. Frage nun: ist es aus dem selben Grund? Gibts sowohl für die eine oder andere einen Workaround?

Ja, das ist in der Tat ganz ähnlich. Die Mechanik hinter Transformationen und Opacity ist fast die gleiche: die Kindelemente eines betroffenen Elements werden mit dem Elternelement zusammengerendert und nur dieses Gesamtwerk wird transformiert bzw. von Opacity-Effekt betroffen. Zitat Spezifikationen:

Conceptually, after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering [...] Since an element with opacity less than 1 is composited from a single offscreen image, content outside of it cannot be layered in z-order between pieces of content inside of it. For the same reason, implementations must create a new stacking context for any element with opacity less than 1. If an element with opacity less than 1 is not positioned, implementations must paint the layer it creates, within its parent stacking context, at the same stacking order that would be used if it were a positioned element with z-index:0 and opacity:1.

Von einem Workaround ist mir nichts bekannt. Das Außer-Kontext-Rendern ist offenbar ein unumgängliches Funktionsprinzip von Transformationen und Opacity.

Drag & Drop – kein Drop-Event im Firefox

Hast du eine Idee, wieso das Drop-Event von HTML5 Drag & Drop im Firefox nicht gefeuert wird? In Chrome funktioniert es ohne Probleme.

Kurze Antwort: das Problem lässt sich lösen, indem man das dragover-Event abfängt und mit preventDefault() abbricht, in etwa so:

dropziel.ondragover = function(evt){
    evt.preventDefault();
};

Lange Antwort: während einer Drag-Operation feuert eine ganze Menge Events und viele von denen muss man, wenn man die API verwenden möchte, einfach abbrechen, damit andere Events funktionieren. Das klingt erst mal verquer, hat aber schon so seinen Sinn. Es sollen schließlich die meisten Elemente in einer Seite keine Ziele für Drag & Drop sein und es ist ganz sinnvoll, auf diesen gar nicht erst drop-Events zuzulassen. Um ein Element zum potenziellen Ziel zu machen muss daher zunächst das dragover-Event abgebrochen werden.

Warum das neuerdings in Chrome nicht mehr nötig ist, darüber kann ich nur spekulieren. Entweder ist das ein Bug oder die Chrome-Entwickler finden ganz einfach diese Event-Abbrechen-um-Events-stattfinden-zu-lassen-Geschichte so blöde, dass sie sich bewusst dagegen entscheiden. Ich würde ihnen daraus auch keinen übergroßen Vorwurf stricken, denn die API ist im Originalzustand einfach zu bekloppt.

Wo stehen die Default-Styles?

Gibt es irgendwo eine Übersicht, welches Default-Styling für welche HTML5-Elemente existiert?

Diese Übersicht gibt es praktischerweise direkt in den HTML5-Spezifikationen. HTML5 hat den Anspruch, neben Tags und Attributen auch das ganze im Browser befindliche Drumherum zu spezifizieren – von URL-Parsern über Download-Algorithmen bis hin zu DOM-Features ist alles dabei. Und da dürfen die Default-Styles natürlich nicht fehlen.

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter 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.