HTML5 - DerzeitigeLeistungsfähigkeit Und Möglichkeitenin Bezug Auf Aktuelle Browser Undmobile Endgeräte

Masterarbeit
HTML5 Derzeitige Leistungsfhigkeit und Mglichkeiten in Bezug auf aktuelle Browser und mobile Endgerte
Zur Erlangung des akademischen Grades eines Master of Science - Media Processing and Interactive Services -
Fakultt Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Prof. Dr. Klaus Chantelau eingereicht von: Florian Schuhmann B. Sc. Matr.-Nr. 260357 Martin-Luther-Ring 18 98574 Schmalkalden Schmalkalden, den 6. Dezember 2011
Zusammenfassung Der Hype um HTML5 wird immer grer, doch was ist HTML5 genau und kann es schon genutzt werden? Diese Arbeit entstand im Zusammenhang mit dem spirit@fhs Projekt und beschftigt sich mit diesen Fragestellungen. Daher wird neben einer Einfhrung in das Projekt auch ein historischer Rckblick ber die Auszeichnungssprache HTML gegeben. Im weiteren Verlauf wird zuerst HTML5 in seinen Grundzgen nher vorgestellt bevor sich mehrere Kapitel verschiedenen neuen und interessanten Schnittstellen widmen. Diese werden zuerst beschrieben und dann mit Quelltextauszgen und Prototypen veranschaulicht und getestet. Da die Bandbreite an Neuheiten im Umfeld von HTML5 sehr gro ist, wird neben der Vorstellung von ausgewhlten Neuheiten ein berblick ber weitere neue Mglichkeiten geboten. Ein interessanter Bestandteil ist die Entwicklung von mobilen Apps mittels HTML5. Hierzu werden Applikationstypen unterschieden und relevante HTML5-Features genannt. Es wird aber auch Kritik an HTML5 gebt und ein Ausblick auf HTML.next gewhrt.
Abstract The hype about HTML5 is getting bigger, but what exactly is HTML5 and can it already be used? This work originated in connection with the spirit@fhs project and deals with these questions. Therefore, in addition to an introduction to the project, a historical review about the HTML markup language is given. First of all HTML5 is presented in its basic features before following chapters introduce various new and interesting interfaces. Those will be rst described and then explained and tested with source code statements and prototypes. Since the range of innovations is very broad within the eld of HTML5, it will be a part of presenting selected innovations with an overview of other possibilities. Developing mobile apps with HTML5 is also a very interesting part, thus the types of applications will be dierentiated and relevant HTML5 features are stated. Also criticism on HTML5 is represented and a preview on HTML.next will be provided.
Danksagung Ich mchte mich an dieser Stelle bei meiner Lebenspartnerin, Marie-Christin Reusche sowie bei meinen Eltern, Simona und Thomas Schuhmann, bedanken. Sie haben mich selbst nach der x-ten Spezikationsnderung immer wieder ermutigt, untersttzt und mir den Rcken freigehalten. Ein herzlicher Dank gilt Herrn Prof. Dr. Oliver Braun, der mir die Mglichkeit gab dieses Thema zu bearbeiten und stets bei Problemen oder Fragen zur Stelle war. Ein Dank geht auch an Herrn Prof. Dr. Klaus Chantelau, der gar nicht erst zgerte und sofort als Korreferent zur Verfgung stand. Mit Ronny Schleicher, Benjamin Ldicke und Sebastian Stallenberger kam es whrend der Zusammenarbeit zu interessanten und oft wilden Diskussionen, die uns neben Spa auch auf viele Ideen und Anregungen brachten - danke dafr. Bei Petra Stein, Ricardo Volkert, Marcus Denison und Marcel Ziener mchte ich mich fr das Lektorat dieser Arbeit bedanken. Fr groe Untersttzung in Sachen Grak und Design bedanke ich mich bei Stefanie Riewe, die unter anderem das Spirit-Logo entworfen hat. Auerdem gilt auch dem jetzigen PaDSLab Team mein Dank, da sie bei Fragen rund A A um L TEX immer Hilfestellungen gaben und die Erstellung dieser L TEX-Vorlage dadurch frderten. Finally Id like to thank Ian Hickson, Anne van Kesteren and other members of the WHATWG IRC channel, which always supported me with in solving my problems and questions.
Inhaltsverzeichnis
1 Einleitung 2 Das 2.1 2.2 2.3 Projekt spirit@fhs Was ist spirit@fhs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teilprojektvorstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . StudWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 3 4 6
3 HTML 8 3.1 Die Entwicklungsgeschichte von HTML . . . . . . . . . . . . . . . . . 8 3.2 Die Idee des Neuanfangs mit XHTML . . . . . . . . . . . . . . . . . . 10 3.3 Das neue Zugpferd: HTML5 . . . . . . . . . . . . . . . . . . . . . . . 11 4 HTML5 im berblick 4.1 Syntax . . . . . . . . . . . . . . . . . . . . . 4.2 Semantische Neuheiten . . . . . . . . . . . . 4.2.1 Neue Elemente zur Auszeichnung und 4.2.2 Microdata . . . . . . . . . . . . . . . 4.2.3 Barrierefreiheit mit WAI-ARIA . . . 4.3 Weitere nderungen im berblick . . . . . . 5 Geolocation API 5.1 Die API-Spezikation . . . . . . . . . 5.2 Wie funktioniert die Ortsbestimmung 5.3 Datenstrukturen und Funktionen . . 5.4 Welche Risiken entstehen? . . . . . . 5.5 Prototyp . . . . . . . . . . . . . . . . 6 Formularneuheiten 6.1 Formularelemente . . . . . . . . . 6.2 Formularattribute . . . . . . . . . 6.3 Input-Typen . . . . . . . . . . . . 6.4 Formularvalidierung . . . . . . . . 6.4.1 Automatische Validierung 6.4.2 Manuelle Validierung . . . 15 15 19 21 25 27 28 32 32 33 34 35 35 38 38 39 40 41 41 42
. . . . . . . . . . . . . . . . . . Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . . . in aktuellen . . . . . . . . . . . . . . . . . . . . .
. . . . . . Browsern? . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
7 Multimedia-Elemente 43 7.1 Die HTML-Elemente und ihre Attribute . . . . . . . . . . . . . . . . 43 7.2 Media-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.3 Prototyp eines Videoplayers . . . . . . . . . . . . . . . . . . . . . . . 46
Florian Schuhmann B. Sc.
Inhaltsverzeichnis 7.4
Fachhochschule Schmalkalden WS 2011/12
Weitere Mglichkeiten der Inhaltseinbindung . . . . . . . . . . . . . . 49 50 50 51 52 56 58 58 58 59 60 60 61 61 62 63 64 67 67 67 68 69
8 Canvas 8.1 Grundlagen . . . . . . . . . . . . . . . . . . . 8.2 Canvas API und der 2D-Context . . . . . . . 8.3 Prototyp zur Videobearbeitung im Browser . . 8.4 Canvas Frameworks und deren Mglichkeiten . 9 Weitere HTML5 APIs und Features 9.1 Oine Tauglichkeit . . . . . . . . . . . 9.1.1 Application Cache . . . . . . . 9.1.2 Web Storage . . . . . . . . . . . 9.1.3 Alternativen . . . . . . . . . . . 9.2 Kommunikationsmglichkeiten . . . . . 9.2.1 WebMessaging API . . . . . . . 9.2.2 Web Sockets . . . . . . . . . . . 9.2.3 Weitere Kommunikations-APIs 9.3 Interaktions-APIs . . . . . . . . . . . 9.4 Weitere Spezikationen . . . . . . . . . 10 HTML5-Apps 10.1 App-Typen . . . . . . . . . 10.2 Nativ vs. WebApp . . . . . 10.3 Relevante HTML5-Features 10.4 Spirit HTML5 Android App 11 Kritik, Ausblick und 11.1 Kritik . . . . . 11.2 Ausblick . . . . 11.3 Fazit . . . . . . Literaturverzeichnis Anhang A Optionale Tags der HTML5-Syntax Eidesstattliche Erklrung
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Fazit 74 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 77 81 82 87
VI
1 Einleitung
Das Internet stellt heute eine unverzichtbare Infrastruktur dar, welche mittlerweile hnlich wichtig ist wie andere Infrastrukturen, z.B. fr Verkehr und Stromversorgung. 1 Diese Abhngigkeit wird durch das Web 2.0 oder besser Mitmach-Web und seine Komponenten noch verstrkt. Kaum eine Person ist heute nicht in einem sozialen Netzwerk, bei Communities oder Twitter, angemeldet. Webseiten knnen schon nicht mehr als Dokumente, als welche sie konzipiert wurden, bezeichnet werden. Sie werden immer komplexer und wandeln sich zu richtigen Applikationen. Google zeigt mit Google Mail oder Google+ deutlich den Weg hin zu Web-Applikationen und weg von herkmmlichen Programmen. Ein weiteres eindrucksvolles Beispiel ist die Cloud9 IDE2 als Entwicklungsumgebung direkt im Browser. Die Entwicklung und Strukturierung von solchen Webseiten gestaltet sich immer schwieriger, da die Inhalte nicht nur immer komplexer werden, sondern auch der Nutzer-Komfort und die Systemintegration in den Mittelpunkt rcken. Das Schlimmste hierbei ist aber, dass das genutzte Werkzeug - HTML - aus dem Jahr 1999 stammt. In welche Richtung sich das Internet und die Webseiten entwickeln, war damals noch nicht abzusehen. Die Entwickler mssen allerlei Tricks anwenden, um die heutigen Anforderungen an Webseiten und damit Web-Applikationen zu erfllen. HTML5 als neue Version des Standards soll diese Missstnde in den Gri bekommen und das Web fr die Zukunft rsten. Daher beschftigt sich diese Arbeit mit HTML5 und den Spezikationen in dessen Umfeld, um die heutige Anwendung einer noch nicht fertigen Spezikation zu testen und deren Mglichkeiten zu prsentieren. Die Idee und Motivation hinter diesem Arbeitsthema entstand aus dem Fakulttsprojekt spirit@fhs, welches die Mglichkeit der Implementierung einer Studentenplattform mit HTML5-Mitteln bot. Dies schuf die Chance der Teilhabe an einer sichtbaren und positiven Vernderung in der Fakultt. Das Interesse mit einer greren Gruppe von Beteiligten an einem Projekt zu arbeiten und so interessante Erfahrungen in allen tangierten Bereichen zu sammeln war, ein entscheidendes Kriterium. Als groes Ziel stand anfangs die Entwicklung der studentischen Plattform mittels HTML5 im Mittelpunkt. Da die Integration von verschiedenen HTML5-Features in ein solches Portal vorerst keinen Sinn ergab, weitete sich dies schnell auf die Untersuchung und prototypische Entwicklung einiger Features ohne direkten Bezug zur Plattform aus. Auerdem soll HTML5 abgegrenzt werden, um so den Funktionsumfang besser erfassen zu knnen.
1 2
[Bra10, S. 103] Siehe http://cloud9ide.com/ oder http://ace.ajax.org/
Seite 1 von 87
1. Einleitung
Bevor sich die Arbeit aber diesem Themengebiet nhert, werden im Kapitel 2 das Projekt spirit@fhs mit seinen Teilprojekten sowie die studentische Plattform StudWeb vorgestellt. Das darauf folgende Kapitel widmet sich der Entwicklungsgeschichte von HTML. Es beginnt bei den Ursprngen des HTML und fhrt ber den versuchten Neuanfang mit XHTML hin zu HTML5. Das Kapitel 4 beschftigt sich mit dem Thema HTML5 und verdeutlicht die Syntaxunterschiede an Quellcodeauszgen. Weiterhin werden neue semantische Elemente, Microdata und die Barrierefreiheit, in diesem Kapitel aufgegrien, bevor im letzten Abschnitt ein grober berblick ber verschiedene Neuerungen gegeben wird. In den Kapiteln 5 bis 8 stehen spezische Neuheiten wie die Lokalisierung, Formulare und Multimedia-Elemente im Zentrum der Betrachtung. Dabei werden zuerst Grundlagen und Schnittstellen betrachtet. Im Anschluss folgt die Vorstellung der jeweiligen prototypischen Entwicklung. Die Vielfalt an neuen Schnittstellen und Spezikationen im Umfeld von HTML5 ist so gewaltig und schnelllebig, dass eine detaillierte Betrachtung all dieser im Rahmen der Arbeit nicht mglich wre. Dennoch versucht Kapitel 9 einen breiten berblick ber die vorhandenen Mglichkeiten zu gewhren. Die Entwicklung von mobilen Applikationen wird in Kapitel 10 beleuchtet. Hierzu erfolgt eine Unterteilung und Gegenberstellung von App-Typen sowie die Betrachtung von relevanten HTML5-Features fr diesen Bereich. Der letzte Abschnitt in diesem Kapitel befasst sich mit der Vorstellung einer auf das spirit@fhs Projekt ausgerichteten HTML5 Android App. Abschlieen wird diese Arbeit mit einem Blick auf kritische Punkte von HTML5 sowie einem Ausblick und dem Fazit. Der Quellcode der vorgestellten Prototypen ist in den Respositories Spirit-HTML5App und HTML5-experiments des GitHub Prols FlorianX zu nden.3 Die direkten Web-Adressen der betreenden Dateien werden in den Kapiteln nochmals als Funoten aufgefhrt.
https://github.com/FlorianX
Seite 2 von 87
2 Das Projekt spirit@fhs

Dieses Kapitel soll die Motivation fr diese Arbeit und die Zusammenhnge im Projekt spirit@fhs verdeutlichen. Dazu werden das Gesamtprojekt und die vorhandenen Teilprojekte vorgestellt. Weiterhin soll das Teilprojekt StudWeb, welches eine von mehreren prototypischen Entwicklungen dieser Arbeit darstellt, nher erlutert werden.
2.1 Was ist spirit@fhs?

Das Projekt spirit@fhs wurde im Jahr 2010 an der Fachhochschule Schmalkalden durch Herrn Prof. Dr. Oliver Braun initiiert. Die Projektbezeichnung ist ein Akronym und setzt sich wie folgt zusammen: SPIRIT = (ServicePoint: Information) => Read IT Diese Darstellung ist eine Anlehnung an die Programmiersprache Scala 1 . Der starke Bezug zur Programmierung mit neuen Technologien wird so schon in der Projektbezeichnung widergespiegelt. Damit das Ausprobieren und Testen von neuen Technologien nicht einfach ungenutzt verput, wird versucht, dass jede Applikation, die innerhalb dieses Projektes entsteht, einen Teil zu einem greren Ganzen beitrgt. Das grere Ganze ist in diesem Sinne eine neue Stundenplanungssoftware. Da die Fakultt Informatik in den letzten Jahren die neuen Studiengnge Bachelor Multimedia-Marketing, Bachelor IT-Servicemanagement und Master Media Processing and Interactive Services2 ins Leben gerufen hat, ist das alte auf Prolog3 -basierende Tool zur Stundenplanung an seine Grenzen gestoen. Dieses Tool ermglicht die Stundenplanung fr die zwei bis dahin bestehenden Studiengnge und bot weiterhin die Mglichkeiten eines einfachen Newsportals. Das Projekt spirit@fhs beschtigt sich mit der Neuimplementierung einer Stundenplanungssoftware und setzt dabei auf die Verwendung neuer und vielfltiger Technologien. So wurde bereits bei der Implementierung einer bergangslsung fr eine neue Informationsplattform fr Studierende die Programmiersprache Scala und das Framework Lift 4 verwendet. Diese Applikation trgt den Projektnamen News und ist auf dem spirit@fhs GitHub Account5 verfgbar.
Eine objektorientierte und funktionale Programmiersprache. Siehe http://scala-lang.org/ Ab Wintersemester 2011/12 umbenannt in Angewandte Medieninformatik. 3 Eine logische, deklarative Programmiersprache. 4 Ein Web-Framework fr Scala. Siehe http://liftweb.net/ 5 https://github.com/spirit-fhs
2 1
Seite 3 von 87
2. Das Projekt spirit@fhs
2.2 Teilprojektvorstellung
Spirit@fhs untergliedert sich derzeit in zwlf Teilprojekte, von denen neun aktiv bearbeitet werden. Die Bearbeitung von diesen Teilen erfolgt im Zusammenhang mit Master-, Bachelor-, Praktikums- oder einfachen Seminar-/Projektarbeiten. Die Abbildung 2.1 soll das Ausma des spirit@fhs Projekts verdeutlichen und die relevanten Kommunikationsbeziehungen zwischen den Teilprojekten nachvollziehbar machen. Sie zeigt die neun aktiven Projekte und deren Beziehungen zueinander.
Mobile Apps EmployeeWeb PlanningWeb
MIgrate
StudWeb
RESTful Service
Database alte Stundenplanung
Prolog
LCD-Pro
CARD READER AUDIO
LINE-IN PHONE MIC
SATA
USB
EJECT
DVD-RW
POWER
SELECT MENU
libSpirit
LCD-Pro
Esc
F1
~
F2
`
!
Tab
F3
1
@
F4
2
#
) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

Shift Alt Ctrl
F7 F8
F11 F12 F9 F10 +

_
Scroll Lock PrintScrn SysRq
Pause
NumLock
Break
CapsLock
Scroll Lock
Insert
Home
PageUp Delete End
NumLock
PageDown
* 7
8 4
Home
PgUp
6 1
End
+ 2 0 3
PgDn Ins . Enter Del
Shift Alt Gr
Ctrl
C
LCD-Pro
CARD READER
AUDIO
LINE-IN PHONE MIC
SATA
USB
EJECT
DVD-RW
POWER
SELECT MENU
Esc
F1
~
F2
`
!
Tab
F3
1
@
F4
2
#

Shift Alt Ctrl
F7 F8
F11 F12 F9 F10 +

_
Pause
NumLock
Break
CapsLock
Scroll Lock
Insert
Home
PageUp Delete End
NumLock
PageDown
* 7
8 4
Home
PgUp
6 1
End
+ 2 0 3
Shift Alt Gr
Ctrl
CARD READER
AUDIO
LINE-IN PHONE MIC
SATA
USB
EJECT
DVD-RW
POWER
SELECT MENU
Esc
F1
~
F2
`
!
Tab
F3
1
@
F4
2
#

Shift Alt Ctrl
F7 F8
F11 F12 F9 F10 +

_
Pause
NumLock
Break
CapsLock
Scroll Lock
Insert
Home
PageUp Delete End
NumLock
PageDown
* 7
8 4
Home
PgUp
6 1
End
+ 2 0 3
Shift Alt Gr
Ctrl
Florian Schuhmann
Abbildung 2.1: bersicht ber die aktuellen spirit@fhs Teilprojekte (Quelle: Eigene Darstellung) Den Mittelpunkt bildet derzeit das Database Projekt, welches einen RESTful Service bereitstellt und somit die Datenbank kapselt. Dieses Vorgehen ermglicht es, die genutzte Datenbank auszutauschen, ohne dass in den anderen Applikationen Anpassungen von Nten sind. Die aktuelle Version setzt auf eine PostgreSQL Datenbank, die durch EclipseLink 6 gekapselt wird, und auf einen RESTful Service, der mit Scala/Lift implementiert wurde. Weiterhin entsteht eine Client-Bibliothek libSpirit in C. Diese soll die RESTAnfragen so kapseln, dass es in den Programmierbungen auf einfache Weise mglich ist, Anfragen an die spirit@fhs-Datenbank zu stellen. Dies soll die Lehre auf praktische und interaktive Art und Weise untersttzen.7
EclipseLink ist ein Java Persistenz-Framework. Es wird hier als objekt-relationaler Mapper verwendet. Siehe http://www.eclipse.org/eclipselink/ 7 Quellcode: https://github.com/spirit-fhs/libspirit
6
Seite 4 von 87
Das Projekt PlanningWeb wird mit Scala/Lift implementiert. Es dient zur Verwaltung und Pege von Daten sowie Informationen, die fr die Stundenplanung bentigt werden. Weiterhin ist es der erste Schritt, um die derzeit manuell durchgefhrte Stundenplanung zu untersttzen. Die in dieser Applikation erzeugten Daten liegen aus Datenschutz- und Sicherheitsgrnden in einer eigenen und nicht in der globalen Datenbank-Applikation.8 Das Haskell 9 Projekt Migrate bildet die Schnittstelle zwischen alter und neuer Stundenplanung. Es soll die Stundenplanungsdaten vom alten System beziehen und diese dann aufbereitet in das neue System einspielen. Dieses Projekt stellt zustzlich die Schnittstelle zwischen dem PlanningWeb und der Database dar. Die in der Planung erzeugten Daten sind komplexer als jene, die in der globalen Datenbank bentigt werden. Daher muss auch hier eine Aufbereitung erfolgen.10 Das Backend fr Dozentinnen und Dozenten sowie fr wissenschaftliche Mitarbeiter wird im Projekt EmployeeWeb mit Scala/Lift erstellt. Es bietet die Mglichkeit, dass Informationen, die die Lehre betreen, in Form von News oder Terminen in spirit@fhs eingestellt werden knnen. Ein weiteres Feature ist die umfrageartige Vergabe von Referatsthemen.11 Das spirit@fhs Projekt springt auf den derzeitigen Hype um die Mobile Apps auf und bietet fr die Betriebssysteme Android, iOS und Windows Phone 7 jeweils ein AppProjekt an. Wie auch in den anderen Projekten wird versucht auf neue Technologien und Sprachen zu setzen. So wird die App fr das Google Betriebssystem mit Hilfe von Scala und dem Android SDK erstellt. Die Windows Phone 7 App basiert auf Silverlight 12 , XAML13 , C# 14 und F# 15 sowie Linq 16 . Das iPhone erhlt eine App die mittels HTML5, CSS3, PHP und jQuery 17 erstellt wird. StudWeb stellt das Web-Frontend fr Studenten dar. Dabei werden HTML5 clientseitig und das Zend Framework 18 auf der Serverseite genutzt. Dieses Projekt wird im folgenden Abschnitt 2.3 nher erlutert.19 Das bereits erwhnte Projekt News entstand aus einer Projektarbeit und ist aufgrund der Inaktivitt nicht auf der Grak zu nden. Es ndet derzeit nur eine Bearbeitung in Fehlersituationen statt.20
Quellcode: https://github.com/spirit-fhs/planningweb Eine rein funktionale Programmiersprache. Siehe http://haskell.org/ 10 Quellcode: https://github.com/spirit-fhs/timetable2db 11 Quellcode: https://github.com/spirit-fhs/employeeweb 12 Ist ein Framwork fr das Schreiben und Ausfhren von Rich Internet Applications. Siehe http: //www.silverlight.net/ 13 XAML ist eine von Microsoft entwickelte Beschreibungssprache fr Oberchen und Workows. Siehe http://msdn.microsoft.com/de-de/library/ms752059.aspx 14 C# ist eine objektorientierte Programmiersprache von Microsoft fr das .NET-Framework. Siehe http://msdn.microsoft.com/de-de/vcsharp/default.aspx 15 F# ist das funktionale Pendant zu C#. Siehe http://msdn.microsoft.com/de-de/fsharp/ 16 Linq ist Teil des .NET-Frameworks und dient zur Abfrage von unterschiedlichen Datenquellen. Siehe http://msdn.microsoft.com/de-de/netframework/aa904594 17 Ist ein umfangreiches JavaScript Framework. Siehe http://jquery.com/ 18 Ist ein PHP-Framework. Siehe http://framework.zend.com/ 19 Quellcode: https://github.com/spirit-fhs/studweb 20 Quellcode: https://github.com/spirit-fhs/news
9 8
Seite 5 von 87
Die eigentliche Stundenplanung wird vom Core durchgefhrt. Dieses Projekt wurde im Rahmen einer Praktikumsarbeit als Prototyp in Haskell umgesetzt.21 Eine weitere Arbeit, die sich mit diesem Themengebiet beschftigt, befasst sich mit der Erstellung einer Domain Specic Language fr die Abbildung von Stundenplandaten und deren Beziehungen in Haskell. Es nden zum jetzigen Zeitpunkt keine weiteren Arbeiten an diesem Komplex statt, weshalb auch dieses Projekt nicht auf der Grak zu nden ist. Mit Scala und dem Framework Akka 22 versucht das Projekt DistributedCalc die sehr rechenintensive Erstellung der Stundenplne auf verschiedene Ressourcen zu verteilen. Als Ressourcen knnten die PC-Pools der FH Schmalkalden, der Amazon Web Service oder gar Freiwillige, wie bei SETI@home, dienen. Dieses Projekt steckt noch in den Startlchern und wird daher nicht in der Abbildung aufgefhrt.
2.3 StudWeb
Das Projekt StudWeb soll als reines Studenten-Portal genutzt werden. Daher ist der Login nur fr Studenten mglich. Es bietet derzeit Funktionen zum Abrufen von aktuellen Nachrichten und den dazugehrigen Kommentaren. Weiterhin knnen eigene Kommentare zu den News verfasst und auch gelscht werden. Die Abbildung 2.2 zeigt die Single-Ansicht einer News, welche mit Kommentaren bestckt wurde. Das Portal soll die Studenten durch ein junges und frisches Design ansprechen.
Abbildung 2.2: Screenshot der Single-Ansicht einer News mit Kommentaren Das Layout des Portals wird mit Hilfe von eingebetteten Hintergrundgraken und Cascading Style Sheets erstellt. Des Weiteren setzt die Implementierung auf das JavaScript Framework jQuery und den Einsatz des HTML5 Living Standards. Bei der Darstellung des Layouts und der News wird hauptschlich auf die Verwendung neuer Tags, wie <article> oder <nav> zurckgegrien.
21 22
Quellcode: https://github.com/spirit-fhs/core Akka ist ein Scala-Framework und bietet bspw. Funktionalitten fr verteilte Systeme an. Siehe http://akka.io/
Seite 6 von 87
Ein weiteres Detail, welches prototypisch entwickelt wurde, ist der Stundenplan. Dieser ist nicht mehr statisch wie es der Vergleich in Abbildung 2.3 zeigt, sondern dynamisch und wird fr die jeweiligen Wochen erstellt. Das heit, dass Ausflle oder Verschiebungen im Stundenplan markiert und weitere Details angezeigt werden knnten.
(a) alter Stundenplan
(b) neuer Stundenplan
Abbildung 2.3: Vergleich alter statischer und neuer dynamischer Stundenplan Die Implementierung des Stundenplans basiert auf dem jQuery Kalender Plugin fullcalendar.23 Dieser wurde in der Darstellung der einzelnen Termine fr die Verwendung im StudWeb angepasst. Dies betrit die Anzeige von zustzlichen Feldern, wie Ort, Titel und Lehrbeauftragter. Die Termine knnen entsprechend ihres Typs oder aufgrund ihres Status eingefrbt werden. So sind bungen bspw. grn, Vorlesungen blau, ausgefallene Vorlesungen grau und verschobene Termine gelb. Weitere Details oder Informationen zu den Veranstaltungen werden beim berfahren eines Termins mit der Maus in einem Tooltip angezeigt. Der Kalender erhlt seine Daten ber eine JSON-Schnittstelle. Die serverseitige StudWeb-Implementierung basiert auf PHP und dem ZEND-Framework. Durch die Nutzung dieses Frameworks knnen ein modularer Projektaufbau und die Verwendung des Modell-View-Controller-Konzepts realisiert werden. Somit besteht die Mglichkeit, dass sptere Ideen oder neue Anforderungen als eigene Module in das System integriert werden knnten. Als weitere Module und Funktionalitten knnten in Zukunft eine Raumreservierung, ein Netzwerkkalender oder die Vergabe von Seminarthemen umgesetzt werden. Da sich diese Arbeit mit dem Thema HTML5 beschftigt, wird die serverseitige Implementierung mithilfe des ZENDFrameworks im Folgenden nicht weiter errtert.
23
Der angepasste Quellcode ist hier zu nden: https://github.com/FlorianX/fullcalendar
Seite 7 von 87
3 HTML
Das vorhergehende Kapitel hat das Projekt spirit@fhs und dessen Teile vorgestellt. Dabei wurde ein berblick ber die gesamte Projektstruktur und die verwendeten Techniken gegeben. Auerdem wurde das Teilprojekt StudWeb nher erlutert und in diesem Zusammenhang auch der Begri HTML5 genannt. Um diesen besser verstehen zu knnen, wird in diesem Kapitel der Weg von HTML ber XHTML zu HTML5 dargelegt.
3.1 Die Entwicklungsgeschichte von HTML

Die Entstehung von HTML ist auf ein Projekt von Tim Berners-Lee im Jahre 1989 zurckzufhren. Er entwarf am CERN 1 bei Genf das World Wide Web, welches die Hypertext Markup Language als Text-Auszeichnungssprache beinhaltete. Tim Berners-Lee schrieb in diesem Jahr seine Idee nieder und legte somit den Grundstein fr das heute bekannte HTML.2 Die hier enstandene erste Version von HTML basiert auf der Standard Generalized Markup Language (kurz SGML). Die Metasprache SGML ist ein ISO-Standard und dient zur Erstellung von Auszeichnungssprachen. Sie legt Regelstze fr den Aufbau eines Dokuments fest, dazu zhlen bspw. erlaubte Tag-Konstruktionen. Da diese Sprache sehr komplex ist, setzten die Browserhersteller nicht auf komplexe SGML-Parser, sondern entwickelten eigene HTML-Parser. Dies wird auch am folgenden Listing 3.1 deutlich. Es handelt sich dabei um gltiges SGML, welches aber selbst die heutigen Browser nicht interpretieren knnen: Listing 3.1: Beispiel eines gltigen SGML-Dokuments. <! DOCTYPE html PUBLIC " -// W3C // DTD HTML 4.01// EN " > <> < title / SGML - Dokument / <p/ erster und / <p <i > zweiter Absatz </i </ p > </ >
1 2
Die Europische Organisation fr Kernforschung. Vgl. [BL89]
Seite 8 von 87
3. HTML
Im Gegensatz dazu hier das fr Browser verstndliche HTML: Listing 3.2: Das HTML-Pendant. <! DOCTYPE html PUBLIC " -// W3C // DTD HTML 4.01// EN " > < html > < head > < title > HTML Dokument </ title > </ head > < body > <p > erster und </p > <p > <i > zweiter Absatz </i > </p > </ body > </ html > Beide Versionen sind valides HTML und werden vom Validator3 des W3C4 als solches gekennzeichnet. Hier zeigt sich bereits, dass sich das als Standard behauptet, was die Browserhersteller implementieren. HTML ist also als SGML-Anwendung entworfen und dann als solche in den folgenden Jahren weiterentwickelt worden. So wurde im Jahr 1992 die nur textorientierte Urversion von HTML verentlicht.5 Diese verbesserte Version wurde am Anfang des darauf folgenden Jahres berarbeitet und erhielt dabei neue Attribute bspw. zum Einbinden von Graken und Bildern. Die Entwicklung von HTML ging im selben Jahr noch weiter. Es sollte grundlegend berarbeitet und erweitert werden. Dies geschah durch David Raggett, welcher es als HTML+ verentlichen wollte, wozu es aber nie kam.6 Mit dem RFC18667 wurde im Jahr 1995 erstmals eine Versionsnummer in die Bezeichnung integriert. Weiterhin enthielt diese Spezikation die ersten Formularelemente. Die Version 3.0 hinkte den Entwicklungen im Internet und auf dem Browsermarkt hinterher und war vor ihrer geplanten Verentlichung schon veraltet. Daher erfolgte Anfang 1997 die Verentlichung der Version 3.2 von HTML, welche verschiedene Neuerungen und Elemente wie Tabellen, Applets oder die Textusssteuerung mit sich brachte.8 Im Dezember 1997 wurde bereits die Version 4.0 von HTML in den RecommendationStatus erhoben. Sie beinhaltete eine strikte Trennung von Inhalt und Darstellung, dies geschah durch die Einfhrung von Stylesheets. Weiterhin wurden Skripte und Frames sowie die HTML-Varianten Strict, Frameset und Transitional eingefhrt.9 Im Jahr 1999 erschien die bisher letzte und als Standard geltende Version HTML 4.01.
3 4
http://validator.w3.org/ W3C steht fr World Wide Web Consortium, welches das Standardisierungsgremium des World Wide Webs darstellt und im Jahr 1994 von Tim Berners-Lee in den USA gegrndet wurde. 5 Siehe [BL92] 6 Vgl. [Rag93] 7 http://tools.ietf.org/html/rfc1866 8 http://www.w3.org/TR/REC-html32-19970114 9 Vgl. [CAM97]
Seite 9 von 87
3. HTML
Diese enthlt verschiedene kleinere Anpassungen, Korrekturen und Optimierungen.10 Wie diese Entwicklungsgeschichte zeigt, sind Webstandards sehr schnelllebig und manchmal bei der Verentlichung schon veraltet. Trotz der vielen Versionen und Anpassungen von HTML bleibt es eine Auszeichnungssprache, die zu einer Zeit entstanden ist, zu der noch keiner die heutigen Wnsche, Mglichkeiten und Ausmae des World Wide Webs vor Augen hatte. Da die o. g. Standards meist nur der Praxis und damit den Browserherstellern hinterherliefen, sehnte sich das W3C nach einem Neuanfang: XHTML.
3.2 Die Idee des Neuanfangs mit XHTML

Die Idee der Extensible Hypertext Markup Language (kurz XHTML) kam im Jahr 2000 auf. Mit ihr wollte das W3C einen auf XML-basierenden Neuanfang starten, da sie fr die Erweiterung von HTML 4.0 keine Zukunft sahen. In discussions, it was agreed that further extending HTML 4.0 would be dicult, as would converting 4.0 to be an XML application. The proposed way to break free of these restrictions is to make a fresh start with the next generation of HTML based upon a suite of XML tag-sets. 11 Der Weg aus der komplexen SGML Vergangenheit heraus sollte also ber die Extensible Markup Language (kurz XML) fhren. XML ist genau wie SGML eine universelle Auszeichnungssprache. Sie basiert aber auf einfacheren Syntaxregeln bei denen es keine Ausnahmen gibt und besticht durch eine simple aber rigorose Fehlerbehandlung. Die Version 1.0 von XHTML12 war als bergangslsung geplant. Sie formulierte HTML 4.01 so um, dass die SGML-Basis durch XML ausgetauscht wurde. Des Weiteren wurde begonnen eine strikte Trennung von Inhalt und Formatierung zu denieren. In dieser ersten Version wurden aber zu Gunsten der Kompatibilitt zu HTML noch kleinere Formatierungen im Code erlaubt. Ein Jahr spter erschien bereits XHTML 1.113 , welches die o. g. Trennung nun strikter durchsetzte. Auerdem wurde eine Modularisierung der Elemente eingefhrt und nicht mehr bentigte Elemente, wie die HTML-Varianten bis auf Strict, ersatzlos gestrichen. Die XML-Revolution sollte mit XHTML 214 zur Vollendung kommen. Diese Version sollte viele Neuerungen und Befehle mit sich bringen, die vollkommen neu deniert wurden und somit auch nicht mehr auf HTML 4.01 basierten. Den Weg weg von HTML in Richtung XML wollten die Browserhersteller aber nicht gehen. Daher grndeten Mozilla, Apple und Opera im Jahr 2004 die Web Hypertext Application Technology Working Group (kurz WHATWG). Mit ihr sollen bestehende Technolo10 11
http://www.w3.org/TR/html401/ [RP98] 12 http://www.w3.org/TR/xhtml1/ 13 http://www.w3.org/TR/xhtml11/ 14 http://www.w3.org/TR/xhtml2/
Seite 10 von 87
3. HTML
gien unter dem Label Web Applications 1.0 (spter HTML5) zu neuen Technologien weiterentwickelt werden. Im Jahr 2006 gab es die ersten Interessensbekundungen des W3Cs an einer Beteiligung der Entwicklung von HTML5. Darauf folgte im Jahr 2007 die Grndung einer Arbeitsgruppe und die gemeinsame Arbeit am Standard HTML5. Im Juli 2009 wurde dann die Ausung der XHTML 2-Arbeitsgruppe fr das Ende des Jahres bekannt gegeben.15 Durch diesen Schritt steht nun der HTML5Entwurf im Zentrum der Aufmerksamkeit.
3.3 Das neue Zugpferd: HTML5

Bereits im Jahr 2006 hat Tim Berners-Lee in einem Blog-Eintrag aufgezeigt, dass der gewnschte Umschwung von HTML zu XHTML nicht funktioniert hat. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didnt work. 16 Zu diesem Zeitunkt geht die WHATWG bereits den Weg der inkrementellen Weiterentwicklung von HTML, die Berners-Lee als wichtig bezeichnet. HTML5 ist somit nur eine neuere Version von HTML 4.01, die aber als eigene Sprache und nicht mehr auf der Basis von SGML deniert wird. Die Standardisierung und Weiterentwicklung von HTML5 ist aufgrund der Vielzahl der vorhandenen Spezikationen und dem Vorhandensein von zwei Standardisierungsgruppen sehr undurchsichtig. Die WHATWG besa vor der Zusammenarbeit mit dem W3C nur eine umfassende Spezikation, welche HTML und weitere APIs 17 spezizierte. Diese wurde im Zuge der Zusammenarbeit in HTML5 umbenannt. Aufgrund des Standardisierungsprozesses des W3Cs, welcher auf eine HTML- und nicht auf eine umfassende Spezikation ausgerichtet ist, entelen diverse Spezikationsinhalte. Dadurch entschloss sich die WHATWG erneut eine separate Spezikation bereitzustellen, welche wieder als Web Applications 1.0 bezeichnet wurde. Die Verwirrung um den richtigen Standard wird noch verschrft, da seit Januar 2011 beide Arbeitsgruppen unterschiedliche Entwicklungsmodelle nutzen. Die HTML Working Group des W3C arbeitet mit einem versionsgetriebenen Ansatz auf einen fertigen Stand des HTML5-Standards zu. Dies beinhaltet aber auch die Einschrnkung, dass keine neuen Features mehr hinzugefgt werden knnen. Dieser Sachverhalt hat die WHATWG dazu gebracht, auf ein versionsloses Entwicklungsmodell umzusteigen. Dadurch wurde ein Living Standard geboren. Das heit, dass die von der WHATWG erstellte Spezikation stndigen Erweiterungen, nderungen und Korrekturen unterliegt. Im Zusammenhang mit der nderung des Vorgehens wurde auch der Name der WHATWG Spezikation von HTML5 zu HTML gendert.18
15 16
Vgl. [W3C09] [BL06] 17 API steht fr Application Programming Interface. 18 Siehe [Hic11b]
Seite 11 von 87
3. HTML
Die verentlichten Spezikationen beider Arbeitsgruppen werden aus einem einzigen Dokument19 generiert, welches von Ian Hickson20 gepegt wird. Die Trennung in jeweils eigene Spezikationen soll den Standardisierungsprozess untersttzen und beschleunigen. Am 4. Oktober 2011 wurden die beiden Spezikationen der WHATWG durch Ian Hickson wieder zu einer einzigen zusammengefgt. Dies hat zur Folge, dass die zusammenfassende Spezikation Web Applications 1.0 in HTML umbenannt wurde und die Spezikation HTML, welche ein Subset der Web Applications 1.0 Spezikation darstellte, nicht mehr existiert.21 Im Folgenden werden die einzelnen Spezikationsversionen kurz aufgefhrt und erlutert: HTML Dies ist die Zusammenfassung verschiedener Spezikationen der WHATWG und umfasst somit alle HTML-spezischen Inhalte sowie weitere APIs. Dieser Entwurf wird als Living Standard bezeichnet und enthlt neuere Features und Denitionen die in der Entstehung sind und noch nicht als stable bezeichnet werden knnen. http://www.whatwg.org/html HTML5 - W3C Diese Spezikation entspricht der o. g. Momentaufnahme und ist eine Untermenge des WHATWG HTML-Standards. Es werden nur noch Korrekturen und keine Erweiterungen an ihr durchgefhrt. Sie ist nur auf der Seite des W3Cs zu nden. http://www.w3.org/TR/html5/ HTML5 for Developers Diese Version ist speziell fr Web-Entwickler gedacht. Die Informationen fr Browserhersteller wurden bei dieser Version entfernt. http://developers.whatwg.org/ Wie bei der Entwicklerversion von HTML erwhnt, enthlt der HTML-Entwurf sehr viele Informationen, die nur fr die Browserhersteller wichtig sind. Dabei handelt es sich um Anforderungen, wie verschiedene Elemente interpretiert werden und um solche, die die Rckwrtskompatibilitt sicherstellen sollen. In der Spezikation wird daher klar zwischen den Anforderungen fr Entwickler und denen fr Browserhersteller unterschieden. Die HTML-Spezikation beschreibt also nicht nur die Sprache, sondern auch die Verarbeitung im Browser. Damit die Unterschiede in den verschiedenen Browsern bald der Vergangenheit angehren, soll zustzlich ein einheitlicher HTML-Parser deniert werden. Eine Test-Suite soll sicherstellen, dass die Spezikation und damit die beschriebenen Features in den Browsern vollstndig und
19 20
Siehe http://www.whatwg.org/specs/web-apps/current-work/source Er ist der Grnder der WHATWG und Angestellter der Google Inc. 21 Vgl. [Kes11b], http://twitter.com/WHATWG/status/121268735381221376 und http:// html5.org/r/6619
Seite 12 von 87
3. HTML
richtig implementiert wurden. Damit wird gewhrleistet, dass die Spezikation zum Zeitpunkt der Fertigstellung sofort genutzt werden kann. Der Standard wird also zusammen mit der Browserimplementation erstellt und nicht wie bisher zuerst der Standard und danach die chendeckende Untersttzung im Browser. Der Begri HTML5 kann also unterschiedlich aufgefasst werden: Als Momentaufnahme, wie beim Entwurf des W3Cs, als lebender und sich weiterentwickelnder Standard oder als eine Zusammenfassung verschiedenster Technologien, Standards und damit APIs. Die Abbildung 3.1 zeigt eine Zusammenfassung von neuen Standards und Technologien im Bereich des Webs, die in die Spezikationslandschaft des HTML5 eingeordnet werden.
Abbildung 3.1: bersicht ber das HTML5-Universum (Quelle: [Kr11b, S. 34]) Die kleinen Kreise stehen fr die einzelnen, eigenstndigen Spezikationen. Der innere blaue Kreis stellt die HTML5-Spezikation des W3Cs dar. Sie ist eine Teilmenge der WHATWG Spezikation und wird daher vom grnen Kreis umschlossen. Die blauen Spezikationen werden vom W3C, die grnen von der WHATWG und die orangenen von anderen Organisationen wie der IETF22 oder der Khronos Group23
22
Internet Engineering Task Force, befasst sich mit der Weiterentwicklung und Standardisierung des Internets (bspw. WebSockets). Siehe http://www.ietf.org/ 23 Ist ein Industriekonsortium fr die Erstellung und Verwaltung von Multimedia-Standards (bspw. WebGL). Siehe http://www.khronos.org/
Seite 13 von 87
3. HTML
erstellt. Eine Besonderheit bilden die Spezikationen innerhalb des grnen Kreises, welche von der WHATWG und dem W3C publiziert werden. Alles was sich innerhalb des gelben Kreises bendet wird bereits im Zusammenhang mit HTML5 genannt, wird aber teilweise nicht in den Spezikationen aufgefhrt. Wie diese Abbildung zeigt, gibt es nicht nur neue Elemente, schrfere Denitionen und Bewegung innerhalb der HTML-Spezikation, sondern auch eine Vielzahl neuer auen liegender APIs und Ideen. Da die HTML5-Spezikation des W3Cs neue Features, wie das Canvas, nicht enthlt und die der WHATWG nur noch ohne Versionsnummer vorhanden ist, wird in dieser Arbeit der leicht angepasste und gedehnte Begri von HTML5 verwendet, welcher in der Abbildung als gelber Kreis dargestellt ist. Im weiteren Verlauf der Arbeit werden verschiedene neue Elemente, Funktionen und APIs getestet. Manche davon gehren zum Entwurf des W3Cs oder sind im HTMLEntwurf der WHATWG enthalten. Dabei werden APIs, wie das Geolocation API, nicht ausgegrenzt, nur weil sie zu keiner der genannten Spezikationen gehren. Sie gehren dennoch zur Zukunft des Webs und damit wohl auch zum sich entwickelnden Schlagwort HTML5.
Seite 14 von 87
4 HTML5 im berblick
Das letzte Kapitel zeigte die Entwicklung vom Ur-HTML ber XHTML zum heutigen HTML5. Dabei wurden verschiedene Spezikationen und ihre Hintergrnde vorgestellt. In diesem Kapitel wird mit der Beleuchtung der technischen Seite von HTML5 begonnen. Dazu werden unter anderem die Syntaxdenition, semantisches HTML5 und die Untersttzung der Barrierefreiheit vorgestellt.
4.1 Syntax
Wie in Kapitel 3.3 erlutert, ist HTML5 nur eine Weiterentwicklung von HTML 4.01. Daher ist die spezizierte HTML5-Syntax kompatibel zu HTML4 und XHTML1. Wichtig hierbei ist aber, dass spezische SGML-Eigenheiten in HTML5 nicht mehr untersttzt werden, da sie einerseits in den meisten Browser nie umgesetzt wurden und sich andererseits HTML5 von SGML losgesagt hat. Dadurch das HTML5 nun keine SGML-basierte Anwendung mehr ist, entfllt auch der bisher ntige Verweis auf eine DTD 1 im Doctype. Der Doctype wird nur fr die Unterscheidung der Bearbeitungsmodi im Browser bentigt. Hier gibt es bereits die erste Besonderheit. Der Doctype ist in HTML5 nicht nur krzer, sondern auch case-insensitiv. Das heit, dass die folgenden Doctypes gltig sind und damit den Browser in den Standards Mode versetzen: Listing 4.1: Gltige HTML5 Doctypes <! DOCTYPE <! DOCTYPE <! doctype <! dOctYpe html > HTML > html > hTMl >
Im Vergleich dazu ein fest vorgeschriebener HTML 4.01 Doctype: Listing 4.2: HTML 4.01 Doctype <! DOCTYPE HTML PUBLIC " -// W3C // DTD HTML 4.01 Transitional // EN " " http :// www . w3 . org / TR / html4 / loose . dtd " > Die wohl bedeutendere Eigenschaft von HTML5 ist, dass es in HTML- oder XML (XHTML)-Syntax geschrieben werden kann.2 Im letzteren Fall wre der Doctype
1
Document Type Denition, ist die Zusammenfassung von Deklarationsregeln fr Dokumente eines bestimmten Typs. 2 Wenn ein HTML5-Dokument nach XML-Regeln erstellt wird, knnen HTML- und XML-Parser verwendet werden. Dies wird auch als polyglot markup bezeichnet. Siehe [Gra11]
Seite 15 von 87
4. HTML5 im berblick
optional, aber wenn er genutzt wird, dann ist nur die erste Variante des Listings 4.1 erlaubt. Fr die Verwendung von echtem XHTML5 gelten die strengen XML-Regeln und damit auch die rigorose Fehlerbehandlung. Auerdem muss das erstellte Dokument wohlgeformt sein, so muss fr jedes Start- auch ein End-Tag vorhanden sein. Falls im Dokument ein noch so kleiner Fehler auftritt, kann es vorkommen, dass das gesamte Dokument nicht dargestellt wird und nur ein XML-Fehler erscheint. Die Verwendung des XHTML-Stils zum Schreiben eines Dokuments reicht aber nicht aus, damit dieses auch als solches behandelt wird. Hierzu ist es ntig, dass der Content-Type im HTTP-Header einem der folgenden entspricht. Listing 4.3: Mgliche Content-Types application / xhtml + xml application / xml text / xml Erst dann wird das Dokument vom XML-Parser geparst. Dies war bisher bei XHTML1 nicht der Fall. XHTML1 wurde und wird zwar nach przisen XML-Regel geschrieben, aber vom Browser als normales HTML geparst. Durch die neue Denition, dass XHTML5 echtes XHTML und eine XML-Anwendung ist, wird bei der Verwendung des richtigen MIME-Typs der XML-Parser des Browsers genutzt. Damit nden die strikten XML-Regeln mit ihrer Fehlerbehandlung Anwendung. Ein gltiges XHTML5-Dokument knnte also wie folgt aussehen: Listing 4.4: Ein gltiges XHTML5-Dokument <? xml version = " 1.0 " encoding = " UTF -8 " ? > < html xmlns = " http :// www . w3 . org /1999/ xhtml " > < head > < title > Echtes XHTML5 </ title > </ head > < body > <p > Ein Absatz im XHTML5 - Dokument ! </p > </ body > </ html > Das XHTML5 nun echtes XHTML ist und es bei der Verwendung des richtigen MIME-Typs nicht mehr mit dem HTML-Parser geparst wird, heit aber nicht, dass der XHTML-Stil nicht zum Schreiben eines normalen - mit dem MIME-Typ text/html ausgelieferten - HTML5-Dokumentes verwendet werden kann. Sondern nur, dass der MIME-Typ fr die Unterscheidung zwischen HTML- und XML-Parser verantwortlich ist. Die Nutzung von XHTML5 steht nicht nur fr kritische Nebeneekte3 , sondern fr strikte und einheitliche Regeln und damit aufgerumten Code.
3
Dies bedeutet, dass mglicherweise eine gesamte Webseite nicht dargestellt wird, weil irgendwo im Dokument ein minimaler Fehler vorhanden ist.
Seite 16 von 87
Warum wird dies hier noch einmal so explizit angefhrt? Einfach aus dem Grund, da ein HTML5-Dokument auch in einem eher lockeren HTML-Stil verfasst werden kann. Im Gegenteil zum XHTML knnen (mssen aber nicht) bei der HTML-Syntax bspw. verschiedende Tags oder die Anfhrungszeichen bei Attributwerten einfach weggelassen werden.4 Hierfr sind zwar einige Regeln5 zu beachten und der Quellcode kann deutlich verkrzt werden, dadurch wird er aber sehr unbersichtlich. Ein entsprechendes HTML5-Dokument, welches Tags unterschlgt, aber trotzdem gltiges HTML5 ist, knnte wie folgt aussehen: Listing 4.5: Ein gltiges HTML5-Dokument <! doctype html > < meta charset = " UTF -8 " > < tiTlE > Ein HTML5 Beispiel </ TITLE > <P > Der erste Absatz im Dokument <p iD = example > Ein weiterer Absatz Die fehlenden Tags werden dann vom HTML-Parser hinzugefgt, damit ein korrektes Document Object Model6 entsteht. Das Listing 4.5 zeigt deutlich die Flexibilitt von HTML5 gegenber dem strikten XHTML5. Beim Auslassen von Tags leidet aber die Lesbarkeit und grere Dokumente werden schnell unbersichtlich. Die Lsung hierfr wre die Anwendung der strengen XHTML-Regeln auf ein normales HTML5Dokument, welches auch als solches mit dem MIME-Typ text/html ausgeliefert wird. Dabei gelten die drei wichtigsten Regeln: alle Tags nen und schlieen konsequente Kleinschreibung Attributwerte ausschreiben und in Anfhrungszeichen7 Dadurch entsteht ein sauber strukturiertes und fr Jedermann lesbares Dokument, welches gltiges HTML5 ist und leicht in echtes XHTML5 umgewandelt werden kann. Das obige Beispiel im XHTML-Schreibstil wrde wie folgt aussehen: Listing 4.6: Ein gltiges HTML5-Dokument im XHTML-Stil <! DOCTYPE html > < html > < head > < meta charset = " utf -8 " / > < title > Ein HTML5 Beispiel </ title > </ head > < body > <p > Der erste Absatz im Dokument </p >
4 5
Eine Auistung von optionalen Tags ist im Anhang A zu nden. Siehe [Hic11a, 13.1.2.4 Optional tags] 6 Kurz DOM, ist eine plattform- und sprachunabhngige Schnittstelle fr die Bearbeitung von HTML- und XML-Dokumenten. 7 Selbst boolsche Attribute, wie checked als checked=checked ausschreiben.
Seite 17 von 87
<p id = " example " > Ein weiterer Absatz </p > < input type = " checkbox " name = " XHTML_Checkbox " checked = " checked " / > </ body > </ html > HTML5 bietet also jegliche Freiheiten in Sachen Schreibstil, ob es als einfaches HTML5-Dokument, als HTML5-Dokument in XHTML-Stil oder als echtes XHTML5 abgefasst wird, es bleibt gltiges (X)HTML5. Die Unterschiede liegen also nur in der Lesbarkeit und dem im Browser verwendeten Parser, welcher die Tags in allen Fllen gleich interpretieren sollte. Kleinere technische (und teilweise versionsunabhngige) Besonderheiten8 zwischen HTML5 und XHTML5 bestehen in den folgenden Eigenschaften: Doctype - in HTML5 bentigt, um den Parser in den Standards Mode zu versetzen - in XHTML5 optional, muss bei Verwendung <!DOCTYPE html> entsprechen <noscript> - in HTML5 nur angezeigt, wenn JavaScript deaktiviert ist - in XHTML5 keine JavaScript-Abhngigkeit XML-Namensrume - in HTML5 ignoriert, da der Namensraum von Elementen wie <svg> oder <math> beim Parsen impliziert wird - mssen in XHTML5 explizit angegeben werden document.write() und document.writeln() - knnen in HTML5 genutzt werden - funktionieren in XHTML5 nicht Zeichensatz - in HTML5 ber HTTP-Header, Byte Order Mark oder den Meta-Tag9 - in XHTML5 ber die XML-Deklaration10 oder den HTTP-Header Der letzte wichtige Unterschied ist die bereits angesprochene Fehlerbehandlung von XHTML, welche beim kleinsten Fehler, bspw. einem fehlenden Anfhrungszeichen oder einem Grobuchstaben an der falschen Stelle, nur eine Fehlermeldung ausgibt und die Webseite nicht mehr darstellt. Auch bei der Verwendung der HTML-Syntax wre ein fehlendes Anfhrungszeichen ein Fehler. Dieser wrde aber im Gegensatz zu XHTML5 nicht dazu fhren, dass das gesamte Dokument nicht angezeigt wird. Durch die sehr exible Denition von HTML5 stehen die verschiedenen Syntaxen zur Wahl. Dies ermglicht auch die Nutzung eines polyglotten Markups, welches nicht die einzige interessante Neuheit von HTML5 ist, denn HTML5 untersttzt mit neuen Elementen die semantische Strukturierung von Webseiten und rstet sie so fr die Zukunft.
Weitere Dierenzen werden unter [WHAa] aufgefhrt. <meta charset=utf-8> oder <meta http-equiv=Content-Type content=text/html; charset=UTF-8> 10 <?xml version=1.0 encoding=UTF-8?>
9 8
Seite 18 von 87
4.2 Semantische Neuheiten

Die Syntax und Denition von HTML5 lsst viele Variationen des Quelltextes zu. Bei der Verwendung der HTML5-Elemente sollte daher groer Wert auf die eigentliche Bestimmung dieser Elemente gelegt werden. Die Elemente sollten also nicht zweckentfremdet werden. Eine Tabelle zur Gestaltung einer Liste ist vielleicht formal korrektes HTML5, aber aus semantischer Sicht der falsche Weg. Fr die korrekte Auszeichnung von Listen sind die Tags <ol> oder <ul> vorhanden. Die Bedeutung und der vorgesehene Verwendungszweck von Elementen ist fr die Interpretation einer Webseite bspw. in einem Screenreader sehr wichtig. Viele Elemente und Attribute in HTML5 haben ihre eigene Semantik, die fr eine weitere Verarbeitung entscheidend sein kann. Screenreader wandeln ganze Webseiten in Sprache um und lesen sie dann vor. Damit dies berhaupt mglich ist, muss eine Webseite gut strukturiert sein und die HTML-Mittel richtig eingesetzt werden. Dabei tritt das Problem auf, dass die heutigen Webseiten viel komplexer und verzweigter sind, als die Web-Dokumente, fr die HTML entworfen wurde.
Abbildung 4.1: Aufbereiteter Screenshot der Financial Times Deutschland Startseite (Quelle: Eigene Darstellung) Die Abbildung 4.1 zeigt den Kopfbereich im Vergleich zur gesamten Startseite der Financial Times Deutschland. Weiterhin wurden die strukturierenden Elemente in diesem Bereich farblich hervorgehoben.11 Zur Strukturierung der gesamten Startseite wurden mehr als 500 <div>-Elemente verwendet, wovon allein mehr als 50 im Kopf der Seite zu nden sind. Hinzu kommt, dass <div>-Elemente semantisch leere Hllen sind und damit eine semantische Strukturierung der Seite mit diesen Elementen fast unmglich12 ist. Ein weiteres Problem in diesem Zusammenhang ist die in HTML4 vorhandene Beschrnkung auf sechs berschriftsebenen. Das bedeutet, dass eine Webseite eigentlich nur in 6 Ebenen untergliedert werden knnte. Fr die heutigen komplexen Newsportale wie www.ftd.de sind auch hier die Grenzen schnell erreicht.
11 12
Zur Hervorhebung wurde das Firefox Plugin Web Developer (Version 1.1.9) verwendet. Um die Semantik in Webseiten einzubringen, wurde oft das rel-Attribut aus HTML4 verwendet. Dies funktioniert zwar an manchen Stellen, enspricht aber nicht den Spezikationen.
Seite 19 von 87
Eine Gliederung/Outline der Webseite ist aber enorm wichtig, da Screenreader diese zur Navigation verwenden und Suchmaschinen diese fr die Indexierung nutzen. Um die Beschrnkung zu verdeutlichen, wre folgende Verteilung der berschriftsebenen bei einer Redaktionsseite denkbar: <h1> <h2> <h3> <h4> <h5> <h6> Logo/Titel der Seite Rubriktitel Artikeltitel Artikelsubtitel inhaltliche Gliederung des Artikels Kommentare
Eine weitere Strukturierung und Hierarchisierung der Webseite oder eines komplexeren Artikels ist mit diesem Vorgehen fast gar nicht mglich. Das Einbinden von Web 2.0 Komponenten13 oder anderen Infoboxen, die in der Outline erscheinen und damit eine sehr groe und komplexe Webseite gliedern sollen, ist mit 6 Ebenen schier unmglich. Hier stoen viele Webseiten an ihre Grenzen und suchen daher Auswege. Listing 4.7: Quelltextauszug einer Teaserbox der Seite http://www.ftd.de/ < div class = " box boxTeaser boxImgWide " > [...] < span class = " date " > 15:12 </ span > < span class = " h4 " >Ifo - Index </ span > < span class = " h2 " > Rezessionsfaktor Merkel </ span > [...] Die Financial Times Deutschland verzichtet fast gnzlich auf die berschriftenelemente und funktioniert die <span>-Tags als solche um. Das Listing 4.7 zeigt die Anlehnung der CSS-Klassen an die HTML-berschriften in einem Ausschnitt einer Teaserbox. Diese <span>s erhalten zwar das Aussehen, jedoch nicht die Semantik von richtigen <h >-Elementen. Die Probleme an dieser Strukturierung sind, 1. dass die verwendeten <span>-Tags genauso wie die <div>-Elemente keine semantische Bedeutung haben und 2. sie dadurch auch nicht in einer Outline erscheinen wrden. Die Outline der Startseite der ftd.de sieht aufgrund der nicht genutzten berschriftenTags wie folgt aus: 1. Wirtschaft 1. Newsletter: Eilmeldungen Finanzen 2. Ein Fehler ist aufgetreten! 3. Vielen Dank fr Ihre Anmeldung14 Um diesen allgemeinen Problemen Herr zu werden, bringt HTML5 neue strukturierende Elemente mit sich, die im folgenden Abschnitt nher erlutert werden.
13 14
Rankings, Buttons der Social Network Seiten ect. Die Outline wurde mit dem Firefox Plugin Web Developer (Version 1.1.9) erzeugt.
Seite 20 von 87
4.2.1 Neue Elemente zur Auszeichnung und Strukturierung

Wie im vorhergehenden Abschnitt beschrieben ist die semantische Strukturierung einer Webseite mit Mitteln von HTML4 sehr schwierig. Daher werden mit HTML5 vier neue strukturierende Elemente eingefhrt, die zusammen mit den berschriftselementen die Struktur einer Webseite mageblich beeinussen. Die folgenden Elemente gehren zur Kategorie des sectioning content und beeinussen daher den Geltungsbereich von berschrifts- und Footerelementen. Durch dieses Verhalten ist es ab jetzt mglich, Webdokumente unendlich tief und vor allem auch semantisch zu gliedern. <section> Dieses Element dient zur inhaltlichen Gliederung einer Webseite und deren Inhalten. Es steht semantisch fr einen inhaltlich zusammengehrenden Abschnitt und sollte nicht fr Designzwecke genutzt werden.15 <nav> Das <nav>-Element zeichnet einen Webseitenabschnitt mit internen und externen Links als Navigation aus. Es sollte mit Bedacht eingesetzt werden, da es zum Auszeichnen von Hauptnavigationen entworfen wurde. Es kann mehrfach auf der Seite verwendet werden und knnte so auch eine Navigation in einem Artikel kennzeichnen.16 <aside> Zusatzinformationen knnen durch dieses neue Element ausgezeichnet werden. Hierbei knnte es sich um eine Sidebar, Metainformationen oder Werbung handeln.17 <article> Fr sich selbst stehende Inhalte gehren in das <article>-Element. Solche Inhalte knnten News, Blogposts, Kommentare oder Artikel sein. Bei der Verschachtelung dieses Elements ist darauf zu achten, dass das innere Element immer in Beziehung zum umgebenden Element stehen sollte. Ein Szenario fr eine derartige Verschachtelung wren Kommentare zu einem Blogpost. Falls ein <article> ein Verentlichungsdatum hat, kann dieses mit dem neuen Tag <time>18 maschinenlesbar ausgezeichnet werden.19 Diese neuen Elemente erzeugen neue Abschnitte in einem Webdokument und wirken sich auf die Geltungsbereiche von berschriften aus. Es gibt noch zwei weitere neue Elemente, die ihren Inhalt in eine Beziehung zu dem umgebenden Element stellen. Diese gehren nicht zur Kategorie sectioning content und erzeugen somit auch keinen neuen Abschnitt im Dokument.
Vgl. [Hic11a, 4.4.2 The section element] Vgl. [Hic11a, 4.4.3 The nav element] 17 Vgl. [Hic11a, 4.4.5 The aside element] 18 <time> wurde am 29.10.2011 in der Spezikationsrevision 6783 durch das allgemeinere <data> ersetzt. Dieses kann durch das value-Attribut nicht nur die Zeit, sondern alle mglichen Inhalte maschinenlesbar auszeichnen. Als Resultat der W3C Technical Plenary / Advisory Committee Meetings Week wurde am 10.11.2011 bekannt gegeben, dass <time> mit komplett neuer API wieder eingefhrt werden soll. Vgl. [Kes11c] 19 Vgl. [Hic11a, 4.4.4 The article element]
16 15
Seite 21 von 87
Hierbei handelt es sich um die Elemente <header> und <footer>, die wie folgt genutzt werden sollten: <header> Dieses Element dient zur Auszeichnung von hinfhrenden Inhalten, Navigationen und berschriften.20 <footer> Das <footer>-Element umfasst in Beziehung stehende Inhalte wie bspw. den Verfasser oder Copyright-Informationen.21 Beide Elemente knnen nicht nur auf die gesamte Seite angewendet werden, sondern auch auf andere HTML-Elemente wie im folgenden Beispiel: Listing 4.8: Mglicher HTML5-Aufbau einer Teaserbox < article > < header > < time pubdate datetime = " 2010 -08 -24 T14 :12+01:00 " > 15:12 </ time > < hgroup > <h2 > Ifo - Index </ h2 > <h1 > Rezessionsfaktor Merkel </ h1 > </ hgroup > </ header > [...] </ article > Das Listing 4.8 zeigt eine in HTML5 nachgebildete Teaserstruktur des Listings 4.7. Zur Auszeichnung der Teaserbox wurde das <article>-Element verwendet, welches ein <header>-Element enthlt. Als Kopfdaten wurden das Verentlichungsdatum, ausgezeichnet durch den <time>-Tag mit dem pubdate-Attribut, und eine Sammlung von berschriften verwendet. Diese Struktur ist nicht nur fr Laien, die sich den Quelltext ansehen, viel besser zu interpretieren, sondern auch fr Screenreader und Maschinen. Die Bedeutung der Inhalte wird bereits durch die HTML-Elemente und nicht mehr nur durch den Inhalt selbst bermittelt. Im Beispiel sticht ein weiteres neues Element heraus - das <hgroup>. Es dient als berschrift fr den Abschnitt in dem es steht und fasst mehrere berschriftsebenen zusammen. Bei der Erzeugung der Outline wird aus diesem Element nur die berschrift genutzt, die den hchsten Rang hat.22 In HTML5 sind die aus HTML4 bekannten berschriftselemente <h1> bis <h6> in selber Funktion enthalten. Sie bilden auch hier die inhaltliche Struktur des Dokuments mit dem Unterschied, dass sie nun abhngig von den vorgestellten strukturierenden Elementen eingesetzt werden knnen. Die Struktur bzw. Gliederung des Dokuments wird durch den Outline-Algorithmus erzeugt.23
20 21
Vgl. [Hic11a, 4.4.8 The header element] Vgl. [Hic11a, 4.4.9 The footer element] 22 Vgl. [Hic11a, 4.4.7 The hgroup element] 23 Siehe [Hic11a, 4.4.11.1 Creating an outline]
Seite 22 von 87
Die Outline ist abhngig von Sectioning Elementen. Sobald ein neues strukturierendes Element genet wird, knnen in diesem wieder die Elemente <h1> bis <h6> verwendet werden. Diese erscheinen dann in der Outline eine Hierarchieebene tiefer. Eine Seitengliederung sah bisher bspw. so aus: Listing 4.9: Gliederung nach HTML4 <h1 > spirit@fhs </ h1 > <h2 > StudWeb </ h2 > <h3 > HTML5 </ h3 > <h2 > EmployeeWeb </ h2 > Mit HTML5 knnte diese nun wie folgt ausgezeichnet werden: Listing 4.10: Gliederung mit HTML5 <h1 > spirit@fhs </ h1 > < section > <h1 > StudWeb </ h1 > < section > <h1 > HTML5 </ h1 > </ section > </ section > < section > <h1 > EmployeeWeb </ h1 > </ section > Beide Strukturen wrden die folgende Outline erzeugen: 1. spirit@fhs 1. StudWeb 1. HTML5 2. EmployeeWeb Die vorgestellten Elemente bieten die Mglichkeit Webseiten semantisch zu strukturieren und sie bis ins Unendliche zu gliedern. Um diese Neuerungen noch einmal ganzheitlich betrachten zu knnen, wurde folgende Webseitenstruktur erstellt: Listing 4.11: Beispielhafter Aufbau einer Webseite <! DOCTYPE html > < html > < head > < title > Beispiel </ title > < meta charset = " utf -8 " / > </ head > < body > < header > <h1 > Scala und deren Frameworks </ h1 > < nav > <h1 > Navigation </ h1 >
Seite 23 von 87
<ul > <li > <a href = " lift . html " > Lift </a > </ li > <li > <a href = " akka . html " > Akka </a > </ li > [...] </ ul > </ nav > </ header > < section id = " content " > < article > < footer > < div > Verfasser : Max Mustermann </ div > < time pubdate datetime = " 2010 -09 -01 T14 :14+01:00 " > 01 Sep .15:14 </ time > </ footer > < header > <h1 > Scala und deren Frameworks </ h1 > </ header > <p > Scala ist eine [...] Scala Frameworks : </p > < section > <h1 > Akka </ h1 > <p > [...] </p > </ section > < section > <h1 > Lift </ h1 > <p > [...] </p > </ section > </ article > </ section > < aside > <h1 > Sidebar </ h1 > <ul > <li > <a href = " impressum . html " > Impressum </a > </ li > </ ul > </ aside > < footer > <p > < small > Erstellt von Max Mustermann </ small > </p > </ footer > </ body > </ html > Das Listing 4.11 zeigt die Nutzung der vorgestellten Elemente in einer Webseite. Durch die Verwendung dieser neuen semantischen Elemente kann ein HTMLDokument viel leichter von Maschinen verstanden werden. Wenn Suchmaschinen und Screenreader bei HTML5 angelangt sind, kennen sie die Bedeutungen der Tags und knnen sie dementsprechend verwerten. Auf semantisch leere <div>-Elemente muss nur noch zurckgegrien werden, wenn es sich um Designaspekte handelt. Doch es gibt noch weitere interessante neue Elemente und Konzepte, die nichts mit Abschnitten und der Outline zu tun haben.
Seite 24 von 87
4.2.2 Microdata
Die bisher vorgestellten neuen Elemente erlauben die semantische Strukturierung einer Webseite. Fr die semantische Auszeichnung ist es in manchen Situationen wnschenswert, dass bestimmte Elemente standardisiert mit einer genaueren Bedeutung verknpft werden knnen. So knnten bspw. Suchmaschinen diese zustzlich bereitgestellten Informationen fr die Einstufung und Darstellung einer Webseite bei den Suchergebnissen nutzen. Ein Beispiel ist die Auszeichnung von Datums- und Zeitangaben durch das neue <time>-Element, welches bei richtiger Nutzung maschinenlesbar ist. Es hat aber nur durch die Verwendung des Attributs pubdate die Bedeutung des Verentlichungsdatums in Bezug auf das gesamte Dokument oder das nchstgelegene <article>Element. Ein Grndungsdatum wie im folgenden Listing kann also nicht explizit als solches gekennzeichnet werden. Listing 4.12: Auszeichnung eines Grndungsdatums <p > Die FH Schmalkalden wurde am < time datetime = " 1991 -10 -01 " > 1. Oktober 1991 </ time > gegruendet . </p > Damit ein Dokument mit weiteren Informationen angereichert werden kann, stellt HTML5 das Konzept der Microdata bereit. Hierbei werden HTML-Elemente durch die Verwendung von bestimmten Attributen zu items gruppiert und mit NameWert-Paaren angereichert. Die zwei wichtigsten Attribute sind: itemscope Dieses Attribut deniert ein Element, welches verschiedene und mehrfach verwendete Eigenschaften besitzen kann.24 itemprop Die Eigenschaften werden mit diesem Attribut gekennzeichnet. Das Attribut trgt einen oder mehrere Eigenschaftsnamen. Die Werte dazu benden sich vorwiegend innerhalb des HTML-Elements. Bei den Elementen a, area, audio, embed, iframe, img, link, object, source oder video kann die URL aus den Attributen href oder src als Wert verwendet werden.25 Bereits mit diesen beiden Attributen lsst sich das oben genannte Beispiel mit maschinenlesbaren Informationen anreichern. Listing 4.13: Auszeichnung eines Grndungsdatums mit Microdata <p itemscope > Die FH Schmalkalden wurde am < time datetime = " 1991 -10 -01 " itemprop = " foundingDate " > 1. Oktober 1991 </ time > gegruendet . </p >
24 25
Vgl. [Hic11a, 5.2.2 Items] Vgl. [Hic11a, 5.2.3 Names: the itemprop attribute]
Seite 25 von 87
Die folgenden Attribute sind nicht zwingend notwendig um zustzliche Informationen im Quellcode maschinenlesbar auszuzeichnen, sie sind aber hilfreich, wenn es um die standardisierte Nutzung und die Verwendungsmglichkeiten des MicrodataKonzepts geht. itemtype Dieses Attribut bestimmt den Typ eines Elements bzw. das Vokabular. Die Angabe eines Typs ist sinnvoll, da so ein standardisiertes Format genutzt werden kann. Der Typ wird als URL26 angegeben.27 itemref Das itemref-Attribut referenziert auf die IDs anderer Eigenschaften, die zum Element gehren, aber nicht in der Gruppierung stehen.28 itemid Die itemid ist eine global eindeutige Eigenschaft bspw. die ISBN eines Buches.29 Als bergreifendes Beispiel soll folgendes Listing dienen: Listing 4.14: Nutzung des Microdata-Organisationsschemas < div itemscope itemtype = " http :// schema . org / Organization " itemref = " x " > < span itemprop = " name " > PaDSLab </ span > < img itemprop = " image " src = " logo . jpg " alt = " PaDSLab " / > < span itemprop = " description " > Das PaDSLab unterstuetzt das Projekt spirit@fhs [...] </ span > < span itemprop = " url " > http :// pads . obraun . net / lab . html </ span > < time itemprop = " foundingDate " datetime = " 2011 -09 -01 " > 01.09.2011 </ time > < span itemprop = " employees founders " itemscope itemtype = " http :// schema . org / Person " > < span itemprop = " name " > Marcus Denison </ span > </ span > </ div > < div id = " x " > < span itemprop = " employees founders " itemscope itemtype = " http :// schema . org / Person " > < span itemprop = " name " > Christian Linde </ span > </ span > </ div > Das Listing 4.14 zeigt die Auszeichnung einer Informationsseite einer Organisation mithilfe eines Microdataschemas. Es wurde ein Element mit dem Typ
26
Seit Juli 2011 gibt es eine Kooperation zwischen den Suchmaschinen Bing, Google und Yahoo, welche auf http://www.schema.org/ ein Standardset an Schemas bereitstellen. 27 Vgl. [Hic11a, 5.1.3 Typed items] 28 Vgl. [Hic11a, 5.2.2 Items] 29 Vgl. [Hic11a, 5.1.4 Global identiers for items]
Seite 26 von 87
http://schema.org/Organization erzeugt. Diese Organisation hat die folgenden maschinenlesbar ausgezeichneten Eigenschaften: name = PaDSLab image = logo.jpg description = Das PaDSLab unterstuetzt das Projekt spirit@fhs[. . . ] url = http://pads.obraun.net/lab.html foundingDate = 2011-09-01
Weiterhin wurde ein auerhalb stehendes HTML-Element mit dem Attribut itemref der Organisation hinzugefgt. Die Eigenschaften employees und founders gehren dem Schema Person an und wurden zwei Elementen zugewiesen. Dies bedeutet, dass diese Eigenschaften jeweils die Personen mit den Namen Marcus Denison und Christian Linde enthalten. Dieses Vorgehen ermglicht es, dass Programme wie Browser und vor allem Suchmaschinen die Inhalte einer Webseite entsprechend ihrer Semantik verarbeiten und in einer gewissen Weise verstehen knnen. Microdata und die dazugehrige JavaScriptAPI ist aber bisher in noch keinem Browser implementiert. Durch Microdata protieren also die Suchmaschinen, doch was geschieht mit Screenreadern und im Bereich der Barrierefreiheit? Dies wird der folgende Abschnitt nher erlutern.
4.2.3 Barrierefreiheit mit WAI-ARIA

HTML5 macht auch im Bereich der Barrierefreiheit erstmals Fortschritte. Dabei setzt die HTML5-Spezikation auf Teile eines W3C Entwurfes fr ein barrierefreies Internet. Dieser Entwurf stammt aus der Arbeitsgruppe Web Accessibility Initiative und heit Accessible Rich Internet Applications (kurz WAI-ARIA). Er beschreibt die Anreicherung von Webseiten und deren bisher meist selbst gebauten und damit fr Screenreader schwer verstndlichen Widgets30 mit verschiedenen Rollen und Eigenschaften. Durch dieses Vorgehen werden solche dynamischen Webseiten fr die von Menschen mit Behinderungen genutzten Technologien besser verstndlich. Aus diesem Grund werden mit HTML5 die zwei HTML-Attribute role und aria-* aus der WAI-ARIA eingefhrt. Diese Attribute ermglichen ein barrierefreies Markup. Auerdem besitzen viele HTML5-Elemente eine implizite ARIA-Semantik. So mssen die bereits vorgestellten Strukturelemente oder die neuen Mglichkeiten der Formulargestaltung nicht extra ausgezeichnet werden. Wichtig hierbei ist, dass die verwendeten Angaben fr role und aria-* nicht der impliziten ARIA-Semantik widersprechen.31 Die Verwendung der Attribute ist relativ einfach und entspricht meist den Erwartungen. So gilt bspw. fr ein <nav>-Element immer role=navigation. Diese implizite Auszeichnung ist jedoch nicht in jedem Fall mglich. Daher mssen die eingefhrten Attribute richtig verwendet werden.
30
Dies sind meist selbst entwickelte und auf normalen HTML-Elementen beruhende Mens, Progressbars, Tabs, Slider und mit Ajax aktualisierte Bereiche. 31 Eine genaue Auistung der impliziten ARIA-Semantik ist hier zu nden: [Hic11a, 3.2.7 WAIARIA].
Seite 27 von 87
Listing 4.15: Formular mit Pichtfeld < form action = " post " > < label for = " name " > Name : </ label > < input type = " text " id = " name " aria - required = " true " / > [...] </ form > Bereits bei der Registrierung auf einer Webseite werden oft Felder mit JavaScript auf Korrektheit und Vollstndigkeit geprft. Doch ein Screenreader, der die Webseite vorliest, kann nicht wissen, welche Felder bentigt werden. Listing 4.15 zeigt die Verwendung des Attributs aria-required=true als Lsung fr dieses Problem. Durch die Nutzung dieses Attributs kann ein ARIA-fhiger Screenreader das entsprechende Element als Pichtfeld erkennen und dementsprechend verarbeiten. Listing 4.16: Barrierefreie Verwendung von Tabs < div id = " tabcontainer " > <ul id = " tabs " role = " tablist " > <li role = " tab " id = " tab1 " > Tab 1 </ li > <li role = " tab " id = " tab2 " > Tab 2 </ li > </ ul > < div id = " tab -1 " aria - hidden = " false " aria - labelledby = " tab1 " > [...] </ div > < div id = " tab -2 " aria - hidden = " true " aria - labelledby = " tab2 " style = " display : none " > [...] </ div > </ div > Ein weiteres Beispiel zeigt Listing 4.16. Hier wurde die auf sehr vielen Seiten verwendete Tab-Darstellung mit den neuen Attributen angereichert. Dadurch ist das aus einer Liste und <div>-Elementen bestehende Widget fr einen Screenreader besser verstndlich ausgezeichnet. HTML5 schat es also, dass Webseiten barrierefreier und semantisch besser strukturiert werden knnen. Was sich noch gendert hat, zeigt das folgende Kapitel in einem berblick.
4.3 Weitere nderungen im berblick

In den letzten Kapiteln wurden verschiedene interessante neue Elemente und Attribute vorgestellt, die durch HTML5 zu einem Standard zusammengefasst werden. Es knnen aber nicht alle nderungen betrachtet werden, da es unzhlige kleine und groe Neuerungen zu verbuchen gibt. Im Folgenden sollen daher weitere wichtige Neuheiten zusammengefasst vorgestellt werden, bevor sich die nchsten Hauptkapitel mit den jeweiligen APIs nher beschftigen. In HTML5 wurde nicht nur die Syntax leicht modiziert und eine Vielzahl neuer Elemente eingefhrt, es wurden auch die Inhaltsmodelle der HTML-Elemente vollstndig berarbeitet. In HTML4 gab es nur Block- und Inline-Elemente, die zu-
Seite 28 von 87
sammen den sogenannten Flow-Content bildeten. Dies ndert sich nun mit HTML5 und wird ein Stck weit komplexer.
Abbildung 4.2: Content-Modelle in HTML5 (Quelle: [Hic11a, 3.2.5.1 Kinds of content]) Da HTML5 keine SGML-Anwendung mehr ist, besitzt es auch keine DTD. Somit sind die Content-Modelle nicht mehr als DTD-Entities deniert und dienen nur noch als beschreibende Ausdrcke oder Kategorien. Die Abbildung 4.2 zeigt die neuen Kategorien, in die ein Element fallen kann, aber nicht muss. Metadata Dies sind Daten, die die Darstellung, das Verhalten oder die Beziehungen des Inhaltes oder des Dokumentes beeinussen. Beispiele dafr sind <title>, <style> oder <script>. Die Teilschnittmenge rhrt daher, dass Metadaten auch auerhalb des Dokumentenkrpers vorkommen knnen. Flow Diese Kategorie beschreibt den Inhalt des Dokumentes, weshalb fast alle HTMLElemente dieser Kateogrie zugeordnet werden knnen. Sectioning Elemente, die zu dieser Kategorie zhlen, beeinussen den Geltungsbereich von Header- und Footer-Element. Dies sind die in Kapitel 4.2.1 vorgestellten neuen strukturierenden Elemente. Heading Diese Kategorie umfasst alle Elemente, die mit berschriften zu tun haben und somit die Outline eines Abschnittes bilden. Dazu zhlen die Elemente <h1> bis <h6> sowie <hgroup>. Phrasing Hierbei handelt es sich um den Text eines Dokumentes sowie Elemente die diesen in irgendeiner Weise auszeichnen. Dies umfasst bspw. die Elemente <a>, <time> und <video>.
Seite 29 von 87
Embedded Dies sind Elemente, die externe Ressourcen importieren oder Inhalte einbinden, die einem anderen Namensraum angehren. Dabei handelt es sich bspw. um die Elemente <audio>, <img> oder <svg>. Interactive Zu dieser Kategorie zhlen die Elemente, die eine Nutzerinteraktion anstreben. Das sind bspw. die Elemente <button>, <img> (in Verbindung mit einer <map>) und <select>. Dadurch, dass HTML5 abwrts kompatibel speziziert wird, sind trotz der kompletten Umgestaltung der Modelle nur geringfgige nderungen sprbar. So knnen nun bspw. <a>-Elemente alle anderen HTML-Elemente umschlieen.32 Weiterhin wird mit HTML5 die Globalisierung von einigen HTML-Attributen eingefhrt. Attribute wie class, id und tabindex knnen so erstmals von allen Elementen getragen werden. Auerdem wurden die Standard-Typen text/javascript fr <script> und text/css fr <style> festgelegt und mssen damit nicht mehr explizit als type-Attribut angegeben werden. Die HTML5-Spezikation legt aber nicht nur Standard-Typen und neue Elemente fest, sondern auch eine Streichliste33 und wie die darauf bendlichen Elemente vom Browser behandelt werden mssen. Unter den gestrichenen Elementen benden sich bspw. Frames, Doctype-Varianten und reine Prsentationselemente wie <big>. Hier ist zu beachten, dass manche dieser Prsentationselemente einfach umdeniert wurden. So steht <small> nicht mehr fr kleinen Text, sondern fr Zusatzinhalte oder Kleingedrucktes und <hr> kommt nun nicht mehr als einfache horizontale Trennlinie zum Einsatz, sondern markiert einen thematischen Umbruch im Abschnitt. Die HTML5-Spezikation kann aber noch mehr als nur umdeklarieren und streichen, sie kann auch adaptieren. Dies gilt im Speziellen fr die Ruby-Anotationen, die Anmerkungen unterhalb des eigentlichen Textes sind. Diese stammen aus XHTML 1.1 und wurden, genauso wie die Standards SVG34 und MathML35 , in HTML5 integriert. Listing 4.17: Beispiel einer MathML-Struktur fr ein HTML5-Dokument < math > < msup > < msqrt > < msup > < mfenced open = " ( " close = " ) " > < mrow > <mi >a </ mi > <mo >+ </ mo > <mi >b </ mi > </ mrow > </ mfenced > <mn >2 </ mn >
32 33
Vgl. [Hic11a, 3.2.5 Content models] Siehe [Hic11a, 16 Obsolete features] 34 Scalable Vector Graphics sind XML-basierte, zweidimensionale Vektorgraken. 35 Mathematische Formeln knnen mit der auf XML-basierenden Mathmatical Markup Language dargestellt werden.
Seite 30 von 87
4. HTML5 im berblick </ msup > </ msqrt > <mn >4 </ mn > </ msup > </ math >
Das Listing 4.17 zeigt die MathML-Auszeichnung der Formel (a + b)2 . Wie im Kapitel 4.1 erwhnt, muss bei der Verwendung des <math>-Elements in HTML5 kein Namensraum angegeben werden, da die Spezikation die Implizierung dessen vorsieht. Somit knnte der Quellcode aus dem Listing in ein HTML5-Dokument eingefgt werden und ein MathML-fhiger Browser wrde die Formel anzeigen. Dasselbe ist mit SVG-Graken durch das neue Element <svg> mglich. Bei beiden Elementen ist aber darauf zu achten, dass HTML5 nur die Container, also die genannten Elemente, speziziert und nicht deren Untersttzung. Diese kann also zwischen den Browsern sehr stark schwanken. HTML5 bringt noch weitere Neuheiten wie die Abfragesprache XPath36 , Attribute zur Steuerung der Ausfhrung von JavaScript und neue DOM-Methoden wie getElementsByClassName() mit sich. Auf die Beleuchtung dieser meist kleineren Neuheiten wird aufgrund der Vielzahl und des sich stndig weiterentwickelnden Living Standards verzichtet. Der dieser Arbeit zugrunde liegende erweiterte HTML5 Begri umfasst nicht nur die bisher vorgestellten Neuerungen in Bezug auf die HTML-Elemente und deren Spezikation, sondern auch die neuen JavaScript APIs. HTML5 beinhaltet neben dem reinen Markup auch neue Schnittstellen wie das Geolocation API, das API zur Formularvalidierung sowie das API fr das <canvas>-Element, welche in den folgenden Kapiteln nher vorgestellt und in prototypischen Entwicklungen veranschaulicht werden.
36
XML Path Language
Seite 31 von 87
5 Geolocation API
Dieses Kapitel widmet sich dem Geolocation API und dessen Ortsbestimmung. Das API war anfangs Teil der WHATWG Spezikation, wurde aber dann als eigenes Projekt ausgelagert und bendet sich nun im Standardisierungsprozess des W3Cs. Laut dem Zeitplan der Geolocation Working Group sollte die Spezikation im 2. Quartal 2011 den Status Proposed Recommendation und im 4. Quartal 2011 Recommendation erhalten.1 Der Entwurf ist aber noch als Candidate Recommendation gekennzeichnet, da er Referenzen zum Web IDL-Spezikationsentwurf enthlt. Erst wenn der Web IDL-Entwurf den Status Last Call2 erreicht, wird auch das Geolocation API auf das nchste Podest gehoben.3 Dieses API gehrt also nicht zu einer HTML5-Spezikation, wird aber dennoch im Zusammenhang mit HTML5 sehr oft verwendet. Dies liegt vielleicht daran, dass mit HTML5 nicht nur neue HTML-Elemente, sondern auch eine Vielzahl von neuen JavaScript Schnittstellen eingefhrt werden.
5.1 Die API-Spezikation

Das Geolocation API stellt ein high-level Interface fr die Abfrage von nutzer- bzw. hardwarebezogenen geograschen Positionsdaten zur Verfgung. Wichtig ist, dass nur die Funktionsinterfaces und Datenstrukturen speziziert werden, aber nicht woher die Positionsdaten kommen. Das API wird als agnostisch (unwissend) ber die Herkunft der Daten deniert. Die Spezikation gibt lediglich die folgenden mglichen Ressourcen fr ortsbezogene Informationen an: Global Positioning System (GPS) IP-basierte Ortsbestimmung RFID WiFi und Bluetooth MAC-Adressen4 Funk-Zellen direkte Nutzereingabe5
Diese Ressourcen sind die am hugsten genutzten Mglichkeiten zur Bestimmung des Standortes. Ein Browser kann diese oder auch andere Quellen nutzen, um die
1 2
Vgl. http://www.w3.org/2008/geolocation/ Deadline hierfr ist der 18. Oktober 2011. Siehe http://www.w3.org/TR/WebIDL/ und http: //lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0467.html 3 Vgl. http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0048.html 4 Die Media Access Control Adresse ist die physikalische Adresse der verwendeten NetzwerkHardware. 5 Vgl. [Pop10, 2 Introduction]
Seite 32 von 87
5. Geolocation API
Positionsdaten zu ermitteln und sie dann ber das API standardisiert zur Verfgung zu stellen. Dabei ist wichtig, dass ein Nutzer des API und auch das API selbst nicht wissen woher die Daten stammen. Weiterhin wird in der Spezikation festgeschrieben, dass eine Umsetzung des API einen Mechanismus zum Schutz der Nutzerdaten enthalten muss und diese nur mit ausdrcklicher Genehmigung des Nutzers eingeholt werden drfen.6
5.2 Wie funktioniert die Ortsbestimmung in aktuellen Browsern?

Die Browser Firefox, Chrome und Opera nutzen zur Bestimmung des Standortes den Google Location Service. Microsoft verwendet im Internet Explorer den hauseigenen Ortungsservice Microsoft Location Service. Der einzige Unterschied ergibt sich in der Genauigkeit der bestimmten Position. Bei der Implementierung des Prototypen el auf, dass der Google Location Service meist nur wenige Meter neben der wirklichen Position lag. Die Bestimmung beim Internet Explorer lieferte bspw. eine Position in Weimar anstatt Schmalkalden. Diese Unterschiede knnen mit der vorhandenen Datenmenge oder mit dem Berechnungsverfahren des genutzten Services in Verbindung stehen. Zur Positionsbestimmung sammeln alle Browser die folgenden Daten: entliche IP-Adresse Informationen zu WLAN-Netzwerken in der Umgebung MAC-Adressen Netzwerknamen (SSID7 ) Signalstrken Diese gesammelten Informationen werden dann an den entsprechenden Location Service gesendet. Beide Serviceanbieter vergeben eine zufllige Identikationsnummer und gleichen die empfangenen Daten mit ihrer Geodatenbank ab. Dabei wird eine ungefhre Position trianguliert, welche dann an den Browser zurckgeliefert wird.8 Die Genauigkeit der berechneten Position hngt von der Gre der zugrunde liegenden Geodatenbank und der verwendeten Triangulationsverfahren ab. Im Hinblick auf die Verfahren sind nur Spekulationen mglich, ber die Befllung der Geodatenbanken sind genauere Informationen bekannt. So werden die Daten einerseits aus den Nutzern der Services und andererseits durch mobile Teams der Unternehmen generiert.9
6 7
Vgl. [Pop10, 4 Security and privacy considerations] Der freiwhlbare Name von Funknetzen wird als Service Set Identier bezeichnet. 8 Siehe [Moz11],[Inc11], [ASA11] und [Zei11] 9 Siehe [Mic11, How does Microsoft assemble a Wi-Fi location database?]
Seite 33 von 87
5. Geolocation API
5.3 Datenstrukturen und Funktionen

Die Spezikation des Geolocation API erweitert das navigator-Objekt um das neue geolocation-Objekt. Damit stehen dem Browser drei neue Funktionen fr die asynchrone Bestimmung der Position zur Verfgung: void getCurrentPosition(successCallback [, errorCallback, opt]) Hierbei handelt es sich um die einfache Positionsbestimmung, welche auch als one-shot request bezeichnet wird. Diese Methode erwartet eine CallbackMethode fr den Erfolgsfall. Weiterhin knnen ein Fehler-Callback und ein Kongurationsobjekt optional bergeben werden. long watchPosition(successCallback [, errorCallback, opt]) Diese Methode unterscheidet sich von der obigen nur darin, dass sie die Position berwacht. Das heit, wenn sich die Position ndert, wird erneut der Erfolgs-Callback mit den neuen Positionsdaten aufgerufen. Auerdem liefert diese Methode eine Prozess-ID als Rckgabewert. void clearWatch(watchId) Der mit watchPosition gestartete berwachungsprozess kann anhand der oben genannten ID identiziert und mit dieser Methode abgeschaltet werden. Fr die Konguration der Positionsbestimmung ist das Objekt opt vorgesehen. Dieses kann die drei Eigenschaften enableHighAccuracy, timeout und maximumAge enthalten. Die beiden Letzteren werden in Millisekunden angegeben und stehen einerseits fr die maximale Wartezeit und andererseits fr das maximale Cache-Alter der Daten. Das Setzen von enableHighAccuracy: true soll bewirken, dass genauere Daten gesammelt werden und diese die Przision erhhen. Im Fehlerfall wird der errorCallback ausgefhrt. Dabei wird ein Fehlerobjekt bergeben, welches die Eigenschaften message und code enthlt. Die bergebene Nachricht soll lt. Spezikation nur fr Entwicklungszwecke genutzt werden. Es werden die folgenden selbsterklrenden Fehlerflle deniert: PERMISSION_DENIED (1) POSITION_UNAVAILABLE (2) TIMEOUT (3) Der successCallback erhlt ein Objekt vom Typ Position. Dieses enthlt einen timestamp vom Zeitpunkt der Bestimmung und ein Objekt coords vom Typ Coordinates, welches die berechneten Koordinaten enthlt. Dabei handelt es sich um die geograsche Breite und Lnge, Genauigkeit, Geschwindigkeit, Richtung, Hhe und die Genauigkeit der Hhenangabe.10
10
Vgl. [Pop10, 5 API Description]
Seite 34 von 87
5. Geolocation API
5.4 Welche Risiken entstehen?

Bisher folgen alle Browser der in der Spezikation festgehaltenen Regelung, dass die Nutzer explizit um Erlaubnis gefragt werden mssen, wenn eine Webseite diese Funktionalitt in Anspruch nehmen will. Beim Google Browser Chrome wird hierbei nur noch zwischen Zulassen und Ablehnen unterschieden. Die anderen Browser unterscheiden bei der Abfrage jedoch zustzlich zwischen einmal und immer erlauben. Dies erhht die Sicherheit und gibt dem Nutzer die volle Kontrolle. Falls Browser-Bugs oder Schdlinge die Sperre auer Kraft setzen, knnten personenund ortsbezogene Daten gesammelt werden ohne das der Nutzer dies berhaupt mitbekommt. Hierbei knnten Bewegungsprole erstellt werden, hnlich wie es bei Apple Produkten Anfang 2011 aufgedeckt wurde.11
5.5 Prototyp
Der im Folgenden vorgestellte Prototyp dient zur Bestimmung und Anzeige der Positionsdaten. Da die Positionsberwachung der watchPosition-Funktion im Browser abluft und die Callback-Funktionen nur ausgefhrt werden, wenn sich die Position des Gertes mageblich ndert, setzt diese Entwicklung auf dem one-shot request auf, welcher sich besser veranschaulichen lsst. Die folgenden Listings sind Ausschnitte aus dem auf GitHub12 verentlichten Quellcode. Dieser wurde zustzlich mit Google Maps erweitert, um die Position und die genaue Adresse auf einer Karte visualisieren zu knnen. Bevor das Geolocation API genutzt wird, sollte wie im folgenden Listing geprft werden, ob der Browser die Schnittstelle untersttzt. Andernfalls kann eine Ausweichmglichkeit wie ein Hinweistext geschaen werden. Listing 5.1: Verfgbarkeitscheck und Positionsanfrage if ( typeof navigator . geolocation !== undefined ) { navigator . geolocation . getCurrentPosition ( successCallback , errorCallback , options ) ; } else // fallback Beim Aufruf der getCurrentPosition-Funktion werden drei Variablen bergeben, die vorher deniert wurden. Dabei handelt es sich um zwei anonyme Funktionen in Form der Variablen successCallback und errorCallback sowie das Kongurationsobjekt options. Wenn der Browser die Positionsdaten erhalten hat, lst er den bergebenen successCallback und im Fehlerfall den errorCallback aus.
11 12
Vgl. [Str11] Siehe https://github.com/FlorianX/HTML5-experiments/blob/master/geolocation_api/ index.html
Seite 35 von 87
5. Geolocation API
Listing 5.2: Der Erfolgsfall var successCallback = function ( position ) { var msg = Timestamp : + position . timestamp + <br > + latitude : + position . coords . latitude + <br > + longitude : + position . coords . longitude + <br > + altitude : + position . coords . altitude + <br > + accuracy : + position . coords . accuracy + <br > + altitude accuracy : + position . coords . altitudeAccuracy + <br > + heading : + position . coords . heading + <br > + speed : + position . coords . speed ; // ... post the message to the page }; Das Listing 5.2 zeigt den Erfolgsfall. Die Funktion erhlt das in Kapitel 5.3 beschriebene Positionsobjekt und formatiert dieses mithilfe von HTML als String, welcher ausgegeben werden kann. Mit console.log(position); knnte fr Entwicklungszwecke auch eine Ausgabe in die JavaScript-Konsole des Browsers erfolgen. Listing 5.3: Der Fehlerfall var errorCallback = function ( error ) { switch ( error . code ) { case error . TIMEOUT : alert ( Location Service doesn \ t answer , timeout ! ) ; break ; case error . POSITION_UNAVAILABLE : alert ( Position unavailable ) ; break ; case error . PERMISSION_DENIED : alert ( Permission denied ) ; break ; default : alert ( Somethings wrong , sorry . ) ; break ; } }; Im Fall eines Fehlers bei der Positionsbestimmung wird der errorCallback, welcher ein Fehlerobjekt erhlt, ausgefhrt. Das Listing 5.3 zeigt die Auswertung des Fehlers und eine darauf abgestimmte Ausgabe einer Fehlermeldung. Listing 5.4: Die Einstellungen var options = { enableHighAccuracy : true , // super accuracy timeout : 2000 , // maximum waiting time maximumAge : 0 // maximum acceptable cache age };
Seite 36 von 87
5. Geolocation API
Im Prototyp wurde mit einer Wartezeit von zwei Sekunden, einer hohen Przision und keinen gecachten Daten gearbeitet. Mit diesen wenigen Handgrien und einer etwas erweiterten Behandlung im Erfolgsfall zeigt der auf GitHub verfgbare Quellcode die aktuelle Position mit Adressdaten auf einer Karte an. Desweiteren ist ein Beispiel der Positionsberwachung hinterlegt.
Seite 37 von 87
6 Formularneuheiten
Der neue HTML-Standard fhrt verschiedene Neuerungen im Bereich der Formulare ein. Diese nderungen beinhalten neue oder lngst bekannte und jetzt standardisierte Attribute, hinzugefgte Elemente und Inputfeld-Typen sowie ein integriertes Validierungs-API. Daher widmet sich dieses Kapitel den interessantesten Vertretern und wird diese nher vorstellen.1
6.1 Formularelemente
Im Bereich der Formularelemente gibt es nur die folgenden drei Neuzugnge. Zum einen das eher unspektakulre <output>, welches das Ergebnis einer Berechnung reprsentiert. Dieses gleicht einem normalen Input bis auf den Sachverhalt, dass es nicht vom Nutzer bearbeitet werden kann.2 Der zweite Neuzugang ist das <datalist>-Element. Es untersttzt oder ersetzt die Autovervollstndigung des Browsers mit denierten Werten der Webseite. Listing 6.1: Verwendung des Elements <datalist> < input type = " text " list = " languageData " id = " language " / > < datalist id = " languageData " > < option value = " Scala " > </ option > < option value = " PHP " > </ option > < option value = " Haskell " > </ option > < option value = " C " > </ option > < option value = " C # " > </ option > < option value = " F # " > </ option > < option value = " C ++ " > </ option > </ datalist > Das Listing 6.1 zeigt die Verwendung des Elements in Verbindung mit einem normalen Texteingabefeld. Beginnt der Nutzer nun mit einer Eingabe in dieses Textfeld, wrden Eingabevorschlge entsprechend der eingegebenen Zeichen erfolgen. Wenn beim Eingabefeld das Attribut autocomplete=off gesetzt wird, ist die Autovervollstndigung des Browsers deaktiviert. Anderenfalls knnten die Vorschlge der Datalist und die des Browsers angezeigt werden.
1
Ein kleines Testbecken mit verschiedenen neuen Elementen, Attributen und Typen ist hier zu nden: https://github.com/FlorianX/HTML5-experiments/blob/master/forms/ index.html 2 Vgl. [Hic11a, 4.10.15 The output element]
Seite 38 von 87
6. Formularneuheiten
Das Verhalten dieses Elements imitieren Webseiten derzeit durch die Verwendung von Dropdownboxen und JavaScript. Somit stellt dieses neue Element eine wirkliche Bereicherung dar.3 Das letzte neue Formularelement ist <keygen>. Es dient zur Generierung von Schlsselpaaren mithilfe des RSA-Verfahrens4 . Die Spezikation lsst aber oen, ob und inwieweit ein Browser dieses oder ein anderes Verfahren untersttzt. Wie die Abbildung 6.1 zeigt, fhrt dies zu einer unterschiedlichen Implementierung in den Browsern.
(a) Chrome
(b) Firefox
(c) Opera
Abbildung 6.1: Vergleich der <keygen> Implementierungen Dieses Element knnte fr die Generierung eines Client-Zertikats genutzt werden. Dabei wird der private Schlssel im sogenannten key store des Browsers gespeichert, der entliche Schlssel wird hingegen an den Server gesendet. Nun knnte der Server ein Client-Zertikat erstellen, welches an den Browser zurckgesendet wird. Dieser kann sich somit gegenber dem Server authentizieren.5
6.2 Formularattribute
HTML5 fhrt eine Reihe neuer Attribute fr Formularelemente ein, wovon einige im Folgenden kurz vorgestellt werden. Das Attribut form fgt ein Element einem Formular hinzu, obwohl es nicht innerhalb der Formular-Tags steht. Listing 6.2: Zwei neue Attribute im Einsatz < input type = " text " id = " outer " form = " testForm " placeholder = " Type something ! " / > < form id = " testForm " > < input type = " button " onclick = " alert ( this . form . elements . outer . value ) " value = " Type and click ! " / > </ form >
3 4
Vgl. [Hic11a, 4.10.10 The datalist element] RSA ist ein asymmetrisches Verschlsselungsverfahren, welches auch fr die digitale Signatur verwendet werden kann. 5 Vgl. [Hic11a, 4.10.14 The keygen element]
Seite 39 von 87
Im Listing 6.2 wird ein Eingabeelement durch form=testForm dem darunterliegenden Formular zugewiesen. Der Klick auf den Button zeigt, dass das Element angesprochen und ausgelesen werden kann.6 Ein weiteres neues Attribut, welches im Listing verwendet wurde, ist placeholder. Der hier hinterlegte Text erscheint im Eingabefeld und verschwindet wenn der Nutzer es anklickt. Die Funktionalitt hinter diesem Attribut wurde bisher mit JavaScript realisiert.7 HTML5-Formulare bieten weiterhin die Mglichkeit, dass Formularattribute durch die neuen Attribute formaction, formenctype, formmethod, formnovalidate und formtarget berschrieben werden knnen. Diese Attribute knnen aber nur von Eingabefeldern der Typen image und submit getragen werden.8 Dies erlaubt bspw. die Verwendung von mehreren Buttons, welche ein Formular an unterschiedliche URLs senden. Die letzten Attribute, die hier aufgefhrt werden sollen, sind required und pattern. Diese sind die ersten Mglichkeiten, die mit der neuen Formularvalidierung eingefhrt wurden, um Formulare vom Browser vor dem Absenden zu prfen. Mit required kann ein Pichtfeld markiert werden, welches nicht leer sein darf.9 Mit Hilfe von JavaScript Pattern knnen eigene Validierungsregeln fr ein Element hinterlegt werden. Listing 6.3: Zwei neue Attribute im Einsatz. < form > < input type = " text " pattern = " [0 -9]{2}.[0 -9]{2}.[0 -9]{4} " placeholder = " DD . MM . YYYY " required / > < input type = " submit " value = " Check submitting " / > </ form > Listing 6.3 zeigt dies anhand der Validierung einer Datumseingabe mit dem patternAttribut. Beim Versuch das Formular abzusenden, erscheint die Fehlermeldung, dass das vorgegebene Format nicht eingehalten wurde.10 Diese neuen Attribute bieten auf eine einfache Weise die Mglichkeit, ein Formular vor dem Absenden ohne viel JavaScript zu validieren. Im Kapitel 6.4 werden weitere Mglichkeiten des neuen Validierungs-APIs vorgestellt.
6.3 Input-Typen
Eine weitere interessante Neuerung im Bereich der Formulare ist die Erweiterung der mglichen Typen des Elements <input>. Dies ist der heutigen Vielzahl an Eingabemglichkeiten geschuldet. So musste bislang der Standardtyp text fr jedwede
6 7
Vgl. Vgl. 8 Vgl. 9 Vgl. 10 Vgl.
[Hic11a, [Hic11a, [Hic11a, [Hic11a, [Hic11a,
4.10.18 Association of controls and forms] 4.10.7.2.12 The placeholder attribute] 4.10.7.1.20 Image Button state] and [Hic11a, 4.10.7.1.19 Submit Button state] 4.10.7.2.6 The required attribute] 4.10.7.2.9 The pattern attribute]
Seite 40 von 87
Eingabe genutzt werden. Dies ndert sich mit HTML5, da die folgenden 13 Typen hinzugefgt wurden: search tel url email number range color date month week time datetime datetimelocal
Diese neuen Typen ermglichen es, dass browserinterne Widgets fr die Nutzereingabe verwendet werden knnen. Bisher wurden bspw. die von Webseiten genutzten Datepicker mithilfe von JavaScript bereitgestellt. Die Eingabefelder, welche einem der sechs neuen Typen fr Zeitangaben angehren, werden bereits vom Browser Opera mit einem Datepicker ausgestattet. Wichtig hierbei ist, dass die Darstellung nicht in der Spezikation geregelt wurde. Es sind daher Unterschiede in den Browsern absehbar. So stellt der Browser Chrome bspw. keinen Datepicker, sondern kleine Buttons zum Auf- und Abwrtsschalten am Ende des Eingabefeldes dar. Felder vom Typ search werden auf Mac OS X systemweit gleich dargestellt. Das heit, eigene Styleangaben werden ignoriert. Die unterschiedlichen Typen ermglichen es auch, dass mobile Gerte, etwa mit Touchscreen, die Darstellung der Tastatur anpassen knnen. So wird beim numberTyp beim Android 2.2 Browser die Tastatur mit Zahlen eingeblendet. Die Darstellung und Untersttzung dieser neuen Input-Typen variiert zwischen den Browsern und Systemen noch sehr stark. So ist die Untersttzung in Opera und Chrome sowie beim iPhone sehr weit fortgeschritten, was aber nicht mit optimal gleichzusetzen ist. Als Letztes sei noch genannt, dass die Typen url und email sowie number und range bereits Standardvalidierungsregeln unterliegen. Inwieweit diese beeinusst oder abgendert werden knnen, wird das folgende Kapitel verdeutlichen.11
6.4 Formularvalidierung
Die Validierung von Formularen vor dem Absenden war bisher nur mit JavaScript mglich. HTML5 ndert dies nun und stellt ein Validierungs-API bereit mit dem der Browser die Prfung bernimmt. Dieses bietet die Mglichkeit der automatischen und der manuellen Validierung von Formularen. Dabei ist wichtig, dass eine serverseitige Validierung der empfangenen Daten weiterhin notwendig ist.
6.4.1 Automatische Validierung

Einige Eingabefeld-Typen haben bereits hinterlegte Validierungsregeln. Diese greifen aber nur, wenn das betreende Feld einem Formular zugeordnet ist, es einen Namen hat und nicht die Attribute disabled oder/und readonly trgt. Wenn diese Regeln
11
Vgl. [Hic11a, 4.10.7 The input element]
Seite 41 von 87
zutreen, wird das Feld automatisch validiert ohne das die Validierung manuell aktiviert werden muss. Die Eigenschaft ele.willValidate12 verrt, ob ein Element automatisch validiert wird oder nicht. Falls die automatische Validierung explizit deaktiviert werden soll, kann dies entweder global fr das Formular oder nur fr ein Element geschehen, in dem das Attribut novalidate gesetzt wird. Diese Eigenschaft kann auch durch einen Button mit dem Attribut formnovalidate verndert werden.
6.4.2 Manuelle Validierung

Das Validierungs-API bietet aber auch die Mglichkeit, dass Formulare manuell validiert werden knnen. Die bereitgestellten Funktionen knnen auf einzelne Formularelemente, <fieldset>s oder ganze Formulare angewandt werden. Eigene Validierungsregeln knnen mit JavaScript erstellt oder als JavaScript Pattern im pattern-Attribut des Elements hinterlegt werden. Damit die Meldungen an die Nutzer so einheitlich wie mglich gehalten werden knnen, besteht durch den Aufruf von ele.validationMessage der Zugri auf die aktuell gltige Validierungsnachricht des Browsers zum entsprechenden Feldtyp. Eigene Validierungsnachrichten knnen mit ele.setCustomValidity(Fehlermeldung) pro Element oder Fieldset gesetzt werden. Um ein Feld zu prfen, egal ob nach eigenen oder nach Standardregeln, bietet das Validierungs-API die folgenden Mglichkeiten an: ele.validity.valid ele.validity.checkValidity() ele.validity.valueMissing ele.validity.typeMismatch ele.validity.patternMismatch ele.validity.tooLong ele.validity.rangeUnderflow ele.validity.rangeOverflow ele.validity.stepMismatch ele.validity.customError
Diese liefern entsprechend true oder false zurck. Die gesamte Fehlerbehandlungsroutine wird nur durch ele.validity.checkValidity() ausgelst. Alle anderen Aufrufe validieren die Eingabe im Hintergrund und fhren nicht zum Feuern des Invalid-Events und einer Fehlermeldung.13
ele steht in diesem Zusammenhang fr das document.getElementById(ID) selektiert werden kann. 13 Vgl. [Hic11a, 4.10.21 Constraints]
12
Element,
welches
bspw.
mit
Seite 42 von 87
7 Multimedia-Elemente
Die Nutzung von multimedialen Inhalten wie Video und Audio war bisher nur auf Umwegen im Web mglich. Dabei kam oft das Flash-Plugin zum Einsatz, welches aber nur eine proprietre Lsung darstellt. HTML5 ermglicht nun die native Einbindung dieser Inhalte in eine Webseite und verdrngt Flash im Bereich der multimedialen Inhalte auf den Platz der Notfall- oder Fallback-Lsung. Die groen Videoplattformen wie YouTube1 oder Vimeo2 setzen bereits diese neue Mglichkeit der Integration ein. Welche HTML-Elemente eine Rolle spielen und wie sie mit JavaScript beeinusst werden knnen, wird in diesem Kapitel nher betrachtet. Multimediale Inhalte knnen aber auch komplexerer Natur als nur Audio und Video sein. Hierbei knnte es sich bspw. um JavaApplets, Flash Applikationen oder andere Plugin-Inhalte handeln. Fr solche Flle hlt HTML5 zwei weitere Elemente bereit, welche im letzten Abschnitt des Kapitels beschrieben werden.
7.1 Die HTML-Elemente und ihre Attribute

Die neuen Elemente fr Audio- und Video-Inhalte sind <video> und <audio>. Beide Elemente hneln sich in ihren Attributen und ihrer Verwendung sehr stark. So knnen bei beiden Elementen die Mediadateien entweder per src-Attribut oder <source>-Element angegeben werden. Durch die Verwendung des <source>-Elements knnen, wie im folgenden Listing dargestellt, mehrere Quelldateien angegeben werden, da nicht jeder Browser alle mglichen Formate untersttzt. Listing 7.1: Verwendung des <source>-Elements < video controls > < source src = " movie . ogg " type = " video / ogg ; codecs = theora , vorbis " / > < source src = " movie . mp4 " type = " video / mp4 " / > < source src = " movie . webm " type = " video / webm " / > </ video > Der Browser whlt dann die erste abspielbare Mglichkeit aus. Hierzu gibt es ein festgeschriebenes Vorgehen, in dem der Browser beginnt die Datei herunterzuladen und whrenddessen entscheidet, ob sie abspielfhig ist. Um das ganze Vorgehen etwas zu erleichtern und zu beschleunigen, knnen die Attribute media und type verwendet werden.
1 2
Siehe [CZ10] Siehe [Dou10]
Seite 43 von 87
7. Multimedia-Elemente
Das media-Attribut kann Media Queries3 , wie aus dem CSS bekannt, beinhalten. Durch die Verwendung von bspw. media=handheld, media=screen oder media=all kann eine Medienquelle bestimmten Gerten zugewiesen werden. Dies ist vor allem im mobilen Bereich von Nutzen, da so ein Video mit geringerer Ausung fr ein Handy bereitgestellt werden knnte. Es ist bisher nicht gelungen, ein einheitliches Videoformat festzulegen und nicht jeder Browser kann alle Videoformate und Codecs abspielen, daher untersttzt das type-Attribut die Quellenauswahl des Browsers. Dabei darf das Attribut nur valide MIME-Typen nach RFC42814 enthalten. Wie das Listing 7.1 zeigt, kann es sich dabei nur um die Angabe des Containerformats wie video/webm und auch um zustzliche Informationen zum Codec handeln.5 Die folgende Tabelle fhrt die mglichen Audio- und Videoformate mit ihrer Browseruntersttzung auf. Codec/Format Theora/Vorbis H.264/AAC WebM MP3 WAV IE Firefox 3.5+ 9.0+ 4.0+ 9.0+ 3.5+ Opera 10.5+ 10.6+ 10.5+ Chrome 3.0+ 3.0+ 6.0+ 3.0+ 3.0+ Safari 3.1+ 3.0+ 3.0+
Tabelle 7.1: Browseruntersttzung der Formate (in Anlehnung an:[Kr11b, S. 273] und [Ref11])
Die in der Tabelle 7.1 mit einer Tilde gekennzeichneten Browser bilden eine Ausnahme. Sie knnen das entsprechende Format nicht nativ abspielen, sondern nur sobald der Codec auf dem Computer verfgbar ist. Die Video- und Audio-HTML-Elemente sind sehr stark miteinander verzahnt. Dies wird nicht nur im gleichen Aufbau, den gleichen Attributen und der hnlichen Verwendung deutlich, sondern auch dadurch, dass ein <audio>-Element Videoquellen wiedergeben kann. Der einzige Unterschied in diesem Fall besteht darin, dass das <audio>-Element keinen Bereich fr die Anzeige des Videobildes besitzt. Eine Besonderheit des Audio-Elements ist der eigene Konstruktor. Durch den Aufruf von new Audio(music.ogg).play() kann eine Musikdatei geladen und gleich abgespielt werden. Dies ermglicht den eventgetriebenen Einsatz von Audioinhalten bspw. in Spielen oder als Feedback in Anwendungen, ohne das diese im Quellcode stehen mssen.6 Listing 7.2: Untertitel fr ein Video < video src = " movie . ogg " > < track kind = " subtitles " src = " subtitles . de . vtt " / >
3 4
Siehe http://www.w3.org/TR/css3-mediaqueries/ Siehe http://tools.ietf.org/html/rfc4281 5 Vgl. [Hic11a, 4.8.8 The source element] 6 Vgl. [Hic11a, 4.8.7 The audio element]
Seite 44 von 87
< track kind = " captions " src = " captions . de . vtt " / > < track kind = " metadata " src = " metaInfo . de . vtt " / > </ video > Das HTML-Element <track> ist speziell fr den Einsatz mit dem Video-Element gedacht. Es dient zur zeitgesteuerten Anzeige von Inhalten wie bspw. Untertiteln, Beschreibungen, Metadaten oder Beschriftungen. Das hierfr verwendete Format heit Web Video Text Tracks und wird in der HTML-Fassung der WHATWG speziziert. Es unterliegt derzeit noch groen nderungen und ist bisher in noch keinem Browser vollstndig implementiert.7 Ein weiterer Unterschied der beiden Elemente liegt im controls-Attribut. Dieses dient zur Einblendung des browsereigenen Players. Falls das Attribut bei einem Video fehlt, wird der Player zwar nicht angezeigt, aber trotzdem das Video. Im Gegensatz dazu ist das Audio-Element bei einem Fehlen dieses Attributs nicht auf der Webseite zu sehen. Die Steuerung der Medien kann dann ber einen eigenen Player, ein separates Browserinterface oder durch JavaScript erfolgen. Hierzu wird das Media-API bentigt, welches in den folgenden Abschnitten beleuchtet wird.
7.2 Media-API
Das vorhergehende Kapitel hat bereits gezeigt, dass die Elemente <video> und <audio> mehr Gemeinsamkeiten als Unterschiede haben. So ist es auch bei ihrem JavaScript-API. Der einzige Unterschied liegt darin, dass ein Video-Element die Eigenschaften video Width und videoHeight besitzt, welche fr die Ausung des Videos stehen und nicht fr die Gre der Darstellung.8 Das Media-API wird dann interessant, wenn bspw. ein eigener und nicht der browserinterne Player fr die Wiedergabe verwendet werden soll. Dieser kann dann ohne Probleme in das Seitendesign eingearbeitet werden. Alle nachfolgenden Angaben werden am Beispiel des Audio-Elements behandelt, gelten aber genauso fr VideoElemente. Die zwei Methoden, um ein Audio-Element abzuspielen, sind audio.play() und audio.pause(). Um herauszunden, ob ein Media-Element bereits abgespielt wird, ist die boolsche Eigenschaft audio.paused vorhanden. Mit audio.defaultPlaybackRate [= value] kann eine Abspielgeschwindigkeit als Standard festgelegt werden. Die Eigenschaft audio.playbackRate [= value] bezieht sich hingegen auf die aktuelle Abspielgeschwindigkeit des Mediums in Bezug auf eine Nutzereingabe. Beide Eigenschaften sind immer als Vielfaches der dateieigenen Basisgeschwindigkeit zu verstehen. Die Lautstrke eines Mediums kann mit audio.volume [= value] beeinusst werden. Die dafr vergebenen Werte mssen sich im Bereich von 0.0 bis 1.0 benden. Mit audio.muted [= true/false] kann das Medium lautlos gestellt werden.
7 8
Vgl. [Hic11a, 4.8.9 The track element] und [Hic11a, 4.8.10.13 WebVTT] Vgl. [Hic11a, 4.8.6 The video element]
Seite 45 von 87
Die Lnge eines Audioles ist in der Eigenschaft audio.duration zu nden. Die aktuelle Abspielposition in Sekunden kann mit audio.currentTime [= value] sowohl ausgelesen als auch neu gesetzt werden. Es sind noch weitere Methoden und Eigenschaften wie audio.load([value]), audio.autoplay oder audio.loop der Media-Elemente vorhanden. Diese werden aber nicht nher beleuchtet, da es sich meist um boolsche Eigenschaften oder Zeitangaben handelt, welche selbsterklrend sind. Viel wichtiger sind die folgenden Statuswerte eines Media-Elements, welche in drei Eigenschaften gesplittet sind. Fehlermeldungen benden sich in audio.error, die Netzwerkaktivitten werden durch audio.networkState und der Ladezustand des Medien-Elements durch audio.readyState reprsentiert. Dabei knnen die folgenden Werte angenommen werden: audio.error keine Fehler (null) MEDIA_ERR_ABORTED (1) MEDIA_ERR_NETWORK (2) MEDIA_ERR_DECODE (3) MEDIA_ERR_SRC_NOT_SUPPORTED (4) audio.networkState NETWORK_EMPTY (0) NETWORK_IDLE (1) NETWORK_LOADING (2) NETWORK_NO_SOURCE (3) audio.readyState HAVE_NOTHING (0) HAVE_METADATA (1) HAVE_CURRENT_DATA (2) HAVE_FUTURE_DATA (3) HAVE_ENOUGH_DATA (4) Neben diesen Statusmeldungen feuert ein Media-Element verschiedene Events wie loadstart, loadedmetadata, play und weitere. Diese sind bei der Programmierung eines eigenen Players sehr hilfreich.9
7.3 Prototyp eines Videoplayers

Die Spezizierung der HTML-Elemente fr multimediale Inhalte ermglicht nicht nur die grasche Anpassung mit CSS, sondern auch die komplette Integration in Webseiten und Applikationen mithilfe des Media-API. Als Videoplayer kann der
Vgl. [Hic11a, 4.8.10 Media elements]
Seite 46 von 87
browserinterne, eine HTML5-Videoplayer Bibliothek10 oder eine Eigenentwicklung dienen. Daher soll ein einfacher, mit CSS angepasster Videoplayer erstellt werden, welcher der Abbildung 7.1 entspricht.11
Abbildung 7.1: Screenshot des Player-Prototypen Wie der Screenshot zeigt, besitzt der Prototyp einen Play- und einen Mute-Button sowie eine Zeitanzeige. Fr eine derartige Darstellung knnte das HTML-Grundgerst wie folgt aussehen: Listing 7.3: HTML-Grundgerst des Prototypen < video width = " 400 " height = " 225 " id = " video " poster = " ../../ res / images / bigbugbunny . jpg " > < source src = " ../../ res / video . ogv " / > </ video > < div id = " controlContainer " > < button id = " playButton " type = " button " title = " Abspielen " > play ! </ button > < div id = " time " > < span id = " shown " > 00:00 </ span >/ < span id = " duration " > </ span > </ div > < button id = " muteButton " type = " button " title = " Mute " > mute ! </ button > </ div > Der obere Teil des Listings 7.3 erstellt ein Video-Element mit einer festen Breite und Hhe sowie einem statischen Bild (poster). Zur Auszeichnung der Quelldatei wurde das <source>-Element ohne Angabe der Attribute type oder media genutzt, da sich der Prototyp hauptschlich mit der Steuerung der Media-Elemente und nicht mit der browserbergreifenden Bereitstellung von Videos beschftigen soll.
Ein aktueller Vergleich verschiedenster HTML5-Player ist auf http://praegnanz.de/ html5video/ zu nden. 11 Siehe https://github.com/FlorianX/HTML5-experiments/blob/master/media_api/index. html Der hier gezeigte Quellcode bedient mit einem Player jeweils ein Audio- und VideoElement.
10
Seite 47 von 87
Als nchstes wurde ein <div>-Container hinzugefgt, welcher den Player darstellen soll und die Bedienelemente enthlt. Die Elemente wurden mit einfachen CSSAngaben wie Hintergrundfarbe, Schriftfarbe und Abstnden versehen. Mit diesen wenigen Handgrien ist ein Player bereits optisch fertiggestellt. Das Wichtigste, die Funktionalitt, fehlt jedoch und muss mit JavaScript hinterlegt werden. Zum besseren Handling der JavaScript Befehle wurde die Bibliothek jQuery zuhilfe genommen. Die folgenden Anweisungen drfen erst ausgefhrt werden, wenn die Seite vollstndig geladen ist. Daher wurden sie innerhalb der jQuery-Methode $(document).ready(function(){ ...}) notiert. Listing 7.4: Videolaufzeit ermitteln var element = $ ( # video ) . get (0) ; $ ( element ) . bind ( loadedmetadata , function () { $ ( # duration ) . html ( element . duration ) ; }) ; Das Listing 7.4 zeigt die im vorhergehenden Kapitel angesprochene Nutzung der Media-Events. Mit Hilfe der jQuery-Methode bind() kann eine Funktion an ein Event gebunden werden. Sobald also die Metadaten des Videos geladen sind, feuert dieses Event, die Gesamtlnge des Videos wird ausgelesen und an die entsprechende Stelle im HTML geschrieben. Listing 7.5: Die Funktionalitt des Play-Buttons $ ( # playButton ) . click ( function () { var interval ; if ( element . paused ) { element . play () ; $ ( this ) . html ( stop ! ) ; interval = setInterval ( function () { $ ( # shown ) . html ( element . currentTime ) ; } , 1000) ; } else { clearInterval ( interval ) ; element . pause () ; $ ( this ) . html ( play ! ) ; } }) ; Der Play-Button erhlt durch das Listing 7.5 seine Funktionalitt. Durch den jQueryAufruf wird ein click-Event an den Button gebunden. Feuert das Event, lst es die anonyme Funktion aus, welche prft, ob das Video pausiert ist. Liefert diese Bedingung true zurck wird element.play(), ansonsten element.pause() ausgefhrt. Auerdem wird die Beschriftung des Buttons gendert und ein Intervall erzeugt, mit dem die aktuelle Abspielzeit des Videos im HTML erneuert wird.
Seite 48 von 87
Listing 7.6: Stummschaltung des Videos $ ( # muteButton ) . click ( function () { if ( element . muted ) { $ ( this ) . html ( mute ! ) ; element . muted = false ; } else { $ ( this ) . html ( unmute ! ) ; element . muted = true ; } }) ; Die beschriebene Funktionalitt des Play-Buttons wurde in Listing 7.6 auf den Button fr die Stummschaltung angewandt. Dieser Prototyp zeigt, dass das Media-API die Erstellung eines Players auf einfache Weise ermglicht, egal ob fr Video- oder Audio-Inhalte. Somit knnen durch HTML5 nicht nur die Media-Elemente eingebunden, sondern sie knnen viel mehr vollstndig in eine Umgebung integriert werden. Welche zwei weiteren Mglichkeiten es zur Einbindung von multimedialen Inhalten noch gibt, zeigt das folgende Kapitel.
7.4 Weitere Mglichkeiten der Inhaltseinbindung

Mit HTML5 wird erstmals das weitverbreitete und in jedem Browser funktionierende <embed>-Element in den HTML-Standard aufgenommen. Es dient hauptschlich zur Einbindung von Flash, kann aber auch mit anderen Arten von Plugin-Inhalten umgehen. Neben den Attributen height, width und src kann mit type der MIMETyp des Inhalts angegeben werden. Eine Besonderheit ist, dass es Attribute tragen kann, die an das Plugin bergeben werden sollen und nicht dem HTML-Standard entstammen.12 Die Alternative zu diesem Element ist das <object>. Werte oder Parameter, die an den eingebundenen Inhalt bergeben werden sollen, stehen hierbei in einem eigenen <param>-Element innerhalb des Objektes. Das <object> kann im Gegensatz zum <embed> Ersatzinhalte tragen. Auerdem kann es neben der Nutzung fr PluginInhalte auch fr JavaApplets, Bilder und ganze HTML-Dokumente genutzt werden. Das <object>-Element kann auch als Formularelement genutzt und validiert werden. Dieses Element scheint die Allzweckwae von HTML5 zu sein, denn es kann nicht nur Flash einbinden, sondern macht HTML-Elemente wie <img> und <iframe> eigentlich berssig.13 Hierbei muss aber bedacht werden, dass jedes HTML-Element neben einem Zweck auch eine semantische Bedeutung hat und dementsprechend verwendet werden sollte. Beide hier vorgestellten Elemente dienen zur Einbindung externer Inhalte. Als bessere Wahl zeichnet sich in diesem Fall das <object>-Element aus, da es die Bereitstellung von Ersatzinhalten ermglicht.
12 13
Vgl. [Hic11a, 4.8.3 The embed element] Vgl. [Hic11a, 4.8.4 The object element]
Seite 49 von 87
8 Canvas
Die im letzten Kapitel vorgestellten neuen Multimedia-Elemente sind die ersten Gegner von Flash die HTML5 bereithlt. In diesem Kapitel steht das Canvas als neues Allroundtalent und damit als Flash-Konkurrent im Mittelpunkt. Neben den Grundlagen und der API-Einfhrung wird ein Prototyp zur Videobearbeitung im Browser vorgestellt. Der letzte Abschnitt zeigt weitere Nutzungsmglichkeiten des Canvas durch verschiedene Frameworks auf.
8.1 Grundlagen
Das Canvas wurde ursprnglich von Apple entwickelt und befand sich bereits 2005 in Anstzen in einer Spezikationsversion der WHATWG.1 Dies unterstreicht die Konkurrentenposition gegenber Flash, da Apple bisher auf keiner Version des iPhones und Co Flash zulsst und gleichzeitig Ernder der Alternative ist.2 Das HTML-Element <canvas> stellt seine komplette Gre, die mit height und width angegeben wurde, als Malche zur Verfgung. Weiterhin besteht die Mglichkeit, dass das Element Ersatzinhalte tragen und den zum Zeichnen bentigten Rendering Context bereitstellen kann. Die Malche wird als Bitmap bezeichnet, ber welcher ein contextabhngiges Koordinatensystem liegt. Die folgenden zwei Contexte benden sich derzeit in der Spezikationsphase: 2d Wie der Name schon sagt, stellt dieser Context Mittel fr die zwei dimensionale Bearbeitung und Darstellung von Graken fr das Canvas zur Verfgung. Er ist Bestandteil der HTML-Spezikation der WHATWG und wird beim W3C als separate Spezikation gefhrt. Die Untersttzung in den groen Browsern ist sehr weit fortgeschritten. WebGL Bei WebGL handelt es sich um einen 3D-Context. Dieser wird von der Khronos Group speziziert und basiert auf OpenGL ES 2.0. Alle groen Browser, bis auf den Internet Explorer, untersttzen bereits Teile dieses Contextes.3 Zu beachten ist, dass sich die Operationen, die die Contexte bereitstellen, auf das Gitternetz auswirken. Das heit, wenn eine Skalierung ausgefhrt wird, verndert sich das Gitternetz nicht, aber die Bitmap.4
1 2
Siehe http://www.whatwg.org/specs/web-apps/2005-09-01/#dynamic Im September 2011 wurde der neue Adobe Flash Media Server 4.5 vorgestellt, welcher dieses Problem durch die gezielte Auslieferung eines iOS-freundlichen Formats lsen soll. Vgl. [OP11] 3 Siehe http://www.khronos.org/registry/webgl/specs/latest/ 4 Vgl. [Hic11a, 4.8.11 The canvas element]
Seite 50 von 87
8. Canvas
Das Canvas wird oft auch mit einer Scalable Vector Graphic verglichen oder gar als solche aufgefasst. Dies ist aber nicht korrekt, da ein Browser die Mglichkeit besitzt eine SVG komplett neu zu rendern, wenn sich ein Attribut des SVG-Objekts ndert. Das DOM stellt im Falle von SVG eine Art Szenegraph dar. Ein Canvas vergisst hingegen alle Operationen die durchgefhrt wurden, weshalb alles was gezeichnet wurde nicht mehr nderbar oder rekonstruierbar ist. Falls also ein bereits gezeichnetes Objekt verschoben werden soll, muss die gesamte Szene neu erstellt werden. Diese Funktionalitt kann nur durch JavaScript bereitgestellt werden, da ein Canvas keinen Szenegraphen besitzt.
8.2 Canvas API und der 2D-Context

Das Canvas-Element besitzt neben den beiden Variablen width und height, die die Bitmap lschen, sobald einer der Werte neu gesetzt wird5 , nur drei Methoden. Dabei erstellt canvas.toDataURL(type [, ...]) aus der Bitmap eine DataURL6 , welche als Quelle fr das <img>-Element oder fr CSS Angaben dienen kann. Mit canvas.toBlob(callback [, type, ...]) wird ein JavaScript Objekt erzeugt, dass das Bild der Bitmap enthlt. Auerdem wird das Objekt an eine CallbackFunktion weitergereicht. Die letzte und wichtigste Methode des Canvas ist canvas.getContext(contextId [, ...]). Durch die Angabe von 2d oder webgl liefert diese Funktion den bentigten Zeichen-Context zurck. Das API des Canvas ist sehr kurz gehalten, um so grer ist aber das des 2DContextes. Dieser stellt eine Reihe von Funktionen zum Zeichnen von 2D-Graken zur Verfgung. Das API wurde sehr minimalistisch entworfen und ist daher sehr umstndlich. Es stellt nur die ntigsten Funktionen bereit, um alle geometrischen Figuren abbilden zu knnen. Um komfortabel mit dem API arbeiten zu knnen, sind Frameworks fast Picht. Im Folgenden wird nur eine Auswahl der Funktionen genannt und teilweise vorgestellt, da eine Betrachtung aller Methoden zu umfangreich und zu context-spezisch wre. Auerdem beziehen sich alle nachfolgenden Aufrufe auf den Context und mssen als context.METHODE ausgefhrt werden. Der einfachste Weg den Context zu nutzen ist mit drawImage(image, x, y [, ...]) ein Bild zu zeichnen. Falls bereits ein ImageData-Objekt vorhanden ist , kann auch putImageData(imageData, x, y [, ...]) genutzt werden. Die Angaben x und y stehen immer fr die Position im Gitternetz in Bezug zur linken oberen Ecke. Mit fillRect(x, y, w, h) und strokeRect(x, y, w, h) knnen gefllte Rechtecke oder nur deren Rahmen gezeichnet werden. Mit Hilfe von clearRect(x, y, w, h) kann ein bestimmter Bereich gelscht werden. Dabei stehen die Angaben w und h fr die Breite und Hhe des Rechtecks. Der 2D-Context bietet auch die Mglichkeit Pfade zu erstellen. Diese sollten mit beginPath() beginnen und mit closePath() enden. Zum Zeichnen und Bewegen
5 6
egal ob gleiche oder neue Werte Hierbei wird das Bild Base64 kodiert und als URL reprsentiert. Eine derartige URL sieht wie folgt aus: data:image/png;base64,RgABAQAAUhEUgAAAw0KGgoAAAANSIC. . .
Seite 51 von 87
8. Canvas
knnen dann lineTo(x, y) und moveTo(x, y) verwendet werden. Weiterhin sind Funktionen fr quadratische und Bzier-Kurven sowie fr Kreisbgen etc. vorhanden. Neben diesen einfachen Methoden bietet der Context auch Transformationen an. So ist eine Skalierung mit scale(x, y), eine Rotation mit rotate(angle) und eine Verschiebung mit translate(x, y) mglich. Auerdem knnen die Transformationsmatrizen auch direkt angegeben werden. Dies geschieht mit setTransform(a, b, c, d, e, f) und nicht mit transform(a, b, c, d, e, f), denn Letzteres multipliziert die vorhandene Matrix mit den bergebenen Werten. Durch die Methoden save() und restore() kann der Context-Zustand wie bei OpenGl im Stack ablegt und wieder abgerufen werden. Dies erleichtert komplexe Operationen ungemein. Abschlieend sei noch ohne Methoden-Nennung erwhnt, dass der 2D-Context verschiedene weitere Funktionen fr Texte, Schatten, Muster, Farbverlufe und das Compositing etc. bereithlt.7
8.3 Prototyp zur Videobearbeitung im Browser

Dieser Abschnitt beschftigt sich mit einem Prototypen zur Videobearbeitung im Browser.8 Es soll die Leistungsfhigkeit und die Mglichkeiten der HTML-Elemente in Verbindung mit JavaScript dargestellt werden. Auch dieser Prototyp nutzt jQuery als Hilfsmittel fr das Traversieren und die Eventbindung. Die folgende Abbildung zeigt den fertigen Prototypen in Aktion.
Abbildung 8.1: Screenshot des Prototypen Bevor eine derartige Darstellung mglich ist, muss das HTML-Grundgerst wie folgt erstellt werden: Hierzu wird ein Video-Element, welches als Datenquelle dienen wird, und ein Canvas zur Prsentation der Eekte bentigt. Beide Elemente werden mit den gleichen Dimensionen erstellt.
7 8
Vgl. [Hic11a, 4.8.11.1 The 2D context] Siehe https://github.com/FlorianX/HTML5-experiments/blob/master/canvas/video/ index.html
Seite 52 von 87
8. Canvas
Listing 8.1: HTML-Grundgerst < video width = " 400 " height = " 225 " controls id = " origVideo " > < source src = " ../../ res / video . ogv " > </ video > < canvas width = " 400 " height = " 225 " id = " canvasVideo " > Your browser does not support this graphic . </ canvas > Die angesprochenen Eekte werden vor dem Gebrauch als Funktionen im Objekt9 effects gespeichert. Das Listing 8.2 zeigt einen Teil des Objektes mit den Funktionen fr das Invertieren und die Grauskalierung des Videos. Eine weitere Funktion fr die Kantendetektion mit verschiedenen Operatoren ist im vollstndigen Prototyp zu nden und wurde aufgrund des Umfangs hier ausgelassen. Listing 8.2: Denition der Eekte als Objekt var effects = { none : function ( data ) { return data ; }, invert : function ( data ) { var length = data . length ; var counter = 0; while ( counter < length ) { for ( var i =0; i < 4; i ++) { data [ counter ] = ( i == 3) ? data [ counter ] : 255 - data [ counter ]; counter ++; } } return data ; }, grey : function ( data ) { var length = data . length ; for ( var i = 0; i < length ; i += 4) { var r = data [ i + 0]; // R var g = data [ i + 1]; // G var b = data [ i + 2]; // B var a = data [ i + 3]; // A var grey = ( r + g + b ) / 3; data [ i + 0] = grey ; // R data [ i + 1] = grey ; // G
9
JavaScript Objekte entsprechen in anderen Programmiersprachen bspw. einem assoziativen Array.
Seite 53 von 87
8. Canvas data [ i + 2] = grey ; // B data [ i + 3] = 255; // A } return data ; }, [...] }
Der hier verwendete data Parameter ist das CanvasPixelArray des ImageDataObjektes, welches spter ausgelesen und an die hier vorgestellten Eekte bergeben wird. Dieses Array ist eindimensional und enthlt die jeweiligen Werte fr den Rot-, Grn-, Blau- und Alphakanal eines jeden Pixels fortlaufend. Zur Invertierung des Video-Frames wurde der aktuelle Wert eines jeden Kanals von 255 subtrahiert. Eine Ausnahme bildet der Alphakanal, welcher nicht verndert wurde. Die Erstellung des Grauwertbildes erfolgt durch die Addition der drei Farbkanle und Division durch drei. Die jeweiligen Werte wurden dann im Array gendert. Der Alphakanal wird in diesem Fall auf das Maximum von 255 gesetzt. Mit dem folgenden Listing wird ein verstecktes Canvas erzeugt, welches spter als Video-Zwischenspeicher und Pixelquelle dienen wird. Auerdem wurden die HTMLElemente in JavaScript Variablen abgelegt, um besser auf sie zugreifen zu knnen. Das versteckte Canvas wird mit den selben Dimensionen erzeugt, wie das sichtbare. Listing 8.3: Erzeugen eines nicht sichtbaren Canvas var origVideo = document . getElementById ( origVideo ) ; var canvasVideo = document . getElementById ( canvasVideo ) ; var contextCanvasVideo = canvasVideo . getContext ( 2 d ) ; var hiddenCanvas = document . createElement ( canvas ) ; var contextHiddenCanvas = hiddenCanvas . getContext ( 2 d ) ; hiddenCanvas . width = canvasVideo . width ; hiddenCanvas . height = canvasVideo . height ; Nachdem nun die Eekte und Variablen deniert wurden, muss ein Start fr die Videobearbeitung festgelegt werden. Dies geschieht im folgenden Listing: Listing 8.4: HTML-Elemente mit Events versehen var effect = none ; $ ( # effect ) . bind ( change , function () { effect = $ ( # effect ) . val () ; [...] }) ; var interval ; $ ( # origVideo ) . bind ( play , function () { interval = setInterval ( function () { drawToCanvas () ; } , 25) ; }) ;
Seite 54 von 87
8. Canvas
Fr die Wahl des Eektes ist im HTML ein <select>-Feld vorhanden. Dieses wird im Listing 8.4 mit einem change-Event ausgerstet, welches bei einer Vernderung den neuen Wert fr den Eekt im JavaScript setzt. Der letzte Teil des Listings 8.4 stattet das Video mit einem play Event aus. Sobald also das Video abgespielt wird, startet ein Intervall, der alle 25 Millisekunden die Funktion drawToCanvas() aufruft. Diese Funktion ist das zentrale Element des Prototypen und wird vom folgenden Listing gezeigt: Listing 8.5: Die Zeichenfunktion des Prototypen function drawToCanvas () { if ( origVideo . paused || origVideo . ended ) { clearInterval ( interval ) ; } contextHiddenCanvas . drawImage ( origVideo , 0 ,0 , 400 , 225) ; var imageData = contextHiddenCanvas . getImageData (0 , 0 , 400 , 225) ; imageData . data = effects [ effect ]. apply ( null , [ imageData . data , imageData . width , imageData . height , matrix ]) ; contextCanvasVideo . putImageData ( imageData , 0 , 0) ; } Bei jedem Aufruf dieser Funktion wird zuerst geprft, ob das Video angehalten wurde. Ist dies der Fall, wird der erstellte Intervall gelscht. Durch die folgende Zeile wird das Video als Bildquelle genutzt und auf das versteckte Canvas gezeichnet. Im Nachfolgenden wird mit getImageData() ein ImageData-Objekt ausgelesen. Dieser Umweg ist ntig, weil die Pixelwerte nicht aus einem Video gelesen werden knnen, sondern nur das Canvas eine derartige Funktion bereitstellt. Die so erhaltenen Pixelwerte werden nun durch apply(...) an die ausgewhlte Eektfunktion weitergereicht. Diese berechnet die neuen Farbdaten und gibt sie zurck. Mit der letzten Zeile des Listings werden die Daten dann auf das sichtbare Canvas geschrieben. Mit diesen Schritten ist eine Videobearbeitung auf Grundlage des Canvas mglich.
Abbildung 8.2: Screenshot eines zweiten Prototypen
Seite 55 von 87
8. Canvas
Dies lsst sich auch auf eine Bildbearbeitung herunterbrechen, wie ein weiterer Prototyp, welcher auf der Abbildung 8.2 zu sehen ist, zeigt.10 Die Mglichkeiten des Canvas als multimediales Werkzeug sind interessant und vielfltig. Was bereits jetzt alles mglich ist, soll das folgende Kapitel zeigen.
8.4 Canvas Frameworks und deren Mglichkeiten

Das Canvas und die Contexte sind in den neuen Browsern nativ verankert, was ein groer Vorteil gegenber der Plugin-Nutzung von Flash ist. Da es bisher keine wirkliche Alternative zu Flash gab, war es in den nachfolgenden Anwendungsmglichkeiten meist zwingend notwendig auf dieses Medium auszuweichen. Dies ist dank des Canvas nun nicht mehr notwendig. Das Canvas bietet durch die Low-Level-Konzipierung vielfltige Mglichkeiten der Nutzung und das alles nativ vom Browser untersttzt. Die Masse der JavaScript Frameworks fr das Canvas wchst stetig an und abstrahiert dabei das API auf ein benutzerfreundlicheres Niveau. Daher sollen hier einige Frameworks kurz genannt werden, um zu zeigen was bereits alles mglich ist. Schon eine kleine Bibliothek wie CanvasQuery 11 ermglicht eine bessere Bedienbarkeit des API in dem sie jQuery-hnliche Befehlsketten integriert und so nur leicht abstrahiert. Die Frameworks EaselJS 12 , jCanvaScript 13 , LibCanvas 14 , bHive 15 und jcotton 16 besitzen weiterhin Mglichkeiten zur Erstellung von Animationen. Flash wird oft auch fr Keyframe-Animationen genutzt. Das Framework Kapi17 stellt derartige Funktionalitten fr das Canvas zu Verfgung. Ein Szenegraph wird im Projekt CAKE - Canvas Animation Kit Experiment 18 entwickelt.
Abbildung 8.3: Screenshot von RGraph Diagrammen (Quelle: www.rgraph.net)
Dieser ist unter der folgenden URL zunden: https://github.com/FlorianX/ HTML5-experiments/blob/master/canvas/image_processing/index.html 11 https://gist.github.com/505139 12 http://easeljs.com/ 13 http://jcscript.com/ 14 https://github.com/theshock/libcanvas 15 http://www.bhivecanvas.com/ 16 http://jcotton.sourceforge.net/index.htm 17 https://github.com/jeremyckahn/kapi 18 http://code.google.com/p/cakejs/
10
Seite 56 von 87
8. Canvas
Interaktive Diagramme wie es die Abbildung 8.3 zeigt knnen auf einfache Weise mit RGraph 19 erstellt werden. Neben verschiedenen Canvas-Spielen wie Space Pirate Killer 20 und dem Nintendo Spiele Emulator JSNES 21 sind bereits die ersten Spiele-Entwicklungsframeworks wie IMPACT 22 , propulsion 23 und xc.js 24 vorhanden.25 Die genannten Frameworks sollen die Bandbreite zeigen auf welcher derzeit mit dem Canvas als Grundlage entwickelt wird. Viele dieser Entwicklungen berschneiden sich mit den Anwendungsgebieten von Flash. Beim Canvas und den JavaScript Bibliotheken besteht aber der Vorteil, dass sie in jedem neueren Browser laufen und damit plattformunabhngig sind. Der derzeitige Trend im Bereich des Computing strebt hin zur Cloud und den Web-Anwendungen. Dies wird durch die Mglichkeiten, die das Canvas in die HTML-Welt bringt, noch verstrkt. Abschlieend sollen noch zwei bemerkenswerte Anschauungsbeispiele anhand der Abbildung 8.4 genannt werden, welche multimedial unterlegt zeigen, was derzeit mglich ist. Ein Klick auf die Webseiten ist empfehlenswert, da die Screenshots den entsprechenden Eindruck der Animationen und des Sounds nicht wiedergeben knnen.
(a) Interaktives Musikerlebnis (Quelle: http:// (b) Visualisierung des Google Suchaufkomlights.elliegoulding.com/) mens mit WebGL (Quelle: http://data-arts. appspot.com/globe-search)
Abbildung 8.4: Screenshots zweier Canvas Animationen
19 20
http://www.rgraph.net/ http://stelter-media.de/space-pirat-killer/ 21 http://fir.sh/projects/jsnes/ 22 http://impactjs.com/ 23 http://www.propulsionjs.com/ 24 http://www.getxc.org/ 25 Eine umfangreichere bersicht ber die derzeit vorhandenen Frameworks ist auf GitHub zu nden: https://github.com/bebraw/jswiki/wiki/Game-Engines
Seite 57 von 87
9 Weitere HTML5 APIs und Features

In den letzten Kapiteln wurden einige der vielen neuen Mglichkeiten die HTML5 bietet genauer vorgestellt. Aufgrund der Vielzahl von Neuheiten wird dieses Kapitel weitere zusammengefasst vorstellen. Dies umfasst unter anderem Spezikationen fr Oine-Applikationen, Drag&Drop-Funktionalitten sowie neue Kommunikationsmglichkeiten.
9.1 Oine Tauglichkeit

Als erstes sollen die neuen Oine-Fhigkeiten von Webapplikationen nher betrachtet werden. Diese knnen im mobilen Leben ein entscheidendes Kriterium darstellen. Einfache Webseiten knnen durch die gezielte Anwendung folgender Techniken kurze Verbindungsabbrche oder ganze Zeitrume berbrcken. Die Oine Tauglichkeit geht einher mit der Datenspeicherung, welche in zwei Arten unterschieden werden kann. Zum einen in nutzer- und zum anderen in applikationsspezische Daten. Der Application Cache zhlt zu ersterer, alle weiteren Mglichkeiten zhlen zur letzteren Art. Fr die berprfung ob ein Browser on- oder oine ist, werden in der HTMLSpezikation sogenannte Online- und Oine-Events sowie ein Netzwerk-Status speziziert. Dieses Wissen ist bspw. wichtig, wenn der Browser die Daten im Oine-Fall nur zwischenspeichern und sobald er wieder online ist mit dem Server synchronisieren soll. Der Netzwerk-Status kann mit navigator.onLine abgefragt werden. Dabei liefert dieser false, wenn er denitiv oine ist und true, wenn er online sein knnte. Zustzlich feuern auf dem window-Objekt die Events offline und online.1
9.1.1 Application Cache

Der Application Cache ist also fr die Applikationsdaten zustndig. Dies knnten Bilder, HTML-, CSS- oder JavaScript-Dateien sein, die der Browser fr den OineZugri vorrtig halten soll. Wichtig ist hierbei, dass dieser Cache nicht mit dem Browser-Cache verwechselt werden darf. Beim Application Cache legt der Entwickler explizit fest, was genau gecached werden soll und was nicht. Der Browser muss diese Daten dann vorrtig halten, wenn der Nutzer dies erlaubt hat.
1
Vgl. [Hic11a, 6.6.10 Browser state]
Seite 58 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 Fr diese Denition wird ein Cache Manifest bentigt, welches die Pfade der Ressourcen enthlt. Das Cache Manifest besitzt keine Dateiendung, wird UTF-8 kodiert und mit dem MIME-Typ text/cache-manifest ausgeliefert. Die Datei kann die folgenden drei Abschnittstypen (mehrfach) enthalten: CACHE: In diesem Abschnitt mssen zwingend genaue Ressourcen angegeben werden, welche gecached werden sollen. NETWORK: Dieser Abschnitt kann auch Teilpfade enthalten und beschreibt alle Inhalte, die explizit vom Server geladen werden sollen. FALLBACK: Ersatzinhalte knnen in diesem Abschnitt fr Ressourcen oder Teilpfade hinterlegt werden. Bei der Verwendung des Application Caches ist zu beachten, dass ein Update des Caches nur erfolgt, wenn sich die Manifest-Datei ndert, nicht aber wenn sich Ressourcen gendert haben. Ein manuelles Aktualisieren des Caches ist nur im JavaScript durch applicationCache.update() mglich. Der Browser bietet nur die Mglichkeit den Cache komplett zu lschen. Ein Cache Manifest fr eine spirit@fhs-Webseite mit einem Blog, der nicht gecached werden soll, knnte wie folgt aussehen: Listing 9.1: Mglicher Manifest-Aufbau CACHE MANIFEST images / spiritLogo . png index . html NETWORK : / blog / CACHE : partner . html # Ersatzinhalte FALLBACK : / offlineMessage . html Auf dem window.applicationCache-Objekt feuern verschiedene Events, die bspw. den Fortschritt der Cache-Erstellung melden. Auerdem kann der Status des Caches mit Hilfe von applicationCache.status als Zahlencode ausgelesen werden.2
9.1.2 Web Storage

Web Storage ist der derzeit gelugste und von den meisten Browsern untersttzte Datenspeicher im Browser. Die Datenspeicherung erfolgt in Form von Name-WertPaaren in einem Storage Objekt. Dafr stehen die globalen Objekte localStorage und sessionStorage zur Verfgung. Im Falle von sessionStorage werden die Daten nur fr die aktuelle Session gespeichert und gelscht, sobald das Fenster geschlossen wird. Fr die Langzeitspeicherung ist localStorage vorgesehen.
2
Vgl. [Hic11a, 6.6 Oine Web applications] und [Mah11b]
Seite 59 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 Der Zugri auf diesen Datenspeicher ist nur von ein und derselben Webseite aus mglich. Fr die Zuordnung nutzt der Browser das verwendete Protokoll, den Host und Port einer Webseite. Fr die Bearbeitung des Datenspeichers stehen verschiedene Methoden zur Verfgung. So knnen mit setItem(key, data), getItem(key) und removeItem(key) einzelne Eintrge gesetzt, gelesen und gelscht werden. clear() setzt den gesamten Speicher der Webseite zurck. Diese Art der Datenspeicherung wird in der Spirit Android App verwendet und im Kapitel 10 in Aktion gezeigt. Events fehlen auch bei diesem HTML5-Feature nicht, sie feuern auf dem Elternobjekt storage, sobald nderungen an einem der beiden Speicher durchgefhrt werden. Dabei sind Informationen zum neuen und alten Wert, dem Schlssel und der storageArea (local- oder sessionStorage) im Event enthalten.3
9.1.3 Alternativen
Fr die Speicherung von Daten auf Clientseite gab es bis November 2010 noch zwei Alternativen: Web SQL und Indexed DB. Seitdem ist die Entwicklung des Web SQL Standards beim W3C eingestellt und es wird von einer Nutzung abgeraten. Zwar sind Implementierungen in Webkit-Browsern und Opera noch vorhanden, aber eine chendeckende Untersttzung ist nicht mehr in Sicht.4 Als wirkliche Alternative ist also nur noch die Indexed DB vorhanden. Sie kann zu den NoSQL-Datenbanken gezhlt werden und speichert die Daten als Objekte in einer Schlssel-Wert-Paar-Struktur ab. Der Unterschied zum Web Storage liegt darin, dass Felder innerhalb der abgelegten Daten mit Indiezes versehen werden knnen und ein Zeiger-Konzept vorhanden ist. Durch diese nderungen ist der Datenspeicher leistungsstrker und die Datenmenge kann leichter verwaltet werden.5
9.2 Kommunikationsmglichkeiten
Neben diesen Mglichkeiten der oine Datenspeicherung versucht HTML5 auch Probleme der Kommunikation zwischen Fenstern, iFrames, Server und Client sowie ber verschiedene Domains hinweg zu lsen. Webseiten sind fr die Browser in sich geschlossene Einheiten, weshalb sie die Kommunikation und den Datenaustausch zwischen verschiedenen Quellen nicht zulassen. Damit dies aber ermglicht werden kann und keine Sicherheitslcken wie Cross-SiteScripting entstehen, fhrt HTML5 verschiedene neue Kommunikationsmglichkeiten ein. Die Kommunikation ndet ber das Senden von Nachrichten statt. Daher verwenden alle nachfolgend vorgestellten Varianten ein MessageEvent, welches feuert, wenn eine neue Nachricht im Fenster eintrit.
3 4
Vgl. [Hic11a, 12 Web storage] und [Mah11b] Vgl. [Hic10] 5 Vgl. [MSG+ 11] und [Mah11b]
Seite 60 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12
9.2.1 WebMessaging API

Das WebMessaging API stellt Methoden zur Verfgung, durch die eine Webseite mit einem eingebetteten iFrame kommunizieren kann. Wenn diese beiden Applikationen unterschiedliche Origins6 haben, wrde eine Kommunikation als Cross-Site-Scripting verstanden und vom Browser geblockt werden. Die WebMessaging API speziziert zwei Modelle - das Cross-Document und das Channel Messaging. Mit Hilfe der Methode postMessage(data, receive_origin[, transfer]) kann im ersten Fall eine Nachricht versendet werden. Diese Nachricht kann dann durch die Registrierung des message-Eventhandlers auf dem windowObjekt als MessageEvent empfangen und weiterverarbeitet werden wie dies das folgende Listing zeigt7 : Listing 9.2: Beispiel des Cross-Document Messagings // JS auf http :// example . de / index . html iFrame . contentWindow . postMessage ( HTML5 for spirit@fhs , http :// spirit . de / ) // JS auf http :// spirit . de / index . html window . addEventListener ( message , function ( event ) { var sender = event . source ; sender . postMessage ( YES ! , event . origin ) ; } , false ) ; Das Channel Messaging arbeitet hingegen mit einem Zwei-Wege-Kanal. Fr die Identizierung dienen die Ports fr Anfang und Ende des Kanals. Die Erzeugung eines solchen Kanals geschieht mit var channel = new MessageChannel();. Die Variable channel enthlt dann zwei Ports, wovon einer lokal verwendet und der andere bspw. mit Cross-Document Messaging an einen Empfnger versendet werden kann.8 Nun knnen Eventhandler an die Ports gebunden werden, welche die Nachrichten empfangen.9
9.2.2 Web Sockets

HTML5 bringt das Konzept der Web Sockets in den Browser. Hierbei handelt es sich um ein Protokoll, welches von der IETF10 entwickelt wird und eine bi-direktionale Verbindung zwischen Browser und Server ermglicht. Die WHATWG und das W3C spezizieren fr dieses Protokoll die JavaScript Schnittstelle, durch welche eine dauerhafte Verbindung mit einem TCP11 -Socket aus dem Browser heraus erstellt werden
Origin ist wie beim WebStorage die Zusammensetzung aus Protokoll, Host und Port einer Webseite. Auch http://spirit.de und https://spirit.de sind somit unterschiedliche Origins. 7 Vgl. [Hic11a, 11.4 Cross-document messaging] 8 Die Versendung erfolgt als Objektliste als transfer-Parameter. 9 Vgl. [Hic11a, 11.5 Channel messaging] 10 http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol 11 TCP steht fr Transmission Control Protocol.
6
Seite 61 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 kann. Sie ermglichen durch eine dauerhafte Verbindung die Erstellung von Echtzeitanwendungen. Listing 9.3: Erstellen einer Web Socket Verbindung var socket = new WebSocket ( " ws ://127.0.0.1:8080/ " ) ; socket . onopen = function () { // ... } socket . send ( " Hello ! " ) ; Ein Web Socket kann mit dem in Listing 9.3 dargestellten Konstruktor erstellt werden. Als Parameter reicht die Angabe einer URL, optional knnen aber zustzlich ein oder mehrere Protokolle deniert werden. Zur Steuerung des Sockets stehen wieder Eventhandler wie onclose, onerror und onopen zur Verfgung. Nachrichten knnen mit der Methode send(data) bertragen werden. Der Erhalt einer Nachricht ber den Socket wrde auch hier wieder ein message-Event auslsen.12 Die Browseruntersttzung ist sehr unterschiedlich ausgeprgt. So ist in den Firefox Versionen 4 und 5 die API zwar vorhanden, aber deaktiviert. In aktuelleren Versionen muss das Interface ber MozWebSocket angesprochen werden.13 Der Browser Chrome nimmt wieder einer Vorreiterrolle ein und untersttzt die Spezikation gegenber Safari und Opera vollstndig. Eine Untersttzung im Internet Explorer ist fr Version 10 angekndigt.14
9.2.3 Weitere Kommunikations-APIs

Auer den genannten neuen Kommunikationsmitteln hlt HTML5 noch Server-sent Events bereit. Diese sollen dafr dienen, dass ein Server Updates an einen Browser senden kann, ohne dass dieser einen Request senden muss. Die Realisierung eines derartigen Vorgangs geschieht ber das EventSource-Interface wie im folgenden Listing dargestellt: Listing 9.4: Erstellen einer EventSource var stream = new EventSource ( " twitterStream . php " ) ; stream . onmessage = function ( event ) { alert ( event . data ) ; }; Durch diese Technik knnen Webseiten-Updates, die keine Userinteraktion erfordern, auf einfache Weise umgesetzt werden. Als Beispiel knnten Statusupdates, Brseninfos, News oder Twitternachrichten einfach an den Browser gesendet werden, ohne das diese extra angefordert werden mssten. Die Verarbeitung im Browser erfolgt
12 13
Vgl. [Hic11a, 11.3 Web sockets] Siehe https://developer.mozilla.org/en/WebSockets#AutoCompatibilityTable 14 Siehe http://caniuse.com/#feat=websockets
Seite 62 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 auch hier wieder mit Events. Der Server muss die Daten als text/event-stream MIME-Typ versenden. HTML5 fhrt aber auch noch ein Media Streaming API und Peer-to-Peer Verbindungen unter der Rubrik Video conferencing and peer-to-peer communication ein. Diese benden sich noch in einer experimentellen Phase und werden bisher von keinem Browser untersttzt.15
9.3 Interaktions-APIs
Die Interaktionsmglichkeiten zwischen Browser und Betriebssystem werden durch HTML5 erweitert. Es sind Spezikationen fr Web Notications und ein Drag&Drop API vorhanden, die das Leben des Browsernutzers erleichtern sollen. Unter Web Notications verstehen sich System-Benachrichtigungen, die von einer Webseite ausgelst werden knnen. Als Benachrichtigungstypen sieht die Spezikation die folgenden vor: ambient notications sind kurze Einblendungen, die ohne Nutzerinteraktion wieder verschwinden. interactive notications leiten Nutzeraktionen an die Applikation weiter. persistent notications mssen explizit vom Nutzer geschlossen werden. simple notications bestehen nur aus einem Icon und etwas Text. web notications beinhalten Websprachen wie HTML und SVG. Die Spezikation sieht vor, dass auch Benachrichtigungssysteme wie Growl fr Mac OS, NotifyOSD fr Linux oder das Windows Notication API angesprochen werden knnen.16
Abbildung 9.1: Screenshot einer Chrome Benachrichtigung Listing 9.5: Benachrichtigung mit Chrome var notifications = window . webkitNotifications ; if ( typeof notifications !== " undefined " ) { function spiritAlert () { if ( notifications . checkPermission () !== 0) { notifications . requestPermission () ; }
15 16
Vgl. [Hic11a, 9 Video conferencing and peer-to-peer communication] Ein lauhiger Prototyp ist hier zu nden: https://github.com/FlorianX/ HTML5-experiments/blob/master/forms/index.html
Seite 63 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 var note = notifications . createNotification ( " ../ res / images / spiritIcon . jpg " , " Spirit Error " , " The System is down ! Attention ! " ) ; note . show () ; } } else { alert ( " This is not Chrome ! You re browser doesn t support notifications . " ) ; } Chrome ist bisher der einzige Browser der diese Funktionalitt untersttzt, aber leider noch nicht genau nach Spezikation. Das Listing 9.5 zeigt daher nur eine in diesem Browser funktionierende Lsung, welche eine Benachrichtigung wie aus Abbildung 9.1 erzeugt.17 Eine weitere Neuheit in Sachen Interaktion ist das Drag&Drop API von HTML5. Es stammt ursprnglich aus dem Internet Explorer 5, wurde aber von den Entwicklern in Safari und Firefox bernommen, weshalb es spter in der Spezikation von Ian Hickson landete. Die Nutzung ist horrible18 , wie dies selbst Ian Hickson umschrieb. Das Drag&Drop API stellt verschiedenste Events wie dragstart, dragover oder drop und Attribute zur Verfgung. Darunter ist auch das draggable-Attribut, welches ein HTML-Element als verschiebbar auszeichnet. Das schreckliche an diesem API ist, dass sich manche Events anders verhalten als dies im JavaScript blich ist. So muss bspw. das Event dragover mit event.preventDefault() abgebrochen werden, da es sonst das Droppen verhindert. Die Standardisierung dieser Schnittstelle ermglicht das Cross-Webseiten- und Cross-Browser-Drag&Drop und ist somit ein entscheidender Interoperabilittsbonus von HTML5.19
9.4 Weitere Spezikationen

Die neuen Mglichkeiten, die HTML5 bietet, reien nicht ab, daher sollen im Folgenden noch weitere interessante - aber sicher nicht alle - Vertreter genannt werden. Mit Web Workers 20 lassen sich JavaScript-Berechnungen als Hintergrundprozesse auslagern, wodurch der Browser bei langen Berechnungen nicht mehr blockiert. Die Shared Workers 21 treiben dies auf die Spitze, in dem sie es ermglichen, dass mehrere Dokumente auf einen solchen Prozess zugreifen knnen. Workers sind in beiden Fllen vllig von der Auenwelt abgeschnitten und haben daher auch keinen Zugri auf das DOM. Die Kommunikation ndet, wie bei den anderen Neuheiten auch, nur ber Events und deren Inhalte statt.
Vgl. [Gre11] Siehe Twitterpost http://twitter.com/#!/Hixie/status/4075253361 19 Vgl. [Hic11a, 8.6 Drag and drop] 20 Ein Prototyp mit den Trmen von Hanoi und der -Berechnung ist hier zu nden: https://github.com/FlorianX/HTML5-experiments/blob/master/workers/webworkers/ index.html 21 Folgender Prototyp ermglicht die Synchronisation zweier Browserfenster: https://github. com/FlorianX/HTML5-experiments/blob/master/workers/sharedworkers/index.html
18 17
Seite 64 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 Sie besitzen nur wenige Funktionalitten des DOM-Interfaces und knnen bspw. mit postMessage() Nachrichten senden. Auerdem knnen sie weitere Scripte mithilfe von importScripts() nachladen und durch den Konstruktor-Aufruf weitere Sub-Worker erstellen. Das folgende Listing 9.6 zeigt, wie Worker erstellt und ihnen Nachrichten gesendet werden: Listing 9.6: Erstellung der Worker // Web Worker var worker = new Worker ( worker . js ) ; // Shared Worker var sharedWorker = new SharedWorker ( worker . js ) ; worker . postMessage ( Hi ! ) ; sharedWorker . port . postMessage ( Hallo ! ) ; Da mehrere Dokumente auf einen Shared Worker zugreifen knnen, wird hier wieder mit Kanlen und den entsprechenden Ports gearbeitet. Im Worker werden dann Events wie self.onmessage oder self.onconnect verwendet. Der Shared Worker erhlt den Port, an den er antworten muss, ber die Port-Eigenschaft des MessageEvents. Die Versendung von Daten erfolgt mit JSON, weshalb auch komplexere Strukturen bertragen werden knnen. Die Worker bringen damit Nebenlugkeit und auch verteiltes Rechnen in die Web-Welt und das JavaScript.22 Im Umfeld von HTML5 sind diverse weitere Spezikationen angesiedelt und im Entstehen. So speziziert das W3C die Dateibearbeitung aus dem JavaScript heraus. Hierzu sind drei miteinander verwobene Spezikationen vorhanden. Das File API speziziert neben der reinen Reprsentation von Dateien in Web Applikationen auch den Zugri auf diese und deren Inhalte durch einen FileReader. Dieses API kann mit dem Drag&Drop API interagieren und ist fr das Einlesen und Verarbeiten von Dateien auf dem Client verantwortlich.23 Auf diesem API basieren die Spezikationen fr das File API: Writer und das File API: Directories and System. Erstere deniert einen Mechanismus zum clientseitigen Schreiben von Dateien, Letztere beschreibt eine Schnittstelle zur Ordnererstellung und Navigation im Dateisystem des Clients.24 Alle APIs knnen auf zwei Arten genutzt werden: asynchron und synchron. Das asynchrone Vorgehen ist der Standardweg, um das Blockieren des Browsers zu verhindern. Die Kombination dieser APIs ermglicht das Lesen, Schreiben und Strukturieren von groen Datenmengen als Binr- oder anderes Datei-Format in einer abgeschotteten Ordnerstruktur (Sandbox) auf dem Client. Diese APIs werden bisher nur von Chrome in einem fortgeschrittenen Mae untersttzt. Die Spezikationen rund um den neuen HTML-Standard scheinen kein Ende zu nden. So versucht Mozilla ein WebAPI 25 zu entwicklen, das die Steuerung und Nut22 23
Vgl. [Hic11a, 10 Web workers] Vgl. [RS11] 24 Vgl. [Uhr11b] und [Uhr11a] 25 https://wiki.mozilla.org/WebAPI
Seite 65 von 87
9. Weitere HTML5 APIs und Features Fachhochschule Schmalkalden WS 2011/12 zung von Kamera, Kontaktliste, SMS und Telefonie des Gertes ber den Browser erlaubt. hnliche und noch mehr Ziele verfolgt die Device APIs Working Group des W3C. Sie spezizieren unter anderem den Zugri auf den Batteriestatus, die Sensoren oder Vibration eines Gertes.26 Dies zeigt eine klare Ausrichtung auf mobile Gerte wie Smartphones oder Tablets. Diese knnten durch die Vielzahl der Spezikationen mit extrem eingebetteten Web-Applikationen bedient werden, ohne das ein Unterschied zu nativen Entwicklungen zu erkennen wre. Die letzten zwei neuen Spezikationen, die aufgefhrt werden sollen, sind das Web Audio27 und Fullscreen API 28 . Hierbei handelt es sich bisher lediglich um Verfasserentwrfe. Das Fullscreen API beschreibt, wie ein Element eine Vollbilddarstellung anfordern knnte. Fr die Audiobearbeitung wurde von Google das Web Audio API zur Standardisierung beim W3C eingereicht, welches bereits teilweise in WebkitBrowsern funktioniert. Es kann in Verbindung mit dem 2D- und WebGL-Context des Canvas-Elements genutzt werden, was Animationen und Applikationen bspw. durch Audioeekte interaktiver gestaltet.29 Nach dieser Vielzahl von verschiedenen neuen Spezikationen im HTML5-Universum, wird das nchste Kapitel einen Blick auf den Nutzen von HTML5 im Bereich der mobilen Gerte werfen.
26 27
Siehe http://www.w3.org/2009/dap/ https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html 28 http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html 29 Interessante Beispiel-Applikationen mit WebGL und Audioeekten knnen mit Chrome unter folgender URL betrachtet werden: http://chromium.googlecode.com/svn/trunk/samples/ audio/index.html
Seite 66 von 87
10 HTML5-Apps
Dieses Kapitel wird sich mit dem Trend der mobilen Apps (Applikationen) beschftigen. Dabei sollen zuerst die App-Typen abgegrenzt und gegenbergestellt werden. Anschlieend erfolgt eine Aufzhlung von bisher relevanten HTML5-Features zur mobilen App-Entwicklung sowie die Vorstellung der Spirit HTML5 Android App.
10.1 App-Typen
Die App-Entwicklung kann auf drei unterschiedliche Arten stattnden: Native App, WebApp und Hybrid App. Eine Native App wird speziell fr ein bestimmtes Betriebssystem entwickelt und fgt sich somit in das System ein. Sie ist dadurch plattformabhngig und muss in der vom System vorgeschriebenen Programmiersprache verfasst werden. Fr die Entwicklung von iOS-Apps sieht Apple Objective-C sowie C++ vor. Android hingegen setzt auf Java und Java-verwandte Sprachen sowie auf den Einsatz von C/C++ fr Performance-kritischen Code. WebApps basieren dagegen auf Webstandards wie HTML(5), CSS und JavaScript. Es handelt sich hierbei um normale Webseiten, deren Darstellung fr mobile Endgerte optimiert wurde. Diese Apps sind plattformunabhngig und bentigen nur einen Browser, der die verwendeten Standards untersttzt. Bei der Optimierung sollte das Konzept des Progressive Enhancement beachtet werden. Wenn bspw. Features von HTML5 eingesetzt werden, dann so, dass die WebApp trotz fehlender Browseruntersttzung genutzt werden kann. Der letzte Typ der Apps, die Hybrid App, versucht nun die beiden genannten Wege zu vereinen. So sollen Apps mittels HTML5, JavaScript und CSS entwickelt und dann in eine Native App transformiert oder eingebunden werden. Die Entwicklung erfolgt meist mithilfe von Frameworks wie PhoneGap1 , welche zustzlich native Funktionalitten durch eine eigene API fr die WebApp verfgbar machen und so eine Lcke schlieen.
10.2 Nativ vs. WebApp

Ein Trend geht eindeutig in Richtung WebApps, was die Bandbreite an verfgbaren Frameworks zeigt. Der Vorteil scheint hier klar auf der Hand zu liegen - eine App fr alle Plattformen. Doch ist das wirklich empfehlenswert? Eine App fr alle Systeme heit auch, dass die App immer gleich aufgebaut ist. Doch die Usability und verschiedene Richtlinien der Plattformen sollten in der Konzeption
1
Siehe http://phonegap.com/
Seite 67 von 87
10. HTML5-Apps
einer App bercksichtigt werden. Android Smartphones haben bspw. einen physikalischen Back-Button, in iOS ist dies ber eine Navigations-Leiste geregelt. Weitere Unterschiede sind im App-Men zu nden, da iOS eine Men-Leiste und Android einen Men-Button besitzt. Es ist bereits schwierig, diese genannten Punkte unter einen Hut zu bringen, was deutlich macht, dass weitere systemspezische Look-andFeel-Eigenschaften ein integriertes Erscheinungsbild einer App auf unterschiedlichen Plattformen erschweren. Das Problem, dass WebApps oder Hybride nicht auf hardwarespezische Details wie den Batteriestatus oder die Kamera zugreifen knnen, wird durch APIs von Frameworks wie PhoneGap oder durch neue Standards wie das WebAPI von Mozilla gelst. Durch diese Lsungen kann eine Hybrid App oder auch eine WebApp bspw. direkt auf die Kamera oder das Telefonbuch zugreifen. Standards knnen unterschiedlich interpretiert werden, weshalb auch Unterschiede bei der Darstellung von manchen Webseiten in verschiedenen Browsern auftreten. Das heit aber, das Features gar nicht oder unterschiedlich implementiert sein knnen. Hier ist die Anwendung und das Vorgehen zur Nutzung dieser Features entscheidend. Ein Vorteil von WebApps ist, dass sie unabhngig von Zulassungsprozessen und Beschrnkungen der App Stores genutzt werden knnen. Updates der WebApps sind, sobald sie auf dem Webserver liegen, fr jeden Nutzer verfgbar und unterliegen keiner nochmaligen Kontrolle oder einem komplexen Verteilungsnetzwerk. Der App Store stellt aber den Nativen Apps die Mglichkeit der gezielten Vermarktung bereit und ist somit auch frderlich. An diesen Punkten ist klar zu erkennen, dass beide App-Typen ihre Vor- und Nachteile haben. Es ist schwer abzuschtzen, welcher Typ die bessere Wahl ist. Daher sollte immer von Fall zu Fall abgewogen werden, welches die optimalere Alternative fr das anvisierte Anwendungsgebiet darstellt.2
10.3 Relevante HTML5-Features

Die mobile App-Entwicklung, egal ob Hybrid App oder WebApp, kann sich verschiedene HTML5-Features zunutze machen, da viele Smartphones bereits einige der HTML5-Neuerungen beherrschen. Oft wird in diesem Zusammenhang nur von den Multimedia-Elementen <video>, <audio> und <canvas> gesprochen, die bereits grochig eingesetzt werden. Doch es gibt noch weitere interessante HTML5-Features, die auf mobilen Plattformen verfgbar sind und dort dem Nutzer einen Mehrwert verschaen. Die in Kapitel 4.2 eingefhrten semantischen Elemente helfen auch hier bei einer besseren Strukturierung und untersttzen die Interpretation des Browsers. Durch die neuen Input-Typen und Formularelemente aus Kapitel 6 wird die Nutzung von WebApp-Formularen fr Anwender erleichert, da viele Touch-Smartphones ihre Tastatur auf die verschiedenen Typen abstimmen knnen. Bei einer geforderten EmailEingabe werden bei Android bspw. das @ und .com gleich auf der Standard2
Vgl. [Mah11a] und [Eid11]
Seite 68 von 87
10. HTML5-Apps
Tastatur eingeblendet und die Tastatur schaltet bei einer Nummern-Eingabe automatisch auf das Zahlenfeld um. Ein fr den mobilen Einsatz sehr interessantes API ist das Web Storage API. Dieses ist unterteilt in das localStorage und sessionStorage API, wovon aber nur das localStorage API oft in Apps Anwendung ndet. Durch dieses ist es erstmals mit JavaScript mglich, Daten lokal abzulegen. So knnen Daten nicht nur fr eine lngere Zeit auf dem Gert gespeichert, sondern auch Funkverbindungsabbrche ausgeglichen oder das Pre-Fetching3 realisiert werden. Der mit HTML5 eingefhrte Application Cache ist fr die Steuerung des CachingVerhaltens zustndig und kann auch in diesem Bereich bereits verwendet werden. Durch ihn knnen Entwickler gezielt statische Inhalte wie Bilder, JavaScript- oder CSS-Dateien vom Browser cachen lassen, was die Netzwerkbelastung beim AppAufruf minimiert. Das letzte interessante Feature ist das Geolocation API. Dieses wird bereits jetzt schon hug eingesetzt und ermglicht so das Angebot von Apps mit Location Based Services. HTML5 bietet also eine Reihe von Techniken, die fr die Entwicklung von mobilen Applikationen, sei es auf richtiger App-Basis oder als optimierte Webseite, interessant sein drften. Das nchste Kapitel zeigt die Anwendung einiger der genannten Techniken bei der Erstellung der Spirit HTML5 App.
10.4 Spirit HTML5 Android App

Die bisherigen Abschnitte haben gezeigt, dass HTML5 eine interessante Plattform fr die App-Entwicklung darstellt und die Umsetzung auf zwei Arten erfolgen kann. Die im Folgenden vorgestellte App wurde als eine Art Hybrid App entwickelt.4 (Eine Art aus dem Grund, weil nur die zur Verfgung stehenden Techniken Java und HTML5 sowie das JavaScript Framework jQuery Mobile 5 genutzt und dabei auf die Verwendung einer zustzlichen API Schicht Abbildung 10.1: App-Logo wie PhoneGap verzichtet wurde.) Die Entscheidung el auf eine Hybrid App, um sehen zu knnen, wie sich auf HTML5-basierende Teile einer App in das System integrieren lassen. Nach kurzer Zeit stand auerdem fest, dass der entwickelte Prototyp als richtige App im Android Market angeboten werden sollte. Die Hybrid-Entwicklung ermglichte dies ohne Probleme. Fr den Vertrieb ber den Market ist ein App-Icon ntig. Dieses wurde, wie Abbildung 10.1 zeigt, an das neue Spirit Logo angelehnt, um den Wiedererkennungswert zu erhhen.
3 4
Pre-Fetching bezeichnet das intelligente Vorladen von in Zukunft bentigten Daten. Der Quellcode ist hier zu nden: https://github.com/FlorianX/Spirit-HTML5-App 5 http://jquerymobile.com/
Seite 69 von 87
10. HTML5-Apps
Die Abbildung 10.2 zeigt die verentlichte App in der Listen- und Einzelansicht der News. Die Anzeige eines Stundenplans ist bisher noch nicht mglich.
(a) Listenansicht
(b) Einzelansicht
Abbildung 10.2: Screenshots der Spirit App Eine Android App basiert auf verschiedenen Activities fr jede mgliche Ansicht. Um HTML5 in eine App zu integrieren, ist also mindestens eine Activity ntig. Listing 10.1: Android Activity in Java public class SpiritHtml5AppActivity extends Activity { WebView webView ; @Override public void onCreate ( Bundle savedInstanceState ) { [...] webView = ( WebView ) findViewById ( R . id . webView ) ; WebSettings settings = webView . getSettings () ; settings . setJavaScriptEnabled ( true ) ; settings . setDomStorageEnabled ( true ) ; webView . setWebChromeClient ( new WebChromeClient () ) ; webView . loadUrl ( " file :/// android_asset / www / index . html " ) ; } @Override public boolean onKeyDown ( int keyCode , KeyEvent event ) { if (( keyCode == KeyEvent . KEYCODE_BACK ) &&
Seite 70 von 87
10. HTML5-Apps webView . canGoBack () ) { webView . goBack () ; return true ;
} return super . onKeyDown ( keyCode , event ) ; } } Das Listing 10.1 zeigt die SpiritHtml5AppActivity und deren Methoden onCreate und onKeyDown. Erstere wird aufgerufen, sobald die App gestartet wird. Sie initialisiert eine Ansicht namens webView zur Anzeige von Webseiten und erlaubt in dieser die Nutzung von JavaScript und DomStorage. Auerdem wird ein WebChromeClient erzeugt, welcher fr alles zustndig ist, was das User Interface des Browsers betrit. Dies umfasst bspw. die Anzeige von JavaScript Meldungen, die mittels alert() ausgelst wurden. Als Letztes wird der WebView angewiesen eine lokale URL - die eigentliche App - aufzurufen. Durch die zweite Funktion im Listing 10.1 soll das Zurckblttern per Back-Button eines Android-Smartphones in der App nutzbar gemacht werden. Ansonsten wrde ein Klick auf diesen die App beenden. In der App ist noch zustzlicher Java-Code fr die Integration von Google Analytics vorhanden, welcher aber zur besseren bersicht entfernt wurde. Alle nachfolgenden Listings entstammen der HTML-Datei, welche oben als URL aufgerufen wurde. Listing 10.2: HTML-Struktur der App < div data - role = " page " data - theme = " b " id = " newsPage " > < div data - role = " header " > <h1 > News </ h1 > <a onclick = " getNews ( true ) ; " data - icon = " refresh " data - role = " button " data - theme = " a " class = " ui - btn - right " > Update ! </a > </ div > < div data - role = " content " id = " newsList " > </ div > </ div > Die Grundstruktur der App ist sehr minimal gehalten, da auf einem Smartphone oft Platzmangel herrscht. Was aber in Listing 10.2 sofort aullt, sind die vielen data-* Attribute. Diese wurden in HTML5 neu eingefhrt und dienen zur Anreicherung des HTMLs mit Daten, die bspw. fr die Bearbeitung mit JavaScript bentigt werden. In diesem Fall nutzt das verwendete Framework jQuery Mobile die entsprechenden Angaben fr Einstellungszwecke. So wird ein einfacher Link mit Hilfe von data-role="button" als Button ausgezeichnet und erhlt vorgegebene CSS- und JavaScript-Eigenschaften. jQuery Mobile ermglicht nicht nur die Nutzung von bereits getesteten und angepassten Design-Vorgaben und bietet damit Kompatibilitt zu vielen Plattformen, sondern es stellt auch entsprechende Events fr die Touch-Interaktionen wie swipe, tap und taphold zur Verfgung.
Seite 71 von 87
10. HTML5-Apps
Listing 10.3: Initialisierung der App $ ( document ) . ready ( function () { getNews () ; $ ( . singleNews ) . live ( swiperight , function ( event ) { $ . mobile . changePage ( $ ( # newsPage ) , { transition : " none " }) ; event . preventDefault () ; }) ; }) ; Die HTML-Datei wird durch den Browser der Activity aufgerufen. Wenn die Datei vollstndig geladen ist, wird die bereits bekannte jQuery Methode ready(...) ausgefhrt. Diese ruft die Methode getNews([live]) auf, welche im folgenden Listing abgebildet ist. Auerdem wird ein Eventhandler bei allen Elementen mit der Klasse singleNews fr das Event swiperight hinterlegt. Wenn das Event feuert, wird durch diese Funktion die Listenansicht geladen. Die Idee hinter diesem Konstrukt ist, dass ein Nutzer, der sich auf der Einzelansicht einer News bendet, durch ein Wischen ber den Touchscreen wieder zur Startseite zurckgelangt. Listing 10.4: Abrufen der News ber REST oder den localStorage function getNews ( live ) { $ . mobile . showPageLoadingMsg () ; live = typeof ( live ) != undefined ? live : false ; if ( typeof localStorage !== undefined ) { var localNewsJSON = localStorage . getItem ( SpiritApp_News ) ; } if ( localNewsJSON && ! live ) { renderNews ( JSON . parse ( localNewsJSON ) ) ; } else { $ . ajax ({ url : " http :// spirit . fh - schmalkalden . de / rest /1.0/ news " , dataType : json , success : function ( data ) { localStorage . setItem ( SpiritApp_News , JSON . stringify ( data ) ) ; renderNews ( data ) ; },
Seite 72 von 87
10. HTML5-Apps
error : function ( jqXHR , textStatus , errorThrown ) { $ . mobile . hidePageLoadingMsg () ; alert ( " Konnte keine Verbindung zum Server herstellen ! " ) ; } }) ; } } Die in Listing 10.4 dargestellte JavaScript Funktion ist das Herzstck der App und fr die Datenhaltung zustndig. Mit der Variable live wird entschieden, ob die Daten zwingend neu vom Server abgerufen werden sollen. Sie wird nur gesetzt, wenn der User explizit auf den Update-Button klickt. JavaScript kennt keine Default-Parameter-Werte, weshalb eine Prfung fr diese Variable eingefgt werden musste, die einen Standardwert setzt. Des Weiteren wird geprft, ob das localStorage API verfgbar ist und ob es bereits Daten enthlt. Falls dies der Fall ist, werden die Daten an die Funktion renderNews( data) bergeben, andernfalls wird mit einem jQuery Aufruf ein Ajax-Request gestartet, der die Daten bei der REST-Schnittstelle abfragt. Diese werden dann sofort im localStorage gespeichert und an renderNews weitergereicht. Die erwhnte Funktion renderNews wurde hier nicht explizit aufgefhrt, da sie sich nur mit der HTML-Generierung und Darstellung der News beschftigt und ein create-Event triggert, um jQuery Mobile darauf hinzuweisen, dass die Seite gendert wurde. Sie fgt auerdem fr jede News eine extra HTML-Seite in den DOM ein, welche als Einzelansicht dient. Mit diesen Schritten ist es mglich, eine einfache HTML5-App zu schreiben, die im Market verentlicht werden kann, Daten abruft und sie speichert. Fr weitere Entwicklungen in diesem Bereich wird aber eine WebApp empfohlen, da alle Studierenden die Spirit-URL kennen und diese auch nutzen sollten. Dadurch entsteht ein Single-Point-of-Contact, der auf einfache Weise aktuell gehalten werden kann und ein breiteres Publikum anspricht.
Seite 73 von 87
11 Kritik, Ausblick und Fazit

Die Sprache HTML entwickelt sich durch die vielen Neuheiten weg von einer reinen Dokumentenbeschreibung, hin zur Grundlage von Web-Applikationen. Dieses Kapitel widmet sich daher im ersten Teil den kritischen Seiten von HTML5 und dem Wildwuchs an Spezikationen. Auerdem wird ein kurzer Blick auf HTML.next geworfen, bevor im letzten Teil ein Fazit diese Arbeit abschliet.
11.1 Kritik
Der Fokus von HTML5 liegt auf den Web-Applikationen, weshalb sich die Spezikationen weniger mit reinem HTML und mehr mit den JavaScript APIs beschftigen. Web-Applikationen sollen sich durch HTML5 besser in das Betriebssystem integrieren lassen. Der Browser wird dadurch die zentrale Programmplattform, wie dies bereits Google im Betriebssystem Chromium OS vorsieht. Die treibenden Krfte hinter diesem Standard sind aber nicht die speziell zusammengesetzten Arbeitsgruppen des W3Cs, sondern eher die Browserhersteller. Sie sitzen am lngeren Implementierungshebel und haben es nicht nur geschat, dass die geplante XML Revolution des W3Cs scheiterte, sondern auch, dass das W3C den HTML-Entwurf der WHATWG teilweise bernahm. Auerdem sttzen sich die Browserhersteller bei ihren Implementierungen meist auf die Spezikation der WHATWG, also auf ihre eigene. Es scheint also eine Art Diktatur der Browserhersteller entstanden zu sein. Ob dies von Vorteil ist, wird sich zeigen.1 In Bezug auf den Standardisierungsprozess der WHATWG und des W3Cs ist zu sagen, dass die Vielzahl der vorhandenen und zum Teil unterschiedlichen Spezikationen kaum einen berblick ermglichen. Dies wird durch den Wechsel des Entwicklungsmodells der WHATWG noch verstrkt. Die Masse an verschiedenen Spezikationen und Tools wie Wikis, Bugtracker, Mailinglisten und Twitter auf beiden Seiten ist kaum zu durchschauen und meist sehr verwirrend. Ein Groteil des Standards wird, wie bereits andere HTML-Versionen, der Implementierung hinterher geschrieben. Die bernahme von proprietren Entwicklungen wie dem Canvas oder Drag&Drop API geschah, weil sie bereits auf breiter Front durch verschiedene Browser untersttzt wurden. Dies zeigt den starken Einuss der Hersteller, da das Drag&Drop API selbst vom Verfasser als schrecklich empfunden wird, es aber dennoch in die Spezikation gelangt ist. Weitere Kritik kommt von Douglas Crockford, einer JavaScript-Entwickler-Gre. Dieser ist der Meinung, dass bei der Spezizierung von neuen HTML5-Elementen zu
1
Vgl. [Kr11b, S. 453]
Seite 74 von 87
11. Kritik, Ausblick und Fazit
wenig auf Sicherheitsaspekte, insbesondere auf Cross-Site-Scripting, geachtet wird und die Spezikation daher besser neu geschrieben werden sollte.2 Eine Gruppe von Web-Designern um Jerey Zeldman kritisiert unter dem Namen THE HTML5 SUPER FRIENDS eher die rein semantischen Fehler an HTML5. Dabei geht es bspw. um die Barrierebildung des Canvas und die annhernde semantische Gleichheit von HTML-Elementen wie <article> und <section>.3 Ob die Kritikpunkte an der Spezikation beachtet werden oder nicht, liegt in beiden Gremien allein in den Hnden des Verfassers Ian Hickson.
11.2 Ausblick
Die vorhandenen Spezikationen von HTML5 und den verschiedenen anderen Ideen in deren Umfeld sind viel versprechend. Wenn den Sicherheitsaspekten noch mehr Aufmerksamkeit geschenkt wird, knnen die Sicherheitslcken sicher auch ausgemerzt werden. An HTML5 scheint zumindest im Augenblick kein Weg vorbei zu fhren, da auch der einzige bisherige Konkurrent (XHTML2) nicht mehr weiterentwickelt wird. Die Konkurrenz im multimedialen Bereich zieht sich langsam auch zurck. Adobe gab am 9. November 2011 bekannt, dass die Entwicklung des Flash Players fr mobile Gerte eingestellt wird und sich das Unternehmen strker auf HTML5 konzentrieren will.4 hnliche Spekulationen zur Zukunft von Microsofts Silverlight wurden am gleichen Tag laut. Die Version 5 von Silverlight soll demnach der letzte Release werden.5 Wann und ob eine der beiden HTML-Spezikationen je zum Standard erhoben wird, ist nicht abzusehen, zumal auch das neue Entwicklungsmodell der WHATWG nicht auf einen fertigen Stand hinarbeitet, sondern als Living Standard gefhrt wird. Die Planung des W3Cs dagegen sehen fr dessen Spezikation den Status Recommendation fr das zweite Quartal 2014 vor. Doch diese Spezikation enthlt nur einen Bruchteil der vorgestellten Neuheiten. Dies erklrt, warum beim W3C bereits die ersten Ideensammlungen fr eine neue HTML-Version anlaufen. Hierfr wurden bereits ein Wiki und Bugtracker bereitgestellt.6 Das Projekt wird als HTML.next bezeichnet. Die Idee ist die freie Sammlung von Ideen im Wiki sowie im Bugtracker. Im Wiki wird deutlich darauf hingewiesen, dass Ideen, die in HTML5 nicht umgesetzt werden sollen, einfach bernommen werden knnen. Die bisher gesammelten Ideen beziehen sich auf neue semantische Elemente fr Ortsangaben, Teaserauszeichnung und die Einbindung von ZIP-Archiven. Auerdem sind verschiedene Vorschlge vorhanden, die auf neue Formular- und Multimediafunktionen wie eine Fullscreendarstellung abzielen. Die WHATWG setzt dagegen auf die kontinuierliche nderung und Erweiterung ihrer Spezikation.
2 3
Vgl. [Net10] Vgl. http://zeldman.com/superfriends/ 4 Vgl. [Win11] 5 Vgl. [Fol11] 6 http://www.w3.org/wiki/HTML/next
Seite 75 von 87
11. Kritik, Ausblick und Fazit
11.3 Fazit
HTML5 bereichert die Webentwicklung durch viele interessante neue Mglichkeiten, damit aus Webseiten richtige Applikationen werden knnen. Zu beachten ist aber, dass der berwiegende Teil von HTML5 nicht aus reinem HTML, sondern aus JavaScript Schnittstellen besteht. Die vielen Quellcodebeispiele und prototypischen Implementierungen haben gezeigt, dass die zuknftige Technik bereits jetzt schon teilweise eingesetzt werden kann und die Browser mit der Untersttzung schon sehr weit sind - sogar der Internet Explorer 9. Natrlich sollte bei der Entwicklung neben dem Progressive Enhancement auch das Testen der Applikationen an aller erster Stelle stehen. Die Verwendung von HTML5-Features sollte mit Bibliotheken wie Modernizr7 untersttzt werden, da diese eine Feature-Erkennung bieten und so unterschiedliche Browserimplementierungen gezielt abfangen. Bei der Nutzung der WHATWG Spezikation ist darauf zu achten, dass sich diese tglich ndern kann. Auerdem enthlt sie teilweise hochexperimentelle Inhalte und Ideen. Interessant ist auch die Hilfsbreitschaft der WHATWG Mitglieder in ihrem IRC Channel. Entgegen diverser kritischer und negativer Meinungen8 konnte whrend der Bearbeitung festgestellt werden, dass bspw. Ian Hickson und Anne van Kesteren stets beratend zur Seite standen. HTML5 bietet auch erkennbare Potentiale in der Spieleentwicklung mit dem Canvas. Derzeit ist davon die Rede, dass iOS und Android den Spielekonsolen-Markt umkrempeln und Marktanteile ziehen.9 Wie lange wird es wohl dauern bis HTML5 hier in den Mittelpunkt der Betrachtung rckt? Der Trend geht klar in Richtung HTML5 und das nicht nur fr normale Webseiten und Web-Applikationen, sondern gerade auch fr mobile Endgerte. Daher wird fr weitere Web-Entwicklungen empfohlen, den Fokus auf HTML5 und die Optimierung fr mobile Endgerte zu legen.
7 8
http://www.modernizr.com/ Vgl. [Kr11b, S. 452 .] und http://molily.de/weblog/html5-prozess 9 http://heise.de/-1376769
Seite 76 von 87
Literaturverzeichnis
[ASA11] ASA, Opera S.: W3C Geolocation API support in Opera Presto 2.7. http://www.opera.com/docs/specs/presto27/geolocation/, 2011 [BL89] Berners-Lee, Tim: Information Management: A Proposal. http:// www.w3.org/History/1989/proposal.html, Mrz 1989 [BL92] Berners-Lee, Tim: HTML. http://www.w3.org/History/ 19921103-hypertext/hypertext/WWW/MarkUp/MarkUp.html, November 1992 [BL06] Berners-Lee, Tim: Reinventing HTML. http://dig.csail.mit. edu/breadcrumbs/node/166, Oktober 2006 [Bra10] Braun, Torsten: Das Internet der Zukunft. In: Informatik Spektrum Band 33 (2010), April, Nr. 2, S. 103105 [BV10] Bongers, Frank ; Vollendorf, Maximilian: jQuery - Das Praxisbuch. 1. Auage. Bonn : Galileo Press, 2010 [CAM97] CAMBRIDGE, USA MA: The World Wide Web Consortium Issues HTML 4.0 as a W3C Recommendation. http://www.w3.org/Press/ HTML4-REC, Dezember 1997 [CC11] Craig, James ; Cooper, Michael: Accessible Rich Internet Applications (WAI-ARIA) 1.0. http://www.w3.org/TR/wai-aria/, Januar 2011. W3C Candidate Recommendation [CZ10] Carle, Kevin ; Zacharias, Chris: Introducing YouTube HTML5 Supported Videos. http://youtube-global.blogspot.com/2010/01/ introducing-youtube-html5-supported.html, Januar 2010. The Ocial YouTube Blog [Dou10] Dougherty, Brad: Try our new HTML5 Player! http://vimeo. com/blog:268?utm_source=twitterfeed&utm_medium=laconica, Januar 2010. Sta Blog [Eid11] Eidhof, Chris: HTML5 IS NO SILVER BULLET FOR APPS. http://chriseidhof.tumblr.com/post/12170749641/ html5-is-no-silver-bullet-for-apps, Oktober 2011 [Fol11] Foley, Mary J.: does it matter)? Will there be a Silverlight 6 (and http://www.zdnet.com/blog/microsoft/
77
will-there-be-a-silverlight-6-and-does-it-matter/11180, November 2011 [Gra11] Graff, Eliot: Polyglot Markup: HTML-Compatible XHTML Documents. http://www.w3.org/TR/html-polyglot/, Mai 2011. Working Draft [Gre11] Gregg, John: Web Notications. http://www.w3.org/TR/ notifications/, Mrz 2011. Working Draft [Hic10] Hickson, Ian: Web SQL Database. webdatabase/, November 2010 http://www.w3.org/TR/
[Hic11a] Hickson, Ian: HTML. http://www.whatwg.org/html, November 2011. Living Standard [Hic11b] Hickson, Ian: HTML is the new HTML5. http://blog.whatwg.org/ html-is-the-new-html5, Januar 2011 [Hic11c] Hickson, Ian: HTML5. http://www.w3.org/TR/html5/, Mai 2011. Working Draft [Inc11] Inc., Google: Verwendung der Standortfreigabe. https://www.google. com/support/chrome/bin/answer.py?answer=142065&hl=de, 2011 [Kes11a] Kesteren, Anne van: Blog - Anne van Kesteren. annevankesteren.nl/, 2003-2011 http://
[Kes11b] Kesteren, Anne van: WHATWG Weekly: Simplifying the DOM. http: //blog.whatwg.org/weekly-simple-dom, Oktober 2011 [Kes11c] Kesteren, Anne van: WHATWG Weekly: TPAC 2011. http://blog. whatwg.org/weekly-tpac-2011, November 2011 [KP11] Kesteren, Anne van ; Pieters, Simon: HTML5 dierences from HTML4. http://www.w3.org/TR/html5-diff/, May 2011. Working Draft [Kr11a] Krner, Peter: Gastartikel: HTML5 im berblick. http://blogs.technet.com/b/sieben/archive/2011/03/09/ gastartikel-html5-im-220-berblick.aspx, Mrz 2011 [Kr11b] Krner, Peter: HTML5 Webseiten innovativ und zukunftssicher. 2. Auage. Mnchen : Open Source Press, 2011. http://html5-buch.de [Mah11a] Mahemoff, Michael: HTML5 vs Native: The Mobile App Debate. http: //www.html5rocks.com/en/mobile/nativedebate.html, Juni 2011 [Mah11b] Mahemoff, Michael: Oine: What does it mean and why should I care? http://www.html5rocks.com/en/tutorials/offline/ whats-offline/, October 2011
78
[Mic11] Microsoft: Location and my privacy FAQ. http: //www.microsoft.com/windowsphone/en-US/howto/wp7/web/ location-and-my-privacy.aspx, 2011 [Moz11] Mozilla: Standortbezogenes Surfen. http://www.mozilla.org/de/ firefox/geolocation/, 2011 [MSG+ 11] Mehta, Nikunj ; Sicking, Jonas ; Graff, Eliot ; Popescu, Andrei ; Orlow, Jeremy: Indexed Database API. http://www.w3.org/TR/ IndexedDB/, April 2011. Working Draft [Net10] Netherland, Wynn: Episode 0.2.6 - Douglas Crockford on JSON and JavaScript from TXJS. http://thechangelog.com/post/676820023/ episode-0-2-6-douglas-crockford-on-json-and-javascript-f, Juni 2010. Interview [OP11] Offermann, Stefan ; Puccinelli, Susan: Adobe Announces Adobe Flash Media Server 4.5 and Adobe Flash Access 3.0. http://eon.businesswire.com/news/eon/20110907007466/en/ Adobe/IBC/Flash-Media-Server, September 2011. Pressemitteilung [Pop10] Popescu, Andrei: Geolocation API Specication. http://www.w3.org/ TR/geolocation-API/, September 2010. W3C Candidate Recommendation [Rag93] Raggett, David: A Review of the HTML+ Document Format. http:// www.w3.org/MarkUp/htmlplus_paper/htmlplus.html, November 1993 [Ref11] Refsnes Data: w3schools.com - HTML5 Tutorial. w3schools.com/html5/, 2011 http://www.
[RP98] Raggett, Dave ; Pemberton, Steven: Shaping the Future of HTML. http://www.w3.org/MarkUp/future/, Mai 1998 [RS11] Ranganathan, Arun ; Sicking, Jonas: File API. http://www.w3. org/TR/FileAPI/, Oktober 2011. Working Draft [Smi11a] Smith, Michael[tm]: HTML: The Markup Language. http://www.w3. org/TR/html-markup/, Mai 2011. Working Draft [Smi11b] Smith, Mike: History - HTML WG Wiki. http://www.w3.org/html/ wg/wiki/History, Juni 2011 [Str11] Streit, Alexander von: Apple iPhone und iPad berwachen ihre Besitzer. http://www.focus.de/digital/handy/iphone/ apple-iphone-und-ipad-ueberwachen-ihre-besitzer_aid_620315. html, April 2011 [Uhr11a] Uhrhane, Eric: File API: Directories and System. http://www.w3. org/TR/file-system-api/, April 2011. Working Draft
79
[Uhr11b] Uhrhane, Eric: File API: Writer. http://www.w3.org/TR/ file-writer-api/, April 2011. Working Draft [W3C09] W3C: XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5. http://www.w3.org/News/ 2009#entry-6601, Juli 2009 [WHAa] WHATWG: Dierences Between HTML and XHTML. http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_ Between_HTML_and_XHTML, [WHAb] WHATWG: What are the various versions of the spec? http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_ versions_of_the_spec.3F, [WHAc] WHATWG: What is HTML5? http://wiki.whatwg.org/wiki/FAQ# What_is_HTML5.3F, [Win11] Winokur, Danny: Flash to Focus on PC Browsing and Mobile Apps; Adobe to More Aggressively Contribute to HTML5. http://blogs.adobe. com/conversations/2011/11/flash-focus.html, November 2011 [Zei11] Zeigler, Andy: W3C Geolocation API in IE9. http://blogs.msdn. com/b/ie/archive/2011/02/17/w3c-geolocation-api-in-ie9. aspx, Februar 2011. Program Manager, Internet Explorer
80
Anhang
81
A Optionale Tags der HTML5-Syntax

Element html head body li dt dd p rt rp optgroup option colgroup thead tbody tfoot tr td th Start-Tag optional optional optional required required required required required required required required optional required optional required required required required End-Tag optional optional optional optional optional optional optional optional optional optional optional optional optional optional optional optional optional optional
Tabelle A.1: Optionale Tags beim Verwenden der HTML5-Syntax(Quelle: [Hic11a, 13.1.2.4 Optional tags])
82
Abbildungsverzeichnis
2.1 2.2 2.3 3.1 4.1 4.2 6.1 7.1 8.1 8.2 8.3 8.4 9.1 bersicht ber die aktuellen spirit@fhs Teilprojekte (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Screenshot der Single-Ansicht einer News mit Kommentaren . . . . . Vergleich alter statischer und neuer dynamischer Stundenplan . . . . 4 6 7
bersicht ber das HTML5-Universum (Quelle: [Kr11b, S. 34]) . . . 13 Aufbereiteter Screenshot der Financial Times Deutschland Startseite (Quelle: Eigene Darstellung) . . . . . . . . . . . . . . . . . . . . . . . 19 Content-Modelle in HTML5 (Quelle: [Hic11a, 3.2.5.1 Kinds of content]) 29 Vergleich der <keygen> Implementierungen . . . . . . . . . . . . . . . 39 Screenshot des Player-Prototypen . . . . . . . . . . . . . . . . . . . . 47 Screenshot des Prototypen . . . . . . . . . . . . . . . . . . . . . Screenshot eines zweiten Prototypen . . . . . . . . . . . . . . . Screenshot von RGraph Diagrammen (Quelle: www.rgraph.net) Screenshots zweier Canvas Animationen . . . . . . . . . . . . . . . . . . . . . . . . . 52 55 56 57
Screenshot einer Chrome Benachrichtigung . . . . . . . . . . . . . . . 63
10.1 App-Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 10.2 Screenshots der Spirit App . . . . . . . . . . . . . . . . . . . . . . . . 70
83
Tabellenverzeichnis
7.1 Browseruntersttzung der Formate (in Anlehnung an:[Kr11b, S. 273] und [Ref11]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1 Optionale Tags beim Verwenden der HTML5-Syntax(Quelle: [Hic11a, 13.1.2.4 Optional tags]) . . . . . . . . . . . . . . . . . . . . . . . . . . 82
84
Listings
3.1 3.2 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 5.1 5.2 5.3 5.4 6.1 6.2 6.3 7.1 7.2 7.3 7.4 7.5 7.6 8.1 8.2 8.3 Beispiel eines gltigen SGML-Dokuments. . . . . . . . . . . . . . . . Das HTML-Pendant. . . . . . . . . . . . . . . . . . . . . . . . . . . . Gltige HTML5 Doctypes . . . . . . . . . . . . . . . . . . . . . HTML 4.01 Doctype . . . . . . . . . . . . . . . . . . . . . . . . Mgliche Content-Types . . . . . . . . . . . . . . . . . . . . . . Ein gltiges XHTML5-Dokument . . . . . . . . . . . . . . . . . Ein gltiges HTML5-Dokument . . . . . . . . . . . . . . . . . . Ein gltiges HTML5-Dokument im XHTML-Stil . . . . . . . . . Quelltextauszug einer Teaserbox der Seite http://www.ftd.de/ Mglicher HTML5-Aufbau einer Teaserbox . . . . . . . . . . . . Gliederung nach HTML4 . . . . . . . . . . . . . . . . . . . . . . Gliederung mit HTML5 . . . . . . . . . . . . . . . . . . . . . . Beispielhafter Aufbau einer Webseite . . . . . . . . . . . . . . . Auszeichnung eines Grndungsdatums . . . . . . . . . . . . . . Auszeichnung eines Grndungsdatums mit Microdata . . . . . . Nutzung des Microdata-Organisationsschemas . . . . . . . . . . Formular mit Pichtfeld . . . . . . . . . . . . . . . . . . . . . . Barrierefreie Verwendung von Tabs . . . . . . . . . . . . . . . . Beispiel einer MathML-Struktur fr ein HTML5-Dokument . . . Verfgbarkeitscheck Der Erfolgsfall . . . Der Fehlerfall . . . Die Einstellungen . und Positionsanfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9 15 15 16 16 17 17 20 22 23 23 23 25 25 26 28 28 30 35 36 36 36
Verwendung des Elements <datalist> . . . . . . . . . . . . . . . . . 38 Zwei neue Attribute im Einsatz . . . . . . . . . . . . . . . . . . . . . 39 Zwei neue Attribute im Einsatz. . . . . . . . . . . . . . . . . . . . . . 40 Verwendung des <source>-Elements Untertitel fr ein Video . . . . . . . . HTML-Grundgerst des Prototypen . Videolaufzeit ermitteln . . . . . . . . Die Funktionalitt des Play-Buttons Stummschaltung des Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 44 47 48 48 49
HTML-Grundgerst . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Denition der Eekte als Objekt . . . . . . . . . . . . . . . . . . . . . 53 Erzeugen eines nicht sichtbaren Canvas . . . . . . . . . . . . . . . . . 54
85
Listings 8.4 8.5 9.1 9.2 9.3 9.4 9.5 9.6 10.1 10.2 10.3 10.4
Fachhochschule Schmalkalden WS 2011/12 HTML-Elemente mit Events versehen . . . . . . . . . . . . . . . . . . 54 Die Zeichenfunktion des Prototypen . . . . . . . . . . . . . . . . . . . 55 Mglicher Manifest-Aufbau . . . . . . . . Beispiel des Cross-Document Messagings Erstellen einer Web Socket Verbindung . Erstellen einer EventSource . . . . . . . Benachrichtigung mit Chrome . . . . . . Erstellung der Worker . . . . . . . . . . Android Activity in Java . . . . . . . . HTML-Struktur der App . . . . . . . . Initialisierung der App . . . . . . . . . Abrufen der News ber REST oder den . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 61 62 62 63 65 70 71 72 72
. . . . . . . . . . . . . . . . . . . . . . . . localStorage
86
Eidesstattliche Erklrung
Ich versichere an Eides Statt durch meine eigenhndige Unterschrift, dass ich die vorliegende Arbeit selbststndig und ohne fremde Hilfe angefertigt habe. Alle Stellen, die wrtlich oder dem Sinn nach auf Publikationen oder Vortrgen anderer Autoren beruhen, sind als solche kenntlich gemacht. Ich versichere auerdem, dass ich keine andere als die angegebene Literatur verwendet habe. Diese Versicherung bezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichen Darstellungen und dergleichen. Die Arbeit wurde bisher keiner anderen Prfungsbehrde vorgelegt und auch noch nicht verentlicht.
Schmalkalden, den 6. Dezember 2011

Ort, Datum Florian Schuhmann B. Sc.
87

HTML5 - DerzeitigeLeistungsfähigkeit Und Möglichkeitenin Bezug Auf Aktuelle Browser Undmobile Endgeräte

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HTML5 - DerzeitigeLeistungsfähigkeit Und Möglichkeitenin Bezug Auf Aktuelle Browser Undmobile Endgeräte

Uploaded by

Copyright:

Available Formats

Masterarbeit

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Weitere Mglichkeiten der Inhaltseinbindung . . . . . . . . . . . . . . 49 50 50 51 52 56 58 58 58 59 60 60 61 61 62 63 64 67 67 67 68 69

Florian Schuhmann B. Sc.

[Bra10, S. 103] Siehe http://cloud9ide.com/ oder http://ace.ajax.org/

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

2 Das Projekt spirit@fhs

2.1 Was ist spirit@fhs?

Florian Schuhmann B. Sc.

2. Das Projekt spirit@fhs

Fachhochschule Schmalkalden WS 2011/12

) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

F11 F12 F9 F10 +

Scroll Lock PrintScrn SysRq

PageUp Delete End

) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

F11 F12 F9 F10 +

Scroll Lock PrintScrn SysRq

PageUp Delete End

) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M <, > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X

F11 F12 F9 F10 +

Scroll Lock PrintScrn SysRq

PageUp Delete End

Florian Schuhmann B. Sc.

2. Das Projekt spirit@fhs

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

2. Das Projekt spirit@fhs

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

2. Das Projekt spirit@fhs

Fachhochschule Schmalkalden WS 2011/12

(a) alter Stundenplan

(b) neuer Stundenplan

Der angepasste Quellcode ist hier zu nden: https://github.com/FlorianX/fullcalendar

Florian Schuhmann B. Sc.

3.1 Die Entwicklungsgeschichte von HTML

Die Europische Organisation fr Kernforschung. Vgl. [BL89]

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

3.2 Die Idee des Neuanfangs mit XHTML

http://www.w3.org/TR/html401/ [RP98] 12 http://www.w3.org/TR/xhtml1/ 13 http://www.w3.org/TR/xhtml11/ 14 http://www.w3.org/TR/xhtml2/

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

3.3 Das neue Zugpferd: HTML5

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12

Florian Schuhmann B. Sc.

Fachhochschule Schmalkalden WS 2011/12