Fragen zu HTML5 beantwortet

Veröffentlicht am 2. August 2010

Wenn ich Fragen zu HTML5 via E-Mail oder Twitter erreichen, ist es manchmal schade, dass einige sehr gute Fragen (nebst Antworten) der Allgemeinheit entgehen. Deshalb eröffne ich hier eine kleine Sammlung mit interessanten Fragen und meinen Antworten der letzten paar Wochen zum Buch und zu HTML5. Wenn es sich lohnt wird das eine kleine Artikelserie. Wer mehr Fragen hat: Nur raus damit, egal ob in die Kommentare oder per Mail oder anderweitig!

Warum HTML5?

Ich erkenne nicht so ganz den Vorteil von HTML5, abgesehen vielleicht von Video- und Canvas-Element. Warum sollte ich zu HTML5 migrieren?

Wenn dir HTML5 etwas überflüssig vorkommt, liegt das vermutlich daran, dass du an Websites denkst. Für Websites ist HTML5 aber nicht vorrangig gemacht, sondern für Webapplikationen. Für den neuen Firmenauftritt der Beispielmüller GmbH wird man vermutlich kein HTML5 brauchen (auch wenn es nicht schaden wird), wohl aber für Webapps, die Desktop-Anwendungen Konkurrenz machen sollen. HTML5 hieß nicht umsonst ursprünglich „Web Applications 1.0“. Für den Einsatz von HTML5 für Websites spricht neben den neuen semantischen Elementen und den neuen Features für Formulare vielleicht noch, dass die Syntax ein klein wenig einheitlicher und einfacher ist und Möglichkeiten zur Verkürzung bietet (sofern man denn auf so etwas steht). Man muss aber nicht migrieren – wenn man mit XHTML 1 oder HTML 4 alles machen kann was man möchte, kann man ruhigen Gewissens beim Altbewährten bleiben. Ich empfehle an dieser Stelle einfach mal einen Blick auf drei Dinge, für die man bereits jetzt mit HTML5 (im jedem Browser) anstellen kann.

Wann kommt das E-Book?

Wird es dein Buch auch als PDF oder ePub fürs iPad geben? Ständig eine Bibliothek in Papierform rumschleppen ist sehr lästig.

Ja, eine E-Book-Ausgabe (sowohl PDF als auch ePub) ist geplant und soll laut Verlag "in Kürze" (wann immer das auch genau sein mag) verfügbar sein. Ich werde es ankündigen wenn es soweit ist.

Welches Element für Fat Footers?

Sollte man sog. „Fat Footers“ (also Footer mit viel Inhalt, Linklisten o.Ä.) auch in eine <aside> packen? Oder in einen <footer>? Eine Blog-Sidebar und ein Fat Footer unterscheiden sich ja inhaltlich kaum.

Ein Footer gehört prinzipiell in ein <footer>-Element, denn genau dafür ist das Element da. Es ist laut Spezifikationen auch explizit für typische Fat-Footer-Inhalte freigegeben (...typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like). Dabei ist das <aside>-Element durchaus ähnlich, allerdings muss man beachten, dass es Sectioning Content ist, sich also auf die Outline auswirkt. Möchte man, dass ein Footer ein eigener Seitenbereich ist? Wahrscheinlich in den meisten Fällen nicht.

Wie rotiere ich Elemente auf einer Canvas?

Wie kann ich in einem canvas mit mehreren Elementen ein einzelnes Element rotieren ohne dass die anderen mitrotieren? Bei meinen Versuchen mit context.rotate() rotiert immer der gesamte Inhalt. Habe schon daran gedacht alle Elemente auf einzelne canvas zu zeichnen und diese per z-index übereinanderzulegen aber ich hoffe, Sie können mir einen einfacheren Weg zeigen.

Die Sache ist ganz einfach: es gibt keine „Elemente“ auf einer Canvas. Eine Canvas ist nur eine Malfläche mit Pixeln und rotiert wird immer nur das unsichtbare Koordinatensystem, an dem die Pixel gezeichnet werden. Mein Vorschlag für das Problem:

  1. context.save()
  2. context.rotate()
  3. „rotiertes“ Element zeichnen
  4. context.restore()
  5. alle anderen Elemente zeichnen

So kommt nur das zu rotierende Element in den Genuss eines gedrehten Koordinatensystems, während alle anderen nach dem Aufruf von context.restore() wieder anhand eines normalen Koordinatensystems gezeichnet werden.

Weitere Fragen?

Eure Fragen zu HTML5 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.

Hardware-Review: Logitech Wireless Presenter R400

Veröffentlicht am 30. Juli 2010

Logitech Wireless Presenter R400

Wer mir auf Twitter folgt, dem ist sicher nicht entgangen, dass ich diese Woche in München eine HTML5-Schulung gehalten habe. In Vorbereitung hierauf habe ich so manches gelesen und gekauft, unter anderem den Wireless Presenter R400 von Logitech. Dabei handelt es sich um eine Fernbedienung für Präsentationen mit eingebautem Laserpointer. Mein Fazit nach drei Tagen intensiver Dauer-Benutzung: Wer regelmäßig Slides an Leinwände wirft und dabei nicht vor seinem Computer festgenagelt sein will, muss so ein Teil haben.

Der 11cm lange Wireless Presenter R400 hat neben der Taste für den Laserpointer und einem kleinen An/Aus-Schalter an der Seite vier Tasten zur Steuerung von Präsentationen – Slide vor, Slide zurück, Abdunkeln und eine weitere Taste zum Starten der Präsentation. Hinzu kommt eine einfache Batterieanzeige. Der Anschluss an den Computer erfolgt über ein kleines USB-Modul, das im Presenter selbst verstaut wird und das keinerlei Installation bedarf. Mitgeliefert werden eine Bedienungsanleitung, zwei Batterien und eine schicke kleine Kunststofftasche mit Reißverschluss.

Die beigelegte Bedienungsanleitung ist freilich komplett überflüssig, da sich die Tasten selbst erklären und eine Installation wie gesagt nicht nötig ist. Die Reichweite von 15 Metern ist beachtlich und das Gerät liegt perfekt und rutschfest in der Hand, so dass man kreuz und quer durch den Raum toben und trotzdem immer seine Präsentation steuern kann. Sowohl unter Windows wie auch OS X und Linux funktioniert der Presenter ohne Mucken und erledigt zuverlässig seinen Job.

Logitech Wireless Presenter R400 (Detailansicht)

Mein einziger, winziger Kritikpunkt betrifft die Anordnung der Taste zum Abdunkeln, denn diese befindet sich genau unter der Taste für „Slide vor“. Ein Verwechseln der Tasten ist zwar aufgrund ihrer Formgebung ausgeschlossen (die Abdunkeln-Taste ist wesentlich kleiner und die „Slide vor“-Taste hat einen kleine Erhebung) und da die Tasten Vertiefungen haben, wird weitgehend verhindert, dass man abrutscht. Genau das ist mit aber im Eifer des Gefechts zwei mal passiert, was durchaus einer gewissen wurstfingerigkeit meiner Person anzulasten ist. Das Problem ist, dass bei diesem Abrutschen nach unten man dummerweise genau auf die Taste gerät, die durch ein Abdunkeln einen halben Totalschaden hervorruft. Vielleicht wäre es besser gewesen, an dieser Stelle die „Präsentation starten“ zu platzieren und diese so auszulegen, dass sie bei laufenden Präsentationen einfach nichts tut – so wäre ein versehentliches Abwürgen der Präsentation komplett ausgeschlossen.

Unterm Strich ist festzuhalten, dass wie gesagt der Logitech Wireless Presenter R400 ein Muss ist, wenn man öfter Slides an die Wand zu werfen gedenkt. Wer dererlei auch unter Zeitdruck machen muss, sollte vielleicht auch einen Blick auf die etwas kostenintensivere Deluxe-Variante R800 riskieren – hier ist neben verdoppelter Reichweite (wobei, wer braucht 30 Meter?) auch ein Display mit Timer geboten.

Warum Douglas Crockford HTML5 stoppen will (und warum das schwierig wird)

Veröffentlicht am 13. Juli 2010

We need to reset HTML5 and start over. Dieses Zitat von Douglas Crockford sollte in den vergangen Wochen an den meisten von uns ein- oder zweimal vorbeigescrollt sein. Egal ob auf Konferenzen oder im Interview, der Javascript-Altmeister wird nicht müde, zwar einige Ideen von HTML5 zu loben aber auch ganz klar zu sagen, dass es seiner Meinung nach ein Schritt in die falsche Richtung ist und eine Vollbremsung angebracht sei. Warum ist das so?

Das Problem, das HTML5 löst (nämlich dass bisherige Web-Technologien ein unzureichendes Rüstzeug für Webapps sind) ist laut Crockford nicht das Problem, das dem Web unter den Füßen brennt – vielmehr müsste Sicherheit die Top-Priorität genießen. Heutige Webbrowser machen es nämlich Übeltätern recht einfach: jedes Script, das auf einer Website läuft, darf alles – es darf Cookies setzen und auslesen, es darf die Website selbst verändern, es darf den User bitten sein Passwort einzugeben und vieles mehr. Sobald es einem Angreifer also irgendwie gelingt, einen <script>-Schnipsel irgendwo auf einer Website einzuschleusen (z.B. auf einer Profilseite in einem sozialen Netzwerk), kann er den Browser eines jeden Besuchers dieser Seite übernehmen. Das nennt man Cross-Site-Scripting (XSS).

XSS ist eine der größten Sicherheitslücken des Webs und gleichzeitig auch eins seiner besten Features, denn erst die umfassenden Privilegien für Scripts machen es möglich, Dinge wie Google-Maps, Facebook-Buttons und Flattr-Widgets mit zwei Zeilen HTML (besagten <script>-Schnipseln) einzubauen. Die Scripts dürfen die Seite selbst verändern um ihre Buttons und Bilder zu platzieren, was man ja Google, Facebook und Flattr durchaus gerne erlauben, Datendieben aber gerne untersagen würde. So einfach ist es aber nun eben nicht und HTML5 verändert an diesem Zustand nichts – im Gegenteil, Technologien wie Offline-Speicher eröffnen interessierten Kriminellen neue, attraktive Angriffsziele.

Douglas Crockford vertritt die Auffassung, dass Sicherheit wichtiger als neue HTML-Elemente sei. Seiner Ansicht nach gehört die HTML5-Entwicklung gestoppt bis ein besseres Sicherheitsmodell für den Browser erdacht und implementiert wurde. Danach sollen die Einzelteile von HTML5 Stück für Stück den neuen Sicherheitsvorgaben angepasst und re-implementiert werden. Alles andere verschlimmere nur die XSS-Problematik, die ohne Änderungen am Browser selbst nicht in den Griff zu kriegen sei.

Ich persönlich tu mich mit diesem Ansatz schwer, gleichwohl an der Diagnose, dass XSS ein Problem ist, natürlich nicht zu rütteln ist. Aber man muss auch sehen, dass dass das Kind HTML5 bereits in den Brunnen gefallen und auf dem Weg nach unten mindestens schon zum nervigen Teenager herangewachsen ist. Es ist schwer vorstellbar, dass da noch irgendeine Form von Reset möglich sein soll, zumal bekannt ist, wie lange es dauert, bis sich eine Technologie in wirklich allen Browsern auf breiter Front etabliert hat. Außerdem ist nicht zu vergessen, dass HTML5 ja selbst das Ergebnis eine geplanten Web-Resets, nämlich XHTML 2 ist – das Web ist eben nicht die Bühne für Resets oder Revolutionen, sondern viel mehr ein Ort der graduellen Veränderungsprozesse. Vor diesem Hintergrund habe ich so meine Probleme damit, We need to reset HTML5 and start over als einen ernst gemeinten, konstruktiven Vorschlag anzusehen. XSS reparieren, gerne – aber dafür HTML5 stoppen, das wird schon sehr schwierig.

Wozu braucht mein Browser eigentlich einen HTML5-Parser?

Veröffentlicht am 5. Juli 2010

Anlässlich der der Ankündigung, dass der Firefox 4 erstmals standardmäßig einen HTML5-Parser verwenden wird (für Webkit wird auch bereits einer entwickelt), erreichten mich diverse Fragen was das denn jetzt bedeuten würde. Wenn die Browser von heute keinen HTML5-Parser verwenden, was haben sie denn dann? Immerhin können die doch alle – mit Ausnahme des IE – HTML5-Elemente wie <canvas> und <video> darstellen, oder? Richtig ist, dass ein Oldschool-HTML-Parser und ein Parser nach den Regeln der HTML5-Spezifikation sehr viel gemeinsam haben und die wenigen Unterschiede nur selten sichtbar werden. Aber ganz überflüssig sind HTML5-Parser natürlich nicht.

Der Ist-Zustand

Die ersten kommerziellen Browser hatten das Problem, dass HTML als eine SGML-Anwendung konzipiert ist und eigentlich einen sehr komplexen Parser benötigt (SGML ist so etwas wie ein komplizierterer Vorfahre von XML). Für den Einbau eines SGML-Parsers hatte man damals mitten im Browserkrieg aber keine Zeit und so entwickelt man eigene, nicht dem dem Standard entsprechende Parser für HTML-Dokumente. Sie zeichneten sich durch eine hohe Fehlertoleranz aus und bewährten sich letztendlich – jeder moderne Browser verwendet heute zur Verarbeitung von HTML solche Nichtstandard-HTML-Parser.

Im Bemühen um größtmögliche Kompatibilität glichen die Kombattanten des Browserkriegs ihre jeweiligen Implementierungen miteinander ab, so dass also heute alle Browser ungefähr gleich weit von den Standards entfernte Parser haben. HTML5 löst dieses „Problem“, indem einfach die bestehende Parser-Realität zum Standard erhoben und nur minimal erweitert wird. Das funktioniert recht gut, weil zwischen den Browsern bereits Kompatibilität besteht und es relativ wenige Neuerungen gibt.

Was gibt es neues?

Das, was in den HTML5-Spezifikationen über Parser festgelegt wird, entspricht in weiten Teilen dem, was jeder Browser schon heute kann. Anders gesagt: So viel neues gibt es da gar nicht, denn ein HTML5-Element wie <canvas> unterscheidet sich ja, was die Verarbeitung des HTML angeht, nicht fundamental von einem <div>. Die mit dem Element stattfindenden Interaktionen durch den Nutzer sind vielleicht andere, aber letztlich sind beide nicht mehr als eine Node im DOM-Tree und ein Rechteck auf dem Bildschirm.

Die Parser-Realität anzuerkennen und den Ist-Zustand zu standardisieren bringt Zweierlei: Erstens ist es den Browserherstellern möglich, Ihre Implementierungen weiter aneinander anzupassen, sofern es noch nach Jahren des Abschreibens noch Differenzen gibt. Und zweitens gibt es einige wenige Parser-relevante HTML5-Features wie etwa das <math>-Element und Inline-SVG:

<p>
    Das hier ist Inline-SVG:
    <svg width="250" height="50">
        <rect width="250" height="50" fill="green" stroke="black" stroke-width="8" />
    </svg>
</p>
Inline-SVG

Solcherlei Extravaganzen, wie in diesem Fall die Einbettung in XML in HTML, funktionieren nur mit einem HTML5-Parser. Normale neue Elemente wie <canvas> und <section> sind von der Parser-Frage nicht betroffen, weil sie für den bloßen Aufbau eines Dokuments keine besondere Bedeutung haben. Hiervon ausgenommen ist der Internet Explorer < 9, der aufgrund seiner etwas anderen HTML-Verarbeitung mit unbekannten Elementen noch so seine Probleme hat.

HTML5-Parser jenseits des Firefox 4

Der HTML5-Parser wird zwar erstmals im Firefox 4 standardmäßig aktiviert sein, doch vorhanden ist er auch schon in Version 3.6. Dort kann man ihn aktivieren, indem man unter about:config den Schlüssel html5.enable auf true stellt. Wirklich etwas davon haben wird man nur, wenn man Seiten ansteuert, die entsprechende Features auch verwenden – sieht man einmal von möglichen Abstüzen der experimentellen Software ab.

Wer selbst ein Projekt mit HTML5-Parser anschieben möchte findet beim html5lib-Projekt Implementierungen in Python und PHP. Eine Java-Implementierung, die auch Basis des Firefox-Parsers ist, stellt validator.nu bereit.