Eigentlich lernen wir nur von den Büchern, die wir nicht beurteilen können. Der Autor eines Buches, das wir beurteilen könnten, müßte von uns lernen.
Johann Wolfgang von Goethe
Erstellt: 2013-10-01/16 2015-07-05/07 2018-06-09
Inhaltsdokumente werden in EPUB 3 im Format SVG 1.1 oder in XHTML erstellt, wobei für letzteres einer der Arbeitsentwürfe für HTML5 [HTML5] verwendet wird,
welcher das ist, ist allerdings nicht näher festgelegt, noch wie man präzise als Autor angibt, welchem Arbeitsentwurf man aktuell folgt.
Die Erläuterungen hier folgen dem Arbeitsentwurf von 2013-08-06.
Für dauerhafte Inhalte von Büchern ist eine Version, die lediglich aus Arbeitsentwürfen besteht und nicht aus einer Empfehlung natürlich eigentlich keine besonders gute Wahl.
EPUB 2 verwendet dagegen eine stabile Version von XHTML.
Immerhin, 2014-10-28 ist die Empfehlung zu HTML5 veröffentlicht worden, also deutlich nach
EPUB 3, die eine Empfehlung von 2011 ist.
Version 3.0.1 ist 2014-06 herausgekommen.
Version 3.0.1 und HTML5 in der Version 5.0 passen also ganz gut zusammen.
Warum mit der Spezifikation von EPUB 3.0.1 nicht auf HTML5 in der Version 5.0 gewartet wurde, bleibt sehr rätselhaft.
In den folgenden Jahren kamen weitere Versionen von HTML5 heraus, die formal noch nicht zu EPUB 3.0.1 passen, allerdings auch keine großen Unterschiede aufweisen.
Insgesamt hat sich die Situation um HTML5 in EPUB mittlerweile allerdings wohl definitiv stabilisiert.
Da sollte es nun keine Bedenken mehr geben umzusteigen.
Je nach der Komplexität des Inhaltes eines Buches kann ein Autor mit wenigen Elementen aus dieser Kollektion auskommen oder aber auch darin viele für das Buch relevante Strukturen schmerzlich vermissen. HTML5 selbst bietet keine Elementkollektion, die besonders für die Struktur von Büchern geeignet ist, daher sind diverse Strukturen, die in HTML5 neu definiert werden, für Inhalte von Büchern im Format EPUB 3 ziemlich belanglos. Einige in HTML5 erlaubte Verschachtelungen von Elementen führen zu einer schlechten Struktur, die sich kundige Autoren aber leicht ersparen können, indem sie sich auf ebenfalls erlaubte, strengere Strukturen beschränken. In diesem Sinne wird im Folgenden kurz vorgestellt, was in HTML5 für EPUB 3 relevant ist, um gut strukturierte Dokumente, beziehungsweise Bücher zu schreiben.
Explizit betont sei noch einmal, daß das HTML5, welches für EPUB 3 relevant ist, die XML-Variante dieses Formates ist, nicht die Markierungssuppen-Variante, die anderweitig häufiger erklärt wird und deutlich komplexer ist. Es handelt sich daher immer um eine Variante von XHTML, welche den allgemeinen Regeln für XML-Dokumente folgt.
Jegliche Varianten von XHTML-Dokumenten haben dieselbe Grundstruktur. Der Namensraum von XHTML ist 'xmlns="http://www.w3.org/1999/xhtml"'. Ferner bietet es sich an, ebenfalls einen Präfix für einige Erweiterungen von EPUB 3 zu definieren, also etwa mit folgender Namensraumangabe: 'xmlns:ops="http://www.idpf.org/2007/ops"'. Das Wurzelelement heißt aus historischen Gründen html. Es empfiehlt sich hier, die genannten Namensräume für das gesamte Dokument festzulegen, zusätzlich bei einsprachigen Dokumenten mit dem Attribut xml:lang die verwendete Sprache, bei deutschprachigen also xml:lang="'de".
Der Inhalt von html besteht aus exakt zwei Elementen. Als erstes ist das Element head zu notieren. Darin werden nicht direkt als normale Inhalte präsentierte Metainformationen zum Dokument notiert. Das zweite Element ist body, in welchem die als normaler Inhalt zu präsentierenden Bestandteile des Dokumentes notiert werden.
head enthält ein Element title mit dem Titel des Dokumentes als
einfachem Textinhalt. Weitere optionale inhaltsleere Elemente in beliebiger Anzahl sind unter anderem
meta und link.
meta dient dazu, Metainformationen über das aktuelle Dokumente zu notieren.
Mit link wird auf zum Dokumente gehörige oder damit verbundene Ressourcen verwiesen, etwa
auf Stilvorlagen oder andere Dokumente.
body enthält den normalen Inhalt des Dokumentes. Im Sinne einer guten Struktur sind dies Blockelemente, meist begonnen mit einer primären Überschrift mit dem Element h1.
Damit ergibt sich folgende minimale Grundstruktur:
<?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ops="http://www.idpf.org/2007/ops" xml:lang="de"> <head> <title> ... <!-- Dokumenttitel --></title> </head> <body> <!-- normaler Inhalt --> </body> </html>
Oft wird es bei einfachen Büchern etwa aus dem Bereich der Belletristik ausreichen, den weiteren Inhalt eines Inhaltsdokumentes nach der Kapitelüberschrift lediglich mit Absätzen zu strukturieren. Ein Absatz ist ein abgeschlossener Gedankengang und wird umschlossen von einem Element p. Sinnvoller Inhalt davon ist technisch gesehen für eine gute Struktur lediglich einfacher Text und Phrasenelemente. Die wichtigsten davon für Bücher sind vermutlich em für betonten Text und strong für besonders wichtigen Text. Deren Inhalte sind wiederum Text und Phrasenelemente.
Bei dieser einfachen Struktur wird man für ein Kapitel jeweils ein Inhaltsdokument verwenden. Diese Struktur ist nicht spezifisch für eine bestimmte Version von XHTML und kann so auch anderweitig verwendet werden, etwa für Inhaltsdokumente gemäß EPUB 2.
Folgendes ist ein komplettes Beispiel:
<?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de"> <head> <title>Dokumenttitel</title> </head> <body> <h1>Kapitelüberschrift</h1> <p> Ein Absatz wird pro abgeschlossenem Gedankengang verwendet. Ein Absatz umfaßt oft mehrere Sätze. </p> <p> Dies repräsentiert einen weiteren Absatz. </p> <p> ... </p> </body> </html>
Nur in seltenen Fällen wird man statt p das Element pre verwenden müssen, bei welchem mehrere aufeinander folgende Leerzeichen nicht zusammengeschnurrt werden, also auch Zeilenumbrüche wie im Quelltext notiert präsentiert werden. Einen automatischen Zeilenumbruch gibt es dafür bei pre nicht.
Werden in einem Dokument mehrere Unterkaptitel oder auch mehrere Kapitel untergebracht, so empfiehlt sich eine weitere, übergeordnete Struktur von Blockelementen, für welche HTML5 ein paar neue Elemente bietet und EPUB 3 zudem mit einer Erweiterung die Möglichkeit bietet, die semantische Bedeutung dieser Elemente genauer festzulegen.
Relevant für Kapitelstrukturen ist vor allem das neue Blockelement section. Hier bietet es sich dann an, das jeweilige Kapitel, beziehungsweise Unterkapitel mit einem solchen Element zu umschließen. Gemäß den Präsentationsvorschlägen für HTML5 ergibt sich aus der Verwendung solcher neuer Elemente leider zumeist keine weitere sichtbare Strukturierung, im Bedarfsfalle müssen Autoren hier also mit eigenen Angaben in der Stilvorlage, etwa mit Außen- oder Innenabständen oder Rahmen, nachhelfen.
Wird zum Beispiel das Konzept verfolgt, in einem Inhaltsdokument den gesamten Inhalt des Buches
unterzubringen, so bietet es sich also an, die Kapitelstruktur mit dem Element
section umzusetzen. Die Überschrift des Werkes wäre dann etwa im
h1 zu notieren, weitere Kindelemente von body
sind dann nur noch Elemente section. Ein solches beginnt dann mit
der Kapitelüberschrift in einem h2 gefolgt von Absätzen oder für
Unterkapitel weiteren Elementen section mit Überschriften vom Typ
h3 etc. Mit dem von EPUB 3 eingeführten Attribut
type kann dann genauer angegeben werden, welche Funktion das jeweilige Element
im Buch hat. Bei Bedarf kann natürlich noch weiter unterteilt werden, Überschriften gibt es
zumindest bis h6, was in den meisten Fällen reichen dürfte.
Man beachte dabei, daß das früher einmal definierte Element hgroup
im Arbeitsentwurf von 2013-08-06 gestrichen wurde und hier nicht weiter erläutert wird.
Sinngemäß sieht dann ein Dokument mit Kapiteln und Unterkapiteln wie folgt aus:
<?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ops="http://www.idpf.org/2007/ops" xml:lang="de"> <head> <title>Buchtitel</title> </head> <body> <h1 ops:type="title">Buchtitel</h1> <section ops:type="chapter"> <h2>Titel des ersten Kapitels</h2> <p> Ein Absatz wird pro abgeschlossenem Gedankengang verwendet. Ein Absatz umfaßt oft mehrere Sätze. </p> <p> Dies repräsentiert einen weiteren Absatz. </p> <section ops:type="subchapter"> <h2>Titel des ersten Unterkapitels</h2> <p> ... </p> </section> <section ops:type="subchapter"> <h2>Titel des zweiten Unterkapitels</h2> <p> ... </p> </section> <p> ... </p> </section> <section ops:type="chapter"> <h2>Titel des zweiten Kapitels</h2> <p> ... </p> </section> <section ops:type="chapter"> <h2>Titel des dritten Kapitels</h2> <p> ... </p> </section> </body> </html>
Im Sinne von HTML5 sind auch Vorwort, Nachwort, Literaturverzeichnis, Glossar etc lediglich Abschnitte eines Werkes, welche mit section umschlossen werden sollten. Für solch speziellere Strukturen bietet es sich natürlich wieder das Attribut type von EPUB 3 an, um solche Strukturen präziser zu kennzeichnen.
Das bereits in früheren Versionen definierte inhaltsleere Blockelement hr kann ferner als präsentierter Separator zwischen Blockelementen wie Kapiteln dienen. Etwa ist es bei Büchern ja oftmals üblich, das Ende eines Kapitels mit einem besonderen Zeichen zu kennzeichnen - insbesondere, falls die Kapitel keine Überschriften haben. Per Stilvorlage kann das Aussehen des Elementes dann den Vorstellungen des Autors angepaßt werden.
Wie gehabt kann das Blockelement div verwendet werden, wenn kein anderes Element zur semantischen Bedeutung paßt.
Bei Sammlungen, Anthologien und ähnlichen Zusammenstellungen von eigenständigen Artikeln oder Werken zu einem Gesamtwerk wird man in der Regel pro Werk mindestens ein Inhaltsdokument spendieren. Bei eher kurzen Artikeln kann es hingegen auch sinnvoll sein, mehrere davon in einem Inhaltsdokument zusammenzufassen. Dazu bietet sich das in HTML5 neu eingeführte Element article an. Jedes eigenständige Werk wird dann von solch einem Element umschlossen, sofern eben mehrere in einem Dokument auftreten.
Handelt es sich hingegen bei den einzelnen Werken eher um Zitate, die im Gesamtwerk benötigt
und diskutiert werden, so ist das bereits in früheren Versionen definierte Element
blockquote der passende Kandidat, mit welchem solch ein Zitat umschlossen
und als solches kenntlich gemacht wird. Mit dem Attribut cite kann
dann etwa ein Phrasenelement cite referenziert werden, in welchem
die Quellenangabe zu Zitat angegeben ist. cite wird genauer im Abschnitt
über Phrasenelemente erläutert.
Anders als in früheren Versionen sieht HTML5 nicht nur Blockelemente als Inhalt
vor. Auch Text und Phrasenelemente können (stattdessen) als sinnvoller Inhalt notiert werden.
Insbesondere bei eigenständigen Artikeln sollte natürlich eine eindeutige Zuordnung zu den verantwortlichen Autoren auch nicht fehlen. Dies kann im article mit dem bereits aus früheren Versionen gut bekannten address erfolgen. Hier gilt die Autorenangabe dann eben nur für den Artikel. Außerhalb von article notiert, gilt sie wie gehabt für das ganze Dokument.
Insbesondere bei address, aber auch bei normalen Absätzen, die eine Adressangabe enthalten, sind manuelle Zeilenumbrüche wichtig. Dazu dient das inhaltsleere Element br wie bereits in früheren Versionen definiert. Ansonsten gibt es eher wenige Anwendungen für br, allenfalls noch als kurze Gedankenpause innerhalb eines Absatzes.
Die Behauptung in den Arbeitsentwürfen zu HTML5, br wäre irgendwie nützlich für Zeilen in Gedichten, zeigt allenfalls, daß entweder die Strukturen von Gedichten und Strophen nicht verstanden worden sind oder ignoriert wird, daß br inhaltsleer ist, also insbesondere auch keine Zeile eines Gedichtes enthalten kann, noch kann es Strophen voneinander separieren. Richtig ist vielmehr, daß (X)HTML gar keine semantisch brauchbaren Elemente für Gedichte, Liedtexte, Strophen, Poesie etc aufweist. Es ist also am besten das allgemeine Element div zur Strukturierung in Strophenzeilen zu verwenden und das Element section jeweils für eine Strophe mit den Zeilen darin. Zur Kennzeichnung der semantischen Bedeutung kann das Attribut type von EPUB 3 zu verwenden bei Strophe und Strophenzeile notiert werden.
Abschnitte eines Dokumentes, die nicht direkt im normalen Fluß des Inhaltes stehen, sondern Hilfen oder Zusatzinformationen dazu anbieten, etwa auch Übungsaufgaben oder Beispiele, können sinnvoll in einem neu eingeführten Blockelement aside untergebracht werden. Zugunsten der Lesbarkeit und Verständlichkeit für den Leser sollten hingegen Informationen, die gar nichts mit dem normalen Fluß des Inhaltes zu tun haben, gar nicht untergebracht werden, wodurch sich praktisch automatisch ergibt, daß auch die Informationen, die in aside notiert sind, zumindest indirekt Bezug auf den sonstigen Inhalt haben. Die Struktur des Inhaltes richtet sich auch hier wieder danach, um was es in einer solchen Randnotiz geht, sinnvoll ist es auch hier wieder, sich zu entscheiden, ob der Inhalt aus Blockelementen einerseits oder aus Textinhalt oder Phrasenelementen andererseits besteht.
HTML5 bietet auch neue Elemente für Kopf- und Fußbereiche von Dokumenten, Artikeln, Kapiteln, Abschnitten etc an. Dies ist header für einen Kopfbereich und footer für einen Fußbereich. Der Hauptteil einer Struktur kann schlicht mit dem neuen Element main gekennzeichnet werden.
main darf allerdings nicht Nachfahre folgender Elemente sein:
article, aside, footer, header oder nav. Der Inhalt eines Elementes
main ist ferner als einzigartig innerhalb eines Projektes aufzufassen,
beinhaltet also ausdrücklich nicht sich wiederholende Bestandteile wie Logos, Kopf- und Fußbereiche,
die Navigation etc. Das Element ist insbesondere nützlich für Vorleseprogramme, welche damit
zügiger sich wiederholende Inhalte überspringen können, um beim Vorlesen direkt auf den Punkt,
also zum eigentlichen Inhalt der Seite zu kommen.
header und footer wiederum dürfen keine Elemente
header, footer oder main
enthalten. Ansonsten besteht sinnvoller Inhalt entweder aus Blockelementen einerseits oder
Text oder Phrasenelementen andererseits.
Bei Büchern sind solche Strukturen eher unüblich, auch weil sie für das gesamte Elternelement gelten und nicht etwa bei Seitenmedien für eine Präsentation auf jeder Seite oben und unten gedacht sind - die Benennung impliziert also keine besondere Positionierung bei einer Präsentation, gleichwohl legt der Name nahe, wo das jeweilige Element in der Reihenfolge der Inhalte eines Elternelementes im Quelltext auftreten sollte. Bei einem Buch wird man Strukturen, die den Buchkopf oder -fuß und die Navigation eher in eigenen Dokumenten verfügbar machen, statt sie in jedem Dokument erneut einzubinden, wie dies bei Projekten im Netz üblich ist, weil dort bislang die Möglichkeit nicht kultiviert wurde, ein Projekt als zusammengehörige Entität kenntlich zu machen, die aus mehreren Dokumenten bestehen kann. Hier zeigt sich einmal mehr, daß HTML5 eine etwas eigenartige Wahl eines Formates bezogen auf Inhaltsdokumente von Büchern ist, weil diese Sprachversion gar nicht dafür ausgelegt ist.
Eine neue Elementkombination von HTML5 füllt eine Lücke in vorherigen Versionen, wo es nicht möglich war, Abbildungen insbesondere mit eigener Abbildungsbeschriftung als eigenständige Blockelemente zu notieren. Nicht nur für Abbildungen, sondern auch für andere, selbständige Strukturen führt HTML5 das Blockelement figure neu ein. Hinsichtlich des Inhaltes kann hier gewählt werden, ob man erst die Abbildungsbeschriftung notieren will und dann den Gegenstand der Beschriftung oder umgedreht. Die Beschriftung ist optional und ist im Bedarfsfalle im Element figcaption zu notieren. Entweder davor oder danach steht der so beschriftete Inhalt. Bei der Struktur sollte man auch hier wieder konsequent bleiben, also entweder man faßt alles als Blockelemente auf oder als Text oder Phrasenelemente.
Einfaches Beispiel mit Beschriftung vor einem Bild (die Textalternative zum Bild kann hier leer bleiben, weil bereits die Bildbeschriftung als Alternative dient):
<figure> <figcaption>Rainer Wahn hängt am Bahnhofs-Ernst-August im eigenen Gestrickten ab.</figcaption> <img alt="" src="raineramernstaugust.jpg" width="800" height="600" /> </figure>
Einfaches Beispiel mit Beschriftung nach dem Bild:
<figure> <object data="HannoverStrick01.svg" width="800" height="800" /> <figcaption> Übersichtskarte Hannover Innenstadt unter besonderer Berücksichtigung der zentralen Szenetreffs der hannöverschen Strickgraffiti-Subkultur. </figcaption> </figure>
Statt img und object können wie erwähnt auch andere Elemente beschriftet werden, etwa:
<figure> <h1>Freundesliste</h1> <ul> <li>Maria</li> <li>Petra</li> <li>Florian</li> <li>Mareike</li> <li>Jens</li> <li>Ebru</li> <li>Ayse</li> <li>Vasili</li> <li>Vroni</li> </ul> <h1>Liste von Gegnern</h1> <ul> <li>Bernd</li> <li>Yusuff</li> <li>Ibrahim</li> <li>Werner</li> <li>Paula</li> <li>Yvonne</li> <li>Marcello</li> <li>Sasha</li> <li>Cameron</li> </ul> <h1>Neutrale Liste</h1> <ul> <li>Florentine</li> <li>Bertine</li> <li>Bruno</li> <li>Anna</li> <li>Mohamed</li> </ul> <p><img alt="Soziogramm von Hannahs Schulklasse" src="soziogramm_hannah.svg" /></p> <figcaption>Hannahs soziales Umfeld in ihrer Schulklasse</figcaption> </figure>
Angeordnete Listen mit ol und nicht angeordnete Listen mit ul
bleiben in HTML5 gegenüber den vorherigen Versionen zum großen Teil unverändert.
Es kommt allerdings bei ol ein neues Attribut hinzu und zwei bereits früher gestrichene werden reanimiert.
Mit reversed wird für ol die Reihenfolge der
Numerierung geändert, also umgedreht. Normal ohne Attribut ist von kleiner Zahl zu großer Zahl,
umgedreht geht von großer Zahl zu kleiner. Der Attributwert ist entweder leer oder 'reversed'.
Mittels start kann angegeben werden, mit welcher Zahl die Zählung beginnen
soll. Der Wert ist eine ganze Zahl. Sofern nicht angegeben, wird mit 1 begonnen.
Mittels type wird der Typ der Numerierung angegeben. Es gibt folgende Werte:
Achtung: da die Römer die 0 nicht kannten, kann es damit und auch bei negativen Zahlen zu Problemen kommen, was man durch geeignetes Setzen von start provozieren oder vermeiden kann. Insbesondere beim Rückwärtszählen ist hier der Startwert demgemäß passend festzulegen, der sonst ebenfalls bei 1 oder hier I oder i beginnt. Der zweite Listenpunkt bekommt dann also die Nummer 0, der dritte -1.
Eine kleine Veränderung gibt es auch bei Definitionslisten dl. Die Bedeutung ist nunmehr genauer festgelegt, was die Verwendung etwas einschränkt, aber auch genauer festlegt, wie Terme und definierender Inhalt zusammengehören. Etwa ist es nun nicht mehr möglich, den definierenden Inhalt vor dem Term zu notieren. Stärkere Einschränkungen in den Entwürfen der ersten Jahre wurden in späteren Entwürfen allerdings wieder zurückgenommen.
Man beachte, daß das in einigen Arbeitsentwürfen reanimierte und umdefinierte alte Attribut menu im Arbeitsentwurf von 2013-08-06 gestrichen ist.
Die wesentliche Änderung bei Tabellen ist, daß die Attribute summary, rules, frame, axis, scope (für td) nicht länger zulässig sind. Um eine solche Zusammenfassung für eine Tabelle anzugeben, bietet es sich nun also an, diese in einem Element figure zu notieren und die Zusammenfassung als Beschriftung im Element figcaption. Auch einige andere Zugänglichkeitshilfen und Lesbarkeitshilfen sind gestrichen oder in der Nutzung eingeschränkt, was dann auch allenfalls durch eine entsprechend längere Beschriftung ansatzweise aufgefangen werden kann.
Auch die Attribute width, cellpadding, cellspacing, align, valign, char, charoff, sind gestrichen. Diese Lesbarkeitshilfen können allenfalls noch ersatzweise mit CSS angeboten werden, sofern dessen Interpretation verfügbar und aktiviert ist.
Hinsichtlich der Phrasenelemente gibt es in HTML5 auch zahlreiche Änderungen, wobei sowohl Elemente gestrichen wurden als auch bereits gestrichene wieder reanimiert wurden. Einige neue gibt es auch. Ferner wurde die Bedeutung einiger Elemente verändert oder eingeschränkt, daher lohnt es sich, die verfügbare Kollektion durchzugehen, um zu wissen, was man auszeichnen kann und was nicht mehr.
Gestrichen wurden die Elemente acronym (stattdessen auf abbr ausweichen), big (kein inhaltlich relevanter Ersatz), tt (kein inhaltlich relevanter Ersatz).
Verweise werden wie gehabt mit dem Element a gekennzeichnet. Neben den bekannten, für das Element spezifischen Attributen href für die Angabe des Verweiszieles, hreflang für einen Hinweis auf die Sprache des Verweiszieles, rel für die Angabe einer Relation, type für den Medientyp des Verweiszieles gibt es ein neues Attribut download und das in einigen Versionen nicht verfügbare target.
rev ist ohne Ersatz gestrichen, ebenso charset und name und Attribute für verweissensitive Graphiken.
Mit download kann angegeben werden, daß das Verweisziel nicht dargestellt, sondern zum Abspeichern angeboten werden soll. Der Wert ist entweder leer oder ein Vorschlag für den Dateinamen beim Abspeichern.
Zur Hervorhebung im Sinne einer Betonung wird wie gehabt das Element em verwendet. Ebenfalls wie gehabt gibt es kein Element, mit welchem man die Betonung wieder auf ein normales Niveau zurücknehmen kann oder gar etwas als gezielt unbetont kennzeichnen kann. Stärker betonen kann man mit verschachtelten Elementen em, was allerdings nicht unbedingt zu einer anderen Präsentation führt als ein einzelnes em.
strong hingegen wird umdefiniert und kennzeichnet nicht mehr eine starke Hervorhebung oder Betonung, wozu auch der Name des Elementes besser paßt, sondern kennzeichnet nun etwas als wichtig. Auch hier gibt es kein Element, welches etwas als unwichtig kennzeichnen könnte. Wenn etwas sehr wichtig ist, kann wieder verschachtelt werden, was allerdings auch nicht unbedingt zu einer anderen Präsentation führt als ein einzelnes strong.
Auch small ist komplett umdefiniert worden. Während es früher kennzeichnete, daß es inhaltlich relevant ist, daß etwas kleiner dargestellt wird als normal, was mit dem gestrichenen big wieder rückgängig gemacht werden konnte, kennzeichnet es nunmehr Kommentare, Randnotizen oder das sprichwörtlich Kleingedruckte. Diese Änderung von HTML5 ist allerdings sehr umstritten und wird oft als unsinnig kritisiert. Denn in digitalen Dokumenten gibt es keine Notwendigkeit, Passagen absichtlich schlechter lesbar zu machen - im Gegenteil, bei gedruckten Werken weist das Kleingedruckte meist darauf hin, daß etwas Wichtiges vor dem Leser verborgen werden soll. Das ist inhaltlich schlecht und sollte in anständigen Dokumenten gar nicht auftreten. Hingegen gibt es beim Setzen von Formeln oder Symbolen durchaus die Notwendigkeit, etwas explizit als kleiner dargestellt zu kennzeichnen, ebenso wie als größer dargestellt zu kennzeichnen. Auch die Verwendung von small für Teile einer Überschrift, die damit als Untertitel gekennzeichnet wird, ist damit praktisch ausgeschlossen - es gibt in HTML5 keine sinnvolle Möglichkeit, solche Untertitel gezielt zu kennzeichnen.
Aufgrund dieses Durcheinanders sollte vielleicht auf das Element small besser komplett verzichtet werden. Für Formeln und Symbole ist dann MathML zu verwenden.
Andererseits gibt es in HTML5 auch immer mal wieder Passagen, wo dazu aufgerufen wird, Bestandteile anderer Spezifikationen gezielt zu ignorieren, die die Autoren von HTML5 als nicht sinnvoll empfinden. In diesem Sinne dürfen Autoren sicherlich auch die unsinnige Umdefinition von small einfach ignorieren. Im Bedarfsfalle kann ja mit dem Attribut type von EPUB 3 angegeben werden, was die genaue Bedeutung ist.
Neu ist das Element mark für eine Hervorhebung im Sinne eines Glanzpunktes, bei graphischer Darstellung typisch andersfarbig unterlegt. Damit sind vor allem Schlüsselwörter etwa für eine Suche zu kennzeichnen, insbesondere bei einer dynamischen Erstellung eines Dokumentes auch für Suchbegriffe geeignet. So kann ein Bezug zu den aktuellen Bedürfnissen des Lesers hergestellt werden. Im Rahmen von Büchern im Format EPUB 3 dürfte die Anwendbarkeit eines solchen Elementes für Autoren allerdings ziemlich bedeutungslos sein, weil es keine deklarative Möglichkeit gibt, als Autor eine solche Suche anzubieten und dabei dann Suchbegriffe aktiv zu kennzeichnen.
Die Elemente i, b und u haben in HTML5 eine Umdefinition erfahren, beziehungsweise das in früheren Versionen bereits gestrichene u wurde reanimiert. Zuvor stand i einfach für kursive Schrift und b für dickere Schrift, u für eine unterstrichene Textpassage.
Nunmehr wird auch mit i hervorgehoben, nicht unbedingt im Sinne einer stärkeren Betonung, sondern im allgemeineren Sinne einer anderen Betonung als für den umgebenden Text. Das Element b ist nun dafür gedacht, die Aufmerksamkeit für den Inhalt besonders zu wecken. Die Hervorhebung mittels u ist undifferenziert und nicht genau festgelegt, sollte auch nur verwendet werden, wenn sonst nichts zur Hervorhebung paßt.
Reanimiert wurde in HTML5 das Element s.
Typisch wird der Inhalt als durchgestrichen präsentiert.
Mit s wird nun Falsches und Irrelevantes gekennzeichnet.
Anders als etwa die Elemente del und ins,
die wie gehabt für Korrekturen, Änderungen und Ergänzungen zu verwenden sind,
wird mit s gekennzeichnet, was prinzipiell falsch oder irrelevant ist.
Nicht nur bei Büchern stellt sich damit natürlich die Frage, warum solcher Inhalt nicht gleich entfernt
wird, statt damit den Leser zu verwirren, insbesondere für den Fall, daß ein Darstellungsprogramm
das nicht eindeutig durchstreichen und entwerten sollte.
Zwar gibt es ja das alte Motto, daß nicht durchfallen kann, was gestrichen ist. Dies gilt bei digitalen Dokumenten aber nur sehr eingeschränkt. Während man im Theater nicht aufgeführt hat, was gestrichen ist, ist dies bei digitalen Dokumenten nach wie vor vorhanden und bleibt nicht nur auch weiterhin dem Publikum zur Bewertung überlassen, nein dies kann nun auch noch zusätzlich bewerten, ob die Streichung angemessen ist und es kann sich die Frage stellen, warum solche Inhalte nicht gleich weggelassen wurden.
Kurios, aber vielleicht erhellend ist in diesem Zusammenhang das Beispiel zu s in den Entwürfen zu HTML5 mit einem so durchgestrichenen Preis und daneben einem anderen Preis. Würde es sich um eine Korrektur oder Aktualisierung handeln, wären eben del und ins zu verwenden. Die Beispiele verwenden aber gezielt s und entlarven damit die doppelte Preisangabe gezielt als Werbetrick oder Betrugsversuch, weil es den gestrichenen Preis nach dieser Definition so nie gegeben hat.
Wie gehabt werden inzeilige Zitate mit q umschlossen. Analog dazu gibt es das bereits erwähnte Blockelement blockquote. Per Attribut cite kann eine Quelle referenziert werden. Es wird allerdings angemerkt, daß diese Quellenangabe nicht unbedingt dem Leser durch das Darstellungsprogramm verfügbar gemacht werden muß, was dann auch wieder eine etwas eigenartige Empfehlung darstellt, auch in Hinblick auf die aktuellen Skandale mit vergessenen oder unzulänglichen Quellenangaben in wissenschaftlichen Arbeiten.
Die Quellenangabe selbst, ob nun per cite für ein q referenziert oder unabhängig davon, kann wie gehabt vom Element cite umschlossen werden.
Sehr umstritten ist hier wiederum, daß solch eine Quellenangabe (nur) den Titel des Werkes enthalten soll, nicht Angaben zum Autor. Es wird also notiert, woraus zitiert wird, nicht wer. Natürlich ist es wichtig, möglichst genau anzugeben, wo oder wie das zitierte Werk zu finden oder zu identifizieren ist, von daher gehören zu Quellenangaben nach Möglichkeit Angabe zu Titel, Autoren, aber auch formale Identifikationsschemata und Werkidentifikatoren.
Unsinnig ist die Beschränkung auf den Titel etwa auch bei Quellen ohne Titel,
aber auch wo dem Zitierenden nur bekannt ist, wer etwas gesagt hat,
etwa auch bei einer privaten oder mündlichen Mitteilung,
wo also nicht angegeben werden kann, wo das Zitierte steht, sondern wo man den Zitierten
selbst fragen muß, weil dieser selbst die Quelle ist oder nur dieser selbst über die
schriftliche Quelle verfügt, die er zum Beispiel nicht veröffentlicht hat.
Eine andere Variante sind geflügelte Worte,
wo man durchgehend nur angibt, von wem die sind, aber nicht, wo man sie findet.
Auch hier empfiehlt sich also wieder, im Bedarfsfalle unsinnige Einschränkungen von HTML5
gezielt zu ignorieren.
Inzeilige Definitionen werden wie gehabt mit dem Element dfn gekennzeichnet. Neu ist, daß HTML5 festlegt, daß der zu definierende Begriff und die Definition im selben Absatz p, dem gleichen Abschnitt section oder in derselben Definitionslistengruppe stehen müssen. Das löst natürlich formal immer noch nicht das Problem, daß automatisch erkennbar ist, was definiert wird und was die Definition ist, von daher eine naheliegende Präzisierung, die allerdings auch komplett offenläßt, warum nur diese drei Strukturen dafür geeignet sind, warum nicht andere Blockelemente, die Elternelement von beidem sein müssen?
Zudem gibt es die Änderung oder Ergänzung, daß, sofern vorhanden, das Attribut title von dfn den zu definierenden Begriff enthalten soll, also umgekehrt als bei dem für Abkürzungen zu verwendenden abbr.
Sicher falsch ist etwa folgende Verwendung, nicht nur aufgrund der Formulierung, sondern bei welcher vor allem gar nicht zu erkennen ist, was definiert wird:
<dfn> Peter war schon immer etwas xenophob, insbesondere gegenüber Fremden. </dfn>
Etwas besser geht es schon so:
<p>Peter war schon immer etwas xenophob. <dfn>Xenophobie ist die Angst gegenüber Fremden.</dfn> </p>
Die Definition ist so für Menschen verständlich, nicht aber notwendig für Maschinen. Gemäß HTML5 ist es so gedacht:
<p>Peter war schon immer etwas <dfn title="xenophob">ängstlich gegenüber Fremden</dfn>.</p>
Typisch taucht der Fachbegriff aber eher im Text auf und wird zusätzlich erläutert:
<p>Peter war schon immer etwas <span title="ängstlich gegenüber Fremden">xenophob</span>.</p>
In früheren Versionen hätte auch statt span das dfn verwendet werden können, was in HTML5 aber nun rückwärtsinkompatibel ausgeschlossen wurde. Man kann allerdings auch formulieren:
<p>Peter war schon immer etwas <dfn title="xenophob">xenophob, das heißt ängstlich gegenüber Fremden</dfn>.</p>
Wie erläutert erlaubt HTML5 aber auch, daß die Definition in dem Element stehen kann, welches das Elternelement zu dfn ist, sofern es eines von folgenden Elementen ist: p, section, dt oder dd, wobei bei letzteren beiden dann der Begriff und die Definition in derselben Gruppe auftreten müssen. Damit kann das Beispiel auch so formuliert werden:
<p>Peter war schon immer etwas <dfn>xenophob</dfn>, das heißt ängstlich gegenüber Fremden.</p>
Formal ist dabei natürlich wieder nicht klar, was die Definition darstellt, weil das Elternelement natürlich auch diversen anderen Text enthalten kann, der mit der Definition nichts zu tun hat.
Abkürzungen sollten immer mindestens beim ersten Auftreten in einem Text erklärt werden und immer gekennzeichnet werden. HTML5 betont dazu, daß die mit title vorgenommenen Erklärungen aber nur lokal für jenes abbr gelten, bei welchem sie notiert sind, nicht für alle abbr im selben Dokument mit selbem Inhalt. Hier würde man also erst einmal erwarten, daß sich ein Leser die Bedeutung wenigstens über die Länge des Dokumentes hin merken kann, wenn man es nur einmal zu Beginn erklärt. Bei wichtigen Begriffen und längeren Dokumenten kann es natürlich nicht schaden, die Erklärung öfter anzugeben. Alternativ kann man natürlich auch immer einen Glossareintrag mit a referenzieren, wo die Erklärung im Bedarfsfalle nachgelesen werden kann.
Da acronym gestrichen ist, ist abbr folglich für alle Abkürzungen zu verwenden, die nicht weiter ausdifferenziert werden.
Beispiel zu abbr:
<abbr title="A vocabulary and associated APIs for HTML and XHTML">HTML5</abbr>
Hier läßt sich auch gleich die Grenze der Methode mit title erkennen. In der Erklärung enthaltene Abkürzungen können nicht weiter erläutert werden. Wenn sie für den sonstigen Inhalt relevant sind, könnte man sie also ausschreiben, falls sie nicht bereits zuvor erklärt wurden oder eben prinzipiell ein Glossar verwenden.
Ausführlicher könnte man natürlich auch formulieren und mit einer Definitionsliste kombinieren, besonders geeignet für Glossare:
<dl> <dt><abbr>HTML5</abbr></dt><dd>englischsprachiger Begriff: <span xml:lang="en">A vocabulary and associated <abbr>API</abbr>s for <abbr>HTML</abbr> and <abbr>XHTML</abbr></span></dd> <dt><abbr>API</abbr></dt><dd>Programmierschnittstelle, englischsprachiger Begriff: <span xml:lang="en">Application Programming Interface</span></dd> <dt><abbr>HTML</abbr></dt><dd>englischsprachiger Begriff: <span xml:lang="en">Hyptertext Markup Language</span></dd> <dt><abbr>XHTML</abbr></dt><dd>englischsprachiger Begriff: <span xml:lang="en">eXtensible Hyptertext Markup Language</span></dd> </dl>
Neu eingeführt wird in HTML5 ein Element data.
Dies repräsentiert Inhalte, die in zwei Varianten angeboten werden, als Elementinhalt die Variante, die für
Menschen gut lesbar ist, im erforderlichen Attribut value die maschinenlesbare Variante. Anders als bei den analogen Funktionen von RDFa kann allerdings nicht angegeben werden, welchem Schema die maschinenlesbare Angabe folgt oder welche Bedeutung die Daten haben.
Leider ist auch die Notation inkompatibel oder jedenfalls nicht redundant mit RDFa,
von daher kann es sinnvoller sein, gleich RDFa zu verwenden und auf das Element
weitgehend zu verzichten.
Einmal mehr bleibt hier HTML5 auf halbem Wege stehen und hinterläßt
etwas Halbfertiges, mit dem man in der Praxis nicht besonders viel anfangen kann.
Zumindest Zeiten und Zeitdauern können spezifischer besser mit dem neuen Element time notiert werden. Sofern der Elementinhalt nicht maschinenlesbar ist, kann das maschinenlesbare Äquivalent als Wert des Attributes datetime notiert werden. Dieser Wert entspricht dann dem für ein Datum, eine Zeitangabe oder eine Zeitdauer gemäß dem internationalen Datums- und Zeitformat.
Beispiel Pfannkuchenrezept:
<h1>Pfannkuchen</h1> <h2>Zutaten</h2> <ul> <li><data value="6">sechs</data> Eier</li> <li><data value="500g">ein Pfund</data> Mehl</li> <li><data value="300ml">eineinhalb Tassen</data> Milch</li> <li><data value="100ml">halbe Tasse</data> Wasser oder Mineralwasser</li> <li><data value="0.5g">sechs Prisen</data> Salz</li> <li>optional <data value="1g">etwas</data> Vanille</li> <li><data value="10g">etwas</data>Backfett, Öl oder Butterschmalz</li> </ul> <h2>Zubereitung</h2> <ol> <li>Backfett etc in Pfanne verteilen, um anbrennen zu vermeiden</li> <li>Sonstige Zutaten verrühren, im Gießgefäß <time datetime="P30M">dreißig Minuten</time> ruhen lassen</li> <li>Pfanne heißmachen, Fett verteilen</li> <li>Etwas von den verrührten Zutaten in die Pfanne geben, daß der Boden komplett bedeckt ist, Dicke nach Geschmack (etwa <data value="3mm">drei Millimeter</data></li> <li>Anbacken, bis die Konsistenz fest genug zum Wenden ist, sich die Masse in der Pfanne komplett bewegen läßt</li> <li>Wenden mit geschicktem Schwung der Pfanne</li> <li>Entsprechend zweite Seite ebenfalls anbacken lassen.</li> <li>Im Bedarfsfalle nochmals wenden, bis beide Seiten ein Muster von braunen und gelben Bereichen aufweisen</li> <li>Servieren mit Obst (wie Erdbeeren, Zwetschgen, Kirschen, Heidelbeeren), Sahne, Sirup, Marmelade, Nußnugat-Creme etc oder auch herzhafteren Zutaten </li> </ol>
Beispiele für Datums- und Zeitangaben:
<p> Jetzt ist <time>2013-10-07T21:17:13.123Z</time>. <time datetime="2013-10-08">Morgen</time> sieht alles aber auch nicht viel anders aus. <time datetime="2013-10-09">Nächsten Mittwoch</time> könnte sich natürlich eine Überraschung ergeben. </p>
Bei der Auszeichnung von Variablen, Eingaben und Beispielen bleibt nahezu alles beim Alten, also var
für Variablen, kbd für Nutzereingaben und samp für Beispiele.
Für samp wird allerdings nun definiert, daß der Inhalt die Ausgabe eines Programmes oder
Computersystems sein muß, was dann die Verwendung doch wieder entscheidend einschränkt.
Wird ein kbd innerhalb eines kbd verschachtelt, so wird der Inhalt
eingeschränkt auf eine Zeichenkette, die einer einzelnen Taste auf der Tastatur entspricht, beziehungsweise eine
einzelne Eingabeeinheit. Steht hingegen ein kbd innerhalb von samp,
so wird festgelegt, daß diese Kombination die Reaktion oder das Echo des Systems auf eine Eingabe ist.
Steht umgedreht ein samp im kbd, so repräsentiert dies eine Eingabe, die
auf einer Ausgabe des Systems basiert.
Auch die Auszeichnung als Quelltext erfolgt wie gehabt mit dem Element code. Präzisiert wird hier lediglich, daß es sich um Quelltext für Rechner handelt.
Auch beim Hoch- und Tiefstellen von Text werden wie gehabt die alten Elemente verwendet, also sub für Tiefstellen und sup für Hochstellen. Es wird für HTML5 allerdings betont, daß dies wie bei Formeln notwendig eine inhaltliche Bedeutung haben soll und nicht nur einem Präsentationseffekt wie bei Logos dienen soll. Als Beispiel ein Symbol für den elektronischen Grundzustand eines Moleküls X 2Σ1/2:
X <sup>2</sup>Σ<sub>1/2</sub>
Gegenüber dem XHTML-Modul zu Ruby-Anmerkungen ist der Inhalt in HTML5 drastisch zusammengestrichen. Da EPUB 2 dieses Modul aber ohnehin ausgeschlossen hat, stellt dieser kleine Rest für EPUB 3 trotzdem eine Verbesserung dar.
Das Element ruby umschließt den Begriff und die Anmerkung.
Der Inhalt besteht aus folgenden Komponenten:
Eine Komponente besteht aus
Text oder Phrasenelementen wie insbesondere das Element rt aber ohne ruby.
Zudem kann eine Komponente von ruby auch aus einem anderen Element ruby bestehen,
welches allerdings keine weiteren Elemente ruby enthalten darf.
Eine weitere mögliche Komponente besteht aus einem oder mehreren Elementen rt.
Eine weitere Komponente besteht darin, zunächst ein Element rp zu notieren, gefolgt
von einem oder mehreren Elementen rt, gefolgt von einem abschließenden rp.
Diese Komponente und die Verwendung von rp wird für EPUB 3 für überflüssig gehalten,
weil Darstellungsprogramme für EPUB 3 Ruby-Anmerkungen interpretieren können müssen.
In der Praxis tun dies aber nicht alle und die alten Darstellungsprogramme für EPUB 2 brauchen es
ohnehin nicht, von daher ist die Empfehlung, rp nicht zu nutzen, als eher bedenklich
einzustufen.
Die beiden Elemente rp repräsentieren einen Klammerausdruck. Das erste enthält Zeichen, die einer öffnenden Klammer entsprechen, das zweite die einer schließenden Klammer. Der Inhalt wird nicht dargestellt, wenn das Darstellungsprogramm Ruby-Anmerkungen interpretiert, dient also lediglich als Hilfe für Nutzer von Programmen, die Ruby-Anmerkungen nicht interpretieren. Der Inhalt besteht aus Text oder Phrasenelementen.
rt beinhaltet die Anmerkung zu vorangehendem Inhalt von ruby bis zu einer gegebenenfalls vorhandenen vorhergehenden Endmarkierung von rt. Der Inhalt besteht wieder aus Text oder Phrasenelementen.
Beispiele:
<ruby>W3<rt>World Wide Web</rt>C<rt>Consortium</rt></ruby> <ruby>W3<rt>World Wide Web</rt></ruby><ruby>C<rt>Consortium</rt></ruby> <ruby>Text<rt>Anmerkung 1</rt><rt>Anmerkung 2</rt></ruby> <ruby> ♥<rp>: </rp><rt xml:lang="en">Heart</rt> <rp>, </rp><rt xml:lang="fr">Cœur</rt> <rp>, </rp><rt xml:lang="de">Herz</rt> <rp /> </ruby> <ruby><ruby>Text<rt>Innere Anmerkung</rt></ruby><rt>Äußere Anmerkung</rt></ruby> <ruby xml:lang="en"> <ruby>X<rp>[</rp><rt>eXtensible</rt><rp>]</rp> HT<rp>[</rp><rt>HyperText</rt><rp>]</rp> M<rp>[</rp><rt>Markup</rt><rp>]</rp> L<rp>[</rp><rt>Language</rt><rp>]</rp> </ruby> <rp>(</rp><rt xml:lang="de">Erweiterbare Auszeichnungssprache für Hypertext</rt><rp>)</rp> </ruby>
Zum bereits bekannten bdo kommt mit HTML5 ein weiteres Element bdi hinzu.
Bei bdo kann wie gehabt mit dem erforderlichen dir die normale Leserichtung für den Inhalt überschrieben werden, also 'rtl' für von rechts nach links, 'ltr' für von links nach rechts. Von oben nach unten oder von unten nach oben ist nicht vorgesehen.
Normalerweise wird der Wert von dir vom Elternelement geerbt, wenn es nicht explizit gesetzt ist. Beim neuen Element bdi wird hingegen nicht geerbt, wenn das Attribut nicht gesetzt ist, stattdessen wird die durch den Text automatisch gegebene Leserichtung verwendet.
Beispiel, dem guten Kurt Schwitters zum Andenken:
<p> Wörter, die von vorne nach hinten gelesen und von hinten nach vorne gelesen einen Sinn ergeben, werden Palindrome genannt. </p> <p> Schon Kurt Schwitters hat durch die Blume festgestellt, dass Anna von vorne wie von hinten - <bdo dir="rtl">Anna</bdo> ist. Und das ist gut. </p> <p> Auch Otto ist von vorne wie von hinten <bdo dir="rtl">Otto</bdo>, was Kurt aber nicht besonders interessiert hat, weil nunmal die <bdo dir="rtl">Anna</bdo> die Geliebte seiner siebenundzwanzig Sinne war und nicht der <bdo dir="rtl">Otto</bdo>. </p> <p> Lage ist auch ein Palindrom, ist aber nicht von vorne wie von hinten <bdo dir="rtl">Lage</bdo>, ebensowenig wie jede Emma eine Amme ist. Schon von daher handelt es sich um etwas anderes als bei einem <bdo dir="rtl">Relie<bdi>fpf</bdi>eiler</bdo> oder gar einer Anna Blume, der zu Ehren es nicht nur ein Gedicht von Kurt Schwitters gibt, sondern in Hannover auch einen Brunnen von Max Sauk. </p> <p> Hannover ist kein Palindrom, wie auch Kurt bereits anmerkte. Allerdings vermochte er für <bdo dir="rtl">Hannover</bdo> einen Sinn herzuleiten - rückwärts von nah - und dies wieder zurückgedreht - vorwärts nach weit.<br /> Und immerhin kann in Hannover <bdo dir="rtl">Anna</bdo> mit <bdo dir="rtl">Otto</bdo> an der Leine spazierengehen. Und das ist auch gut. </p>
Eine Kuriosität (neben zahlreichen anderen) von HTML5 ist ein neues eigenes Element für
ein Zeichen, welches ein Leerzeichen der Breite 0 bedeutet, dies ist nach Unicode das Zeichen
U+200B oder auch ​, kann in HTML5 aber ebenfalls mit dem inhaltsleeren
Element wbr notiert werden. Solche Notationen, in einen Wort verwendet,
können dazu führen, daß an der Stelle ein automatischer Zeilenumbruch erfolgt.
Es gibt allerdings keinen Trennstrich, was die Nützlichkeit stark einschränken wird.
Will man angeben, wo ein Wort sinnvoll getrennt werden kann, verwendet man dafür besser
das Zeichen U+00AD oder auch ­. Sofern ein Zeilenumbruch an der Stelle erfolgt, hat
das Darstellungsprogramm dann dort auch automatisch einen Trennstrich einzufügen.
Begrenzt nützlich kann das Element wbr allerdings innerhalb von
pre verwendet werden, um optionale Stellen für einen Zeilenumbruch
vorzuschlagen, hier weicht HTML5 also von der Bedeutung des Zeichens U+200B ab.
Nach wie vor und mit gleicher Verwendung ist das Element span verfügbar für all jene Fälle, wo kein passendes Element für die semantische Bedeutung verfügbar oder notwendig ist. Ähnlich wie div für Blockelemente kann span als Phrasenelement verwendet werden, wenn ein Element notwendig ist, aber kein Element mit inhaltlicher Bedeutung verfügbar oder notwendig ist. Im Bedarfsfalle kann dann wieder mit der Erweiterung von EPUB 3, dem Attribut type, die semantische Bedeutung des Inhaltes angegeben werden. Das Element kann aber auch nützlich sein, wenn eine Phrase in einer anderen Sprache verwendet wird oder die Leserichtung mit entsprechenden Attributen geändert werden soll.
Um andere Dokumente einzubetten, gibt es neben den bereits bekannten Elementen img und object einige, die von HTML5 neu eingeführt wurden. Das neu eingeführte Element embed bietet keine Möglichkeit, zugängliche alternative Inhalte bereitzustellen und sollte deshalb gar nicht verwendet werden. Eine entsprechende Forderung ist auch in EPUB 3 zu finden.
Beim bereits bekannten Element img wird allerdings etwa das Attribut longdesc gestrichen. Das ist konsistent mit einigen Bestrebungen, die Zugänglichkeit von Dokumenten mit HTML5 zu verschlechtern.
Wie gehabt enthält das erforderliche Attribut src einen Verweis auf die einzubettende Bilddatei. Das Attribut alt enthält eine entsprechende Textalternative zum Bild in dem Sinne, daß sich keine Änderung der inhaltlichen Bedeutung ergibt, wenn das eine gegen das andere getauscht wird. Mit width kann die Breite des Darstellungsbereiches für das Bild angegeben werden, mit height die Höhe. usemap und ismap können wie gehabt verwendet werden.
Neu ist das Attribut crossorigin, was mit Sicherheitsaspekten zu tun hat, falls das Bild aus einer externen Quelle kommt und mit Skripten manipuliert wird. Da dies in der Praxis für Bücher belanglos sein sollte und schwer sicherzustellen ist, daß manipulierte externe Bilder nicht ihre Bedeutung ändern, die per alt bereits festgelegt ist, dürfte die sinnvolle Verwendung nicht nur in Büchern sehr stark begrenzt sein.
Während in früheren Versionen keine besonderen Elemente für Video- und Audiodateien definiert waren, sondern einfach das recht gut durchdachte und wie gehabt verfügbare object verwendet wurde, definiert HTML5 zwei neue Elemente audio und video. Da das Konzept für zugängliche Alternativen für diese neuen Elemente weit weniger gut durchdacht ist als für object, ergeben sich bei der Verwendung spezifische Probleme. Da andererseits neuere Versionen von Darstellungsprogrammen mit der Einführung dieser neuen Elemente teils jene Formate nicht mehr in object interpretieren, die sie nun in audio und video interpretieren, und auch keine Formate genannt werden, die lizenzfrei sind und erforderlich interpretiert werden müssen, breitet sich so vor den Autoren ein kaum mehr überschaubares Chaos aus. Dazu trägt auch bei, daß das Konzept neu erfunden wurde und nicht etwa das bewährte Konzept von SMIL übernommen wurde wie etwa bei SVG tiny 1.2.
Alte Programme kennen diese Elemente und ihre Funktion nicht, die referenzierten Inhalte bleiben bei diesen unzugänglich. Es ist also bei der Verwendung dieser Elemente immer zu empfehlen, auf relevante Inhalte zusätzlich mit dem Element a zu verweisen, also zusätzlich zu einer Textalternative. Typisch wird man dazu diese Elemente in einem Element figure notieren und in figcaption dann zum einen die Textalternative, zum anderen Verweise auf die Video- und Audiodateien.
Ähnlich wie bei img kann mittels des Attributes src eine Datei referenziert werden, die eingebettet werden soll. Für audio ein Audio-Format, für video ein Video-Format oder ein Audio-Format mit Überschriften. Entsprechend hat video für die Größe auch die Attribute width und height. Auch das Attribut crossorigin mit gleicher Bedeutung wie für img ist bei den beiden neuen Elementen verfügbar.
Ebenfalls bei beiden Elementen verfügbar sind die Attribute preload, autoplay, mediagroup, loop, muted, und controls.
Das Attribut preload dient dazu, daß Autoren einen Hinweis angeben können, was vermutlich die beste Methode ist, damit eine optimale Verwendung der Ressource gewährleistet ist. Bei Büchern im Format EPUB wird die Audio- oder Video-Datei ohnehin im Bucharchiv lokalisiert sein und nicht auf einem externen Dienstrechner, von daher dürfte der Nutzen des Attributes für Bücher sehr stark begrenzt sein. Der Wert des Attributes ist eines der folgenden Schlüsselwörter:
Mit dem Attribut loop kann angegeben werden, daß die Datei nach dem Erreichen des Endes der Datei diese von Anfang an wiederholt wird. Zu diesem Zwecke reicht es, das Attribut zu notieren. Ist es nicht notiert, wird nicht wiederholt. Der Wert ist entweder leer oder 'loop'.
Entsprechend kann mit dem Attribut autoplay angegeben, werden, daß das Abspielen der Datei automatisch starten soll. Zu diesem Zwecke reicht es, das Attribut zu notieren. Ist es nicht notiert, wird nicht automatisch gestartet. Der Wert ist entweder leer oder 'autoplay'.
Mit controls kann wiederum angegeben werden, daß das Darstellungsprogramm selbst Kontrollelemente
für den Nutzer zur Verfügung stellen soll - also etwa um das Abspielen zu starten, zu pausieren, Pause beenden,
den Ton an- oder abzuschalten. Zu diesem Zwecke reicht es, das Attribut zu notieren.
Ist es nicht notiert, werden keine Kontrollelemente bereitgestellt.
Der Wert ist entweder leer oder 'controls'.
Diese Kontrollelemente sind immer verfügbar, wenn Skriptinterpretation nicht aktiviert
oder verfügbar ist. Ist das Attribut nicht gesetzt, muß der Autor selbst solche Kontrollelemente für jene Nutzer
verfügbar machen, bei denen Skriptinterpretation vorhanden ist. In EPUB 3 empfiehlt es sich natürlich,
wenn überhaupt, dann eigene Kontrollelemente deklarativ mit den speziell von EPUB 3 definierten
Erweiterungen verfügbar zu machen, weil HTML5 keine deklarative Methode definiert, um solche Kontrollelemente anzubieten.
Insgesamt ist es etwas problematisch, daß ohne das Attribut bei aktivierter Skriptinterpretation keine Kontrollelemente angeboten werden. Autoren haben keinen Einfluß darauf, ob Skripte interpretiert werden.
Schon von daher ist das Vorgehen von HTML5 hier schlecht durchdacht.
Statt dieses Attributes wäre es sinnvoller gewesen, eine Schnittstelle im Dokument-Objekt-Modell vorzusehen,
mit welcher ein Skript die Kontrollelemente explizit abschalten kann, falls eigene angeboten werden.
Nun ist es Autoren dringend zu empfehlen, das Attribut bei den Elementen immer zu setzen und für den
Fall, daß eine Steuerung per Skript erfolgt, das Attribut per Skript über das Dokument-Objekt-Modell wieder zu entfernen.
Mittels muted kann angegeben werden, daß der Ton abgeschaltet werden soll. Zu diesem Zwecke reicht es, das Attribut zu notieren. Ist es nicht notiert, ist der Ton gegebenenfalls verfügbar. Der Wert ist entweder leer oder 'muted'.
Mit dem Attribut mediagroup können Audio- und Videoelemente miteinander verknüpft werden. Der Wert ist einfacher Text. Audio- und Videoelemente mit demselben Wert sind miteinander zu einer Gruppe verknüpft. Kontrollelementen gelten dann für alle Elementen einer solchen Gruppe.
Das Element video hat zudem ein Attribut poster. Damit kann ein Bild angegeben werden, welches angezeigt wird, wenn das Video nicht angezeigt wird. Der Wert referenziert die Bilddatei.
Sofern das Attribut src verwendet wird, können die Audio- und Videoelemente leer bleiben, aber auch als ersten Inhalt Elemente track enthalten. Danach können Inhalte folgen, welche auch im Elternelement erlaubt sind. Diese Inhalte sind nur gedacht für alte Darstellungsprogramme, die die Elemente selbst noch nicht kennen. Der Inhalt ist also keine Alternative für den Fall, daß das verwendete Dateiformat nicht interpretiert wird, wie dies bei object der Fall ist. Es ist also mit diesem Konzept nicht möglich, den Inhalt so zu gestalten, daß garantiert immer eine Alternative präsentiert wird. Von daher ist dieses Konzept nicht für relevanten Inhalt zu empfehlen, nur für inhaltlich belanglose Dateien.
Sofern das Attribut src nicht verwendet wird, kann als Inhalt von Audio- und Videoelementen
folgendes Konzept verwendet werden: Zunächst können Elemente source notiert werden, mit
alternativen Dateien in anderen Formaten, aber auch jeweils Audio- und Videoformate.
Danach können wieder Elemente track folgen.
Danach können Inhalte folgen, welche auch im Elternelement erlaubt sind.
Zwar ergibt sich so eine größere Chance, daß irgendein Format präsentiert werden kann, sofern aber kein Format
interpretiert wird, bestehen die gleichen Zugänglichkeitsprobleme wie beim anderen Konzept.
Es ist also auch mit diesem Konzept nicht möglich, den Inhalt so zu gestalten, daß garantiert immer eine Alternative
präsentiert wird. Von daher ist dieses Konzept nicht für relevanten Inhalt zu empfehlen, nur für inhaltlich
belanglose Dateien.
Mit inhaltsleeren Elementen source wird jeweils eine alternative Datei in jeweils einem anderen Format für audio oder video angegeben. Mittels src wird die jeweilige Datei referenziert. Mittels type wird der Inhaltstyp oder Medientyp oder das Format der referenzierten Datei angegeben. Optional können nach einem Semikolon Codecs mit einem Parameter angegeben werden. Die Syntax ist entsprechend folgenden Beispielen:
type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' type="video/ogg; codecs='theora, vorbis'" type='audio/ogg; codecs=vorbis' type='video/ogg; codecs="dirac, vorbis"'
Mit dem Attribut media kann entsprechend eine Medienanfrage angegeben werden, um dem Darstellungsprogramm zu erleichtern, eine passende Auswahl zu treffen. Mit type und media kann das Darstellungsprogramm also bestimmen, welche Alternative zur Darstellung ausgewählt und geladen werden soll. Die anderen Dateien werden dann nicht geladen. Die erste passende Datei wird gewählt.
Mit inhaltsleeren Elementen track können jeweils Text-Dateien mit Untertitel referenziert werden.
Mittels src wird die jeweilige Datei referenziert.
Mittels srclang wird für die verwendete Sprache das zutreffende Sprachkürzel wie 'de'
für deutsch angegeben.
Mittels label wird jeweils eine Überschrift angegeben.
Mittels default wird angegeben, daß diese Datei verwendet wird, sofern es keine anderen Voreinstellungen oder
Angaben vom Nutzer gibt.
Zu diesem Zwecke reicht es, das Attribut zu notieren.
Der Wert ist entweder leer oder 'default'.
Mittels kind wird der Typ des Untertitels angegeben.
Wird das Attribut nicht notiert, wird der Wert 'subtitles' angenommen.
Es gibt folgende Typen:
Für eine Gruppe von Alternativen ist dann jeweils maximal ein Element track mit einem Wert für kind 'subtitles', 'captions', 'descriptions', 'chapters' erlaubt.
Ein Format für die Untertitel ist zum Beispiel WebVTT. Dazu gibt es nur einen Arbeitsentwurf, noch keine Empfehlung (Stand 2015-07). EPUB 3 berücksichtigt das Format nicht als erforderlich. Erforderlich zu interpretierende Alternativen dazu gibt es nicht. Es handelt sich nach dem aktuellen Stand um reine Textdateien, also nicht etwa um ein XML-Format. Eine Alternative dazu wäre sicherlich mit SMIL möglich, aber nicht mit der winzigen Untermenge, die in EPUB 3 festgelegt wird. Hier ergibt sich eine Lücke oder ein Fehler in EPUB 3.
Beispiel für die Einbindung einer einfachen, rein dekorativen Audio-Datei mit Wiederholung, automatischem Start, Kontrollelementen:
<audio src="rumms.ogg" type="audio/ogg; codecs=vorbis" autoplay="" loop="" controls="" />
Beispiel mit Alternativen und Untertitel:
<figure> <audio controls="" loop=""> <source src="noise2.ogg" type="audio/ogg"/> <source src="noise2.mp3" type="audio/mp3"/> <source src="noise2.wav" type="audio/x-wav"/> <track src="text.vtt" kind="subtitles" label="track" default=""/> </audio> <figcaption> Ein Geräusch (<a href="noise2.ogg" type="audio/ogg">OGG</a>, <a href="noise2.mp3" type="audio/mp3">MP3</a> oder <a href="noise2.wav" type="audio/x-wav">WAV</a>) </figcaption> </figure>
Video-Beispiel mit Untertitel:
<figure> <video controls="" src="m202.ogg" loop="" poster="p1030202.jpg" width="320" height="240"> <track src="text.vtt" kind="subtitles" label="track" default=""/> <track src="text.vtt" kind="captions" label="track"/> <track src="text.vtt" kind="chapters" label="track"/> </video> <figcaption>Video einer <a href="m202.ogg" type="video/ogg">Plasma-Lampe</a> (OGG)</figcaption> </figure>
Video-Beispiel mit Alternativen:
<figure> <video controls="" loop="" poster="p1030202.jpg" width="320" height="240"> <source src="p1030202.ogg" type="video/ogg"/> <source src="p1030202.3gp" type="video/3gpp"/> <source src="p1030202.avi" type="video/x-msvideo"/> <source src="p1030202.mpg" type="video/mpeg"/> <source src="p1030202.wmv" type="video/x-ms-wmv"/> </video> <figcaption>Video einer Plasma-Lampe (<a href="p1030202.ogg" type="video/ogg">OGG</a>, <a href="p1030202.3gp" type="video/3gpp">3GPP</a>, <a href="p1030202.avi" type="video/x-msvideo">AVI</a>, <a href="p1030202.mpg" type="video/mpeg">MPEG</a> oder <a href="p1030202.wmv" type="video/x-ms-wmv">WMV</a>) </figcaption> </figure>
Beim für Einbettungen allgemein verwendbaren Element object wurden in HTML5 einige Attribute gestrichen, einige davon sicherlich berechtigt, weil sie überflüssig
waren, bei anderen führt dies zu einer Einschränkung der Nutzbarkeit.
Zusätzlich wurde in HTML5 das Element iframe reanimiert, welches
eine ähnliche Funktion hat, jedoch keine Parameterübergabe an das eingebettete Dokument ermöglicht.
Mit width und height können wie auch bei den anderen Elementen dieser Kategorie Breite und Höhe des Anzeigebereiches für den eingebetteten Inhalt angegeben werden.
Entsprechend kann für object mit type
der Inhaltstyp oder Medientyp angegeben werden.
Diese Angabe kann dann etwa herangezogen werden, um festzustellen, ob die einzubettende
Datei darstellbar ist oder der Inhalt des Elementes als Alternative dargestellt wird.
Wird das neue Attribut typemustmatch notiert, ist das mit
data referenzierte Dokument nur zu verwenden, falls dessen Inhaltstyp mit
dem übereinstimmt, welcher mit type angegeben ist.
Mit dem Attribut data wird das einzubettende Dokument referenziert, es hat
also eine analoge Funktion wie src bei den anderen Elementen dieser
Kategorie.
Neu ist das Attribut name, mit welchem für object nun auch die komplette frühere Funktionalität von iframe verfügbar ist, welches damit zumindest in seiner alten Funktion nahezu komplett redundant wird. Der als Wert notierte Name kann dazu dienen, mit Verweisen mit dem Attribut target den eingebetteten Inhalt von object auszutauschen.
Mit dem neuen Attribut form kann das object mit einem Formular verknüpft werden. Wert ist dann der Fragmentidentifizierer des verknüpften Formulars. Analog kann mit usemap wie gehabt eine Karte (Element map) verknüpft werden.
Der erste Inhalt von object besteht aus einer beliebigen Anzahl von Elementen param. Während bei früheren Version dann nahezu beliebiger Inhalt als Alternative folgen konnte, bestimmt sich nun der erlaubte Inhalt aus dem, was für das Elternelement von object erlaubt ist, das Element ist also transparent. Dieser Inhalt dient jedenfalls als Alternative, wenn das Format des referenzierten Dokumentes nicht dargestellt werden kann. Insbesondere können also weitere Elemente object ineinander verschachtelt werden, um diverse Formate als Alternativen anzubieten. Die letzte Alternative ist dann zumeist ein Text, manchmal in Verbindung mit Verweisen auf die einzubettenden Dateien, damit diese im Bedarfsfalle auch mit externen Programmen angesehen oder einfach gespeichert werden können.
Elemente param, die im Bedarfsfalle in object zu notieren sind und zwar zu Beginn des Inhaltes, dienen dazu, Parameter an die von object referenzierte Datei zu übergeben. Von den in EPUB 3 erforderlich zu interpretierenden Formaten hat allerdings keines eine Funktion, um solche Parameter auszuwerten, weswegen die Anwendung in Büchern begrenzt sein dürfte. Das Element param ist inhaltsleer. In HTML5 müssen die Attribute name und value notiert werden. Gegenüber früheren Versionen ergeben sich also auch hier Einschränkungen.
Der Wert von name ist jedenfalls der Name des zu übergebenden Parameters, der Wert von value ist der Wert des Parameters.
Einfaches Beispiel der Einbindung eines SVG-Dokumentes - weil SVG ein erforderliches Format ist, ist es nicht notwendig, eine Alternative anzugeben. Dank der neuen Funktionalität kann allerdings der Inhalt einfach ausgetauscht werden. Die Größe wird automatisch von dem SVG-Dokument bezogen, welches zum Beispiel auch angeben kann, daß die gesamte verfügbare Breite verwendet werden soll.
<figure> <p> <object data="Mandala01.svg" type="image/svg+xml" name="Mandala" /> </p> <figcaption> <h1>Mandala</h1> <p> Auswahl eines anderen Mandalas: </p> <ul> <li><a href="Mandala04.svg" target="Mandala">Mandala 4</a></li> <li><a href="Mandala03.svg" target="Mandala">Mandala 3</a></li> <li><a href="Mandala02.svg" target="Mandala">Mandala 2</a></li> <li><a href="Mandala01.svg" target="Mandala">Mandala 1</a></li> </ul> </figcaption> </figure>
Verschachtelte Alternativen für ein Video. Die Alternative steht auch hier in der Beschriftung, daher kann das innerste object leer bleiben.
<figure> <object data="p1030202.3gp" type="video/3gpp" width="320" height="240"> <object data="p1030202.avi" type="video/x-msvideo" width="320" height="240"> <object data="p1030202.wmv" type="video/x-ms-wmv" width="320" height="240"> <object data="p1030202.mov" type="video/quicktime" width="320" height="240"> <object data="p1030202.mpg" type="video/mpeg" width="320" height="240"> <object data="p1030202.mp4" type="video/mp4" width="320" height="240"> <object data="m202.ogg" type="video/ogg" width="320" height="240"> <object data="p1030202.flv" type="video/x-flv" width="320" height="240"> <object data="p1030202.swf" type="application/x-shockwave-flash" width="320" height="240" /> </object> </object> </object> </object> </object> </object> </object> </object> <figcaption>Video einer Plasmalampe</figcaption> </figure>
Ein weiteres Element zur allgemeinen Einbettung von Inhalten ist iframe. Das Element ist inhaltsleer. Es gibt also keine Möglichkeit, Alternativen anzubieten, falls das referenzierte Format nicht interpretiert werden kann. Für Bücher im Format EPUB 3 sollten also nur Dokumente in Formaten referenziert werden, die erforderlich interpretiert werden müssen.
Mit dem Attribut src kann wieder das einzubettende Dokument referenziert werden. Mit width und height können wieder Breite und Höhe des Anzeigebereiches für den eingebetteten Inhalt angegeben. werden. Der als Wert von name notierte Name kann dazu dienen, mit Verweisen mit dem Attribut target den eingebetteten Inhalt von iframe auszutauschen.
Neu ist das Attribut srcdoc. Dies kann statt src verwendet werden, um das einzubettende XML-Dokument anzugeben. Hier ist das komplette Dokument allerdings als Wert des Attributes zu notieren, im Bedarfsfalle also mit geeigneter Maskierung von Zeichen, die mit der Syntax von Attributwerten in Konflikt geraten können. Da dies recht unübersichtlich werden kann, kann es letztlich einfacher sein, alternativ den Wert von src mit dem Pseudoprotokoll 'data' und mit Base64 kodiert zu notieren.
Ein weiteres neues Attribut ist sandbox. Damit kann ein Autor den Inhalt einschränken, der im
iframe auftreten darf. Sofern das Attribut gesetzt ist, sind folgende Inhalte im referenzierten
Doument deaktiviert: Formulare, Skripte, Verweise zu anderen Dokumenten und eingebettete Programme laufen in einer abgesicherten
Umgebung, in einer eigenen Spiel- oder Sandkiste, wonach das Attribut benannt ist. Solch eine Sandkiste stellt sicher, daß
das eingebettete Programm für sich läuft und keine Informationen aus der einbettenden Umgebung auslesen kann oder in diese
einbringen kann.
Der Wert besteht aus einer Liste von festen Werten, die mit Leerzeichen voneinander zu separieren sind.
Möglich sind folgende Werte als Listenpunkte, die beschreiben, was im referenzierten Dokument wieder aktiviert wird:
Ist das neue Attribut seamless gesetzt, so soll kein Rand oder Rahmen zwischen referenzierendem und referenzierten Dokument dargestellt werden, die beiden Dokumente werden also als Einheit dargestellt. Dazu reicht das Notieren des Attributes. Der Wert ist entweder leer oder 'seamless'. Verweise im referenzierten Dokument werden zudem im gesamten Anzeigebereich des referenzierenden Dokumentes angezeigt, solange nicht target='_self' verwendet wird (oder ein anderer Wert etwa für ein neues Fenster). Zudem wird die Stilvorlage des referenzierenden Dokumentes auf das referenzierte übertragen. Sofern Stilvorlagen interpretiert werden, wird zudem die Breite von iframe auf 'auto' gesetzt und die Höhe wird auf einen Wert gesetzt, der genau passend zum benötigten Platz für das referenzierte Dokument ist.
Entsprechend dem obigen Beispiel mit den Mandalas und object das gleiche mit iframe, aber nahtlosem Übergang zwischen den Dokumenten:
<figure> <p> <iframe src="Mandala01.svg" seamless="" name="Mandala" /> </p> <figcaption> <h1>Mandala</h1> <p> Auswahl eines anderen Mandalas: </p> <ul> <li><a href="Mandala04.svg" target="Mandala">Mandala 4</a></li> <li><a href="Mandala03.svg" target="Mandala">Mandala 3</a></li> <li><a href="Mandala02.svg" target="Mandala">Mandala 2</a></li> <li><a href="Mandala01.svg" target="Mandala">Mandala 1</a></li> </ul> </figcaption> </figure>
Neu in HTML5 ist das Element canvas, mit welchem eine
Zeichenfläche für Skripte verfügbar gemacht wird.
Sofern eine andere, allgemein zugängliche Repräsentation des Inhaltes möglich ist - was
eigentlich immer der Fall sein wird - muß stattdessen dafür die zugängliche Repräsentation des Inhaltes
verwendet werden und nicht canvas.
Dies kann bei graphischen Repräsentationen oft ein SVG-Dokument oder -Fragment sein,
aber auch eine Pixelgraphik einschließlich Textalternative. Da EPUB 3 aktuell
deklarative und interaktive Animation mit SVG ausschließt, kann es nun passieren,
daß eine zugängliche Repräsentation des gewünschten Inhaltes damit ausgeschlossen ist, folglich
eignet sich dann der beabsichtigte Inhalt gar nicht für Bücher im Format EPUB 3.
Wird canvas verwendet, so muß der Inhalt des Elementes eine zugängliche Alternative
für jene Nutzer sein, bei denen Skriptinterpretation nicht verfügbar oder aktiviert ist.
canvas ist transparent, erlaubt also den gleichen Inhalt wie das Elternelement,
in welchem es notiert ist.
Um die Größe der Zeichenfläche festzulegen, können die üblichen Attribute
width für die Breite des Darstellungsbereichs und
height für die Höhe verwendet werden.
Karten für verweissensitive Graphiken werden wie gehabt in map notiert, weil allerdings für a diesbezügliche Attribute in HTML5 gestrichen wurden, bleibt nur die Verwendung von area, wobei es allerdings ein größeres Risiko für Zugänglichkeitsprobleme gibt als bei der Verwendung von a, beziehungsweise die Verweise sind in map zum Beispiel doppelt zu notieren, einmal mit a, einmal mit area. Das Element map ist transparent, es ist also der gleiche Inhalt erlaubt wie im Elternelement.
Mit dem erforderlichen Attribut name wird ein Name notiert, welcher beim zugehörigen Bild mittels usemap referenziert wird.
In map sind die zur verweissensitiven Graphik gehörigen Referenzierungen mit den Elementen area
zu notieren. Die Attribute alt,
href,
target,
download,
rel,
hreflang und
type
haben die gleiche Funktion und Bedeutung wie für a.
Hinzu kommen die Attribute
coords und
shape.
Ist href nicht notiert, so handelt es sich um einen Bereich, bei dem nichts passiert, wenn man
ihn anklickert.
Mit shape wird die Form des verweissensitiven Bereiches notiert. Folgende Werte sind möglich:
Mittels coords werden die Koordinaten angegeben, die den verweissensitiven Bereich beschreiben.
Die möglichen Werte hängen vom Wert von shape ab.
Es handelt sich immer um ganze Zahlen, die durch Kommata voneinander zu separieren sind, also keine Leerzeichen.
Im Falle von 'default' ist das ganze Bild der verweissensitive Bereich.
coords darf nicht gesetzt sein.
Im Falle von 'circle' werden drei ganze Zahlen notiert, wobei die letzte nicht negativ sein darf.
Die erste Zahl ist der Abstand von der linken Kante des Bildes bis zum Zentrum des Kreises in Pixeln.
Die zweite Zahl ist der Abstand von der oberen Kante des Bildes bis zum Zentrum des Kreises in Pixeln.
Die dritte Zahl ist der Radius des Kreises in Pixeln.
Im Falle von 'rect' werden vier ganze Zahlen notiert, die erste muß kleiner als die dritte sein
und die zweite kleiner als die vierte.
Die erste Zahl ist der Abstand der linken Kante des Rechteckes von der linken Kante des Bildes in Pixeln.
Die zweite Zahl ist der Abstand der oberen Kante des Rechteckes von der oberen Kante des Bildes in Pixeln.
Die dritte Zahl ist der Abstand der rechten Kante des Rechteckes von der linken Kante des Bildes in Pixeln.
Die vierte Zahl ist der Abstand der unteren Kante des Rechteckes von der oberen Kante des Bildes in Pixeln.
Im Falle von 'poly' ist ein geradzahlige Anzahl von ganzen Zahlen zu notieren, wenigstens sechs.
Die Liste besteht jeweils aus Paaren.
Ein Paar beschreibt jeweils einen Punkt des Polygons.
Der erste Wert ist der Abstand von der linken Kante des Bildes in Pixeln, der zweite der von der oberen Kante des Bildes in Pixeln.
Überlappen Bereiche, so ist in der Schnittmenge der Bereich wirksam, der zuerst notiert ist.
Ist es notwendig, bei einem Dokument eine Änderung oder Ergänzung zu kennzeichnen, so wird wie gehabt das Element del verwendet, um nicht mehr gültige Passagen zu streichen. ins wird verwendet, um Ergänzungen einzufügen. Die Elemente nehmen insofern eine Sonderstellung ein, also sie sowohl als Blockelemente als auch Phrasenelemente verwendet werden können. Die entsprechende Funktion ergibt sich aus dem Elternelement und den Kindelementen. Die Elemente sind transparent, die Struktur ist also sinnvoll, wenn sie auch noch sinnvoll ist, wenn man die Elemente formal wegläßt.
Das Attribut datetime kann jeweils bei Bedarf verwendet werden, um das Datum der Änderung
anzugeben. Der Wert ist jeweils ein Datum, bei Bedarf auch mit Zeitangabe. Das ist nach dem internationalen
Datumsformat zu notieren. Mit dem Attribut cite kann entsprechend auf ein Dokument oder
Dokumentfragment verwiesen werden, welches eine Begründung oder Erläuterung für die Änderung gibt.
Ziemlich unsinnig ist, daß es für HTML5 nunmehr nicht mehr erforderlich ist, dem Nutzer oder Leser
eine solche Information zugänglich zu machen. Als Konsequenz sollten Autoren solch relevante Informationen
in HTML5-Dokumenten folglich anderweitig notieren, etwa in einem Element
aside und nur noch darauf verweisen.
Formulare werden in Büchern eher eine sehr untergeordnete Rollen spielen, sind bei interaktiveren oder experimentelleren Büchern aber nicht auszuschließen. Das Hauptproblem bei Formularen liegt darin, daß es für eine sinnvolle Funktion meist notwendig ist, sie abzuschicken und dann mit einem Dienstprogramm auszuwerten, welches dann eine Antwort sendet. Innerhalb von Büchern im Format EPUB 3 ist allerdings keine Sprache wie etwa PHP vorgesehen, die interpretiert werden muß, um abgeschickte Formulare im Buch auszuwerten und eine Antwort zu erstellen. Mit einer Sprache wie java-script/ecmascript kann zwar auch der aktuelle Status eines Formulars analysiert und manipuliert werden, die Interpretation ist aber optional. Autoren können sich also nicht darauf verlassen, daß solch eine Funktionalität verfügbar ist. Bei einem vom Autor kontrollierten Dienstprogramm auf einem externen Dienstrechner könnte dies sichergestellt werden, allerdings braucht das Darstellungsprogramm für das Buch keine Netzverbindung zu haben, was es dann unmöglich machen kann, das Formular abzuschicken. Selbst wenn eine Verbindung genutzt werden kann und die Antwort als XHTML oder SVG erstellt wird, ist keineswegs sicher, daß das Darstellungsprogramm solche Dokumente außerhalb der Buchstruktur auch darzustellen bereit ist.
Daher gibt es hier auch nur einen kurzen Überblick, auch weil sich neben Bewährtem mit HTML5 auch einige Ergänzungen, Streichungen und Änderungen ergeben.
Formulare stehen in einem Element form, beziehungsweise Formularelemente müssen eindeutig auf solch ein Element bezogen sein. Während form früher ein Blockelement war, kann es nun sowohl dort notiert werden, wo Blockelemente notiert werden können, als auch dort, wo Text oder Phrasenelemente notiert werden können.
form darf kein Element form als Nachfahren enthalten. Ansonsten empfiehlt es sich für eine sinnvolle Struktur konsistent zu bleiben, also entweder nur Blockelemente darin als Kindelemente zu notieren oder nur Phrasenelemente und Text. Dabei sollte für eine sinnvolle Struktur zudem darauf geachtet werden, daß dieser Inhalt von form zu dem Elternelement paßt, als wäre es transparent. HTML5 schreibt dies zwar nicht vor, eine ordentliche Struktur ist aber im Interesse des Lesers und des Autors.
Mit dem Attribut method wird die Methode angegeben, mit welcher das Formular verschickt wird. Mögliche Werte sind entweder 'get' oder 'post', wobei 'get' angenommen wird, falls das Attribut nicht notiert ist.
Mit dem Attribut action wird die Adresse identifiziert, zu welcher das Formular geschickt werden soll, zumeist also die eines Dienstprogrammes, welches das Formular auswerten kann. Anders als frühere Versionen ist es in HTML5 allerdings nicht notwendig, das Attribut zu setzen. Das Verhalten ohne action scheint allerdings undefiniert zu sein. Sicherlich kann solch ein Formular nicht erfolgreich abgesendet werden.
Mittels target kann ein Hinweis notiert werden, in welchem Anzeigebereich die Antwort des Dienstprogrammes angezeigt werden soll. Begrenzte Möglichkeiten des Darstellungsprogrammes können hier allerdings auch zu einem Abweichen von diesem Vorschlag führen, was dann die Nutzung durch den Leser erschweren kann. Die Bedeutung des Attributes ist die gleiche wie für das Element a.
Mit dem Attribut enctype kann angegeben werden, in welcher Struktur die Daten gesendet werden sollen, falls method='post'. Es gibt folgende Werte:
Bei einigen Eingaben sieht HTML5 vor, daß das Darstellungsprogramm prüft, ob die Eingabe dem entspricht, was der Autor für die jeweilige Eingabe festgelegt hat. Wenn nicht, kann das Formular nicht abgesendet werden. Falls allerdings das neue Attribut novalidate gesetzt ist, kann das Formular auch mit ungültigen Eingaben versendet werden. Der Wert des Attributes ist entweder leer oder 'novalidate'. Zu beachten ist dabei, daß Formulardaten auch immer auf anderem Wege ohne Kontrolle abgesendet werden können, die Daten müssen also ohnehin unabhängig vom adressierten Dienstprogramm analysiert werden.
Mit dem Attribut 'name' kann dem Formular ein Name gegeben werden, welcher nicht auch bei anderen Formularen im Dokument auftreten darf, also ähnlich wie 'id' geeignet ist, um das Formular eindeutig zu identifizieren.
Mit dem neuen Attribut autocomplete kann festgelegt werden, ob das Darstellungsprogramm aufgrund von gespeicherten Eingaben versuchen darf, das Formular automatisch auszufüllen. Mögliche Werte sind 'on' und 'off'. 'on' wird angenommen, wenn das Attribut nicht gesetzt ist. In dem Falle darf das Formular automatisch ausgefüllt werden, sonst nicht. Der Zweck besteht vorrangig darin, einerseits Nutzern Zeit zu sparen, die oft dasselbe Formular auszufüllen haben, andererseits aber durch die andere Einstellmöglichkeit sichergestellt werden kann, daß bei kritischen Informationen nicht fremde Personen das Formular automatisch ausfüllen lassen können, wenn ihnen das Darstellungsprogramm in die Hände fällt.
Mit 'accept-charset' kann angegeben werden, mit welchen Kodierungen die Daten gesendet werden dürfen. Es handelt sich um eine Leerzeichen-separierte Liste von Kodierungskürzeln. Wird das Attribut nicht verwendet, so wird die Kodierung des Dokumentes angenommen, bei EPUB also in der Regel 'UTF-8'. Sinnvoller Weise richtet sich die Angabe aber danach, was das Dienstprogramm erwartet, an welches die Formulardaten gesendet werden.
Eine Gruppe von zusammengehörigen Kontrollelementen und sonstigen Inhalten in einem Formular kann jeweils mit einem Element fieldset umschlossen werden. fieldset tritt oft als Nachfahre von form auf oder ist eindeutig mit einem Formular verknüpft, zu welchem es gehört. Es kann dort verwendet werden, wo Blockelemente, Phrasenelemente oder Text notiert werden dürfen. Auch hier ist im Sinne einer guten Struktur natürlich auch auf Konsistenz zu achten.
Mit dem neuen Attribut disabled kann angegeben werden, daß die komplette Gruppe deaktiviert ist. Die zugehörigen Eingaben können also weder geändert werden, noch können sie erfolgreich sein, werden also nicht abgesendet.
Sofern fieldset nicht in einem form steht oder einem anderen Formular zugeordnet werden soll, wird mit dem neuen Attribut form angegeben, zu welchem Formular es gehört. Der Wert ist dann der Name eines Formulars im Dokument, zu welchem das fieldset gehört. Entsprechend kann auch mit name für das fieldset selbst ein Name festgelegt werden.
Der Inhalt von fieldset besteht zunächst aus einem optionalen Element legend. Auf dieses folgt dann Inhalt, wie allgemein für Formulare erlaubt, also Blockelemente, Phrasenelemente, Text. Auch hier ist wieder auf eine gute Struktur zu achten.
Das Element legend kann als erstes Element von fieldset notiert werden. Es selbst enthält Text oder Phrasenelemente. Es dient dazu, der Gruppe eine Überschrift, Kennung oder Beschriftung zu geben.
Die Möglichkeit, Bestandteile eines Formulars außerhalb des Formulars zu notieren, ist nur mit großer Vorsicht sinnvoll nutzbar. Der Nutzer sollte immer klar den Überblick behalten können, welche Informationen er nun absendet und welche nicht zum abgesendeten Formular gehören. Eine einfache, zusammenhängende Struktur ist also vom Autor deutlich leichter so zu gestalten, daß sie vom Nutzer verstanden werden kann. Bei verstreuten Eingaben kann hingegen schnell die Übersicht verlorengehen.
Um Kontrollelemente eindeutig zu beschriften, wird das Element label verwendet. Neu ist auch hier wieder das Attribut form, mit dem angegeben werden kann, zu welchem Formular die Beschriftung gehört, sofern das Element nicht in dem Formular steht, zu dem es gehört.
Ansonsten gibt es wie gehabt zwei Verwendungsmodelle für label. Bei dem einen steht die Beschriftung zusammen mit dem Kontrollelement direkt in diesem Element. Bei dem anderen steht die Beschriftung im label und mit dem Attribut for wird das Kontrollelement referenziert, zu dem die Beschriftung gehört.
label gehört zu den Phrasenelementen und kann selbst Phrasenelemente, Kontrollelemente und Text enthalten. Ausgenommen sind weitere Elemente label als Inhalt.
Zu den bereits bekannten Kontrollelementen input (sofern type nicht 'hidden' ist), select, textarea und button kommen mit HTML5 weitere hinzu: keygen, meter, output, progress. Zudem wurde die Attributkollektion erheblich verändert und erweitert. Es handelt sich bei allen um Phrasenelemente, entweder inhaltsleer oder mit elementspezifischem Inhalt. Die Kollektion ist jedenfalls so umfangreich, daß sie angesichts der sehr begrenzten Anwendungsmöglichkeiten hier einstweilen nicht näher erläutert wird.
input ist das Basiskontrollelement. Mit den neuen Attributen können unter anderem etwa typische Eingaben kontrolliert werden. Mit select wird eine Auswahlliste mit vom Autor vorgegebenen Werten verfügbar gemacht. textarea dient der mehrzeiligen freien Texteingabe. button ist ein allgemeiner Knopf, insbesondere zum Absenden eines Formulars brauchbar. Mit kygen werden kryptographische Schlüsselpaare verfügbar gemacht. Mit meter wird eine skalare Meßgröße repräsentiert. Mit progress wird der Fortschritt einer Aufgabe oder Berechnung repräsentiert. output repräsentiert die Ausgabe einer Berechnung, die auf einer Nutzereingabe beruht.
HTML5 bietet neue interaktive Elemente an.
Davon ist dialog unbedingt zu vermeiden.
Im Laufe der Arbeitsentwürfe hat sich dessen Bedeutung komplett geändert.
Anfangs hat es sich um ein Element gehandelt, um Dialoge auszuzeichnen, wozu es bei späteren
Arbeitsentwürfen gar kein Element mehr gibt. Dann wurde es erst entsorgt und dann als
interaktives Element wieder eingeführt. Sofern überhaupt implementiert, kommt es bei der
Präsentation nahezu unvermeidlich zu katastrophalen Zugänglichkeitsproblemen.
Wird das Attribut open gesetzt, so kann der Inhalt den Inhalt
verdecken, der auf das Element folgt. Ist das Attribut nicht gesetzt, so wird der
Inhalt des Elementes nicht angezeigt. Eine deklarative Methode, um den Status von
open zu ändern, ist nicht vorgesehen.
Die andere interaktive Konstruktion ist besser durchdacht und hat eine ähnliche Funktion. Diese entspricht etwa dem, was häufig mit der Pseudoklasse :hover mit CSS erreicht wird - im Bedarfsfalle kann ein Nutzer durch Aktivierung eines kleinen sichtbaren Bereiches einen größeren Bereich darstellen lassen und durch deaktivieren wieder verschwinden lassen - etwa bei Aufklappmenüs realisiert oder bei der interaktiven Anzeige von Zusatzinformationen oder Hilfen.
Dies wird erreicht mit dem Element details. Es kann je nach Bedarf als Blockelement oder Phrasenelement eingesetzt werden. Der Inhalt besteht aus einem Element summary für eine Kurzzusammenfassung oder Überschrift, auf welches die Details folgen, die aus Blockelementen, Phrasenelementen oder Text bestehen können. Im Sinne einer guten Struktur sollte man sich hier allerdings entscheiden zwischen einerseits den Blockelementen und anderseits Text und Phrasenelementen. Die Entscheidung sollte auch davon abhängen, welche Kindelemente das Elternelement erlaubt oder sonst beinhaltet, wobei dann beim Inhalt von details auf Konsistenz geachtet werden sollte.
Mit dem Attribut open wird festgelegt, daß der komplette Inhalt von details dargestellt wird. Der Wert ist entweder leer oder 'open'. Ist das Attribut nicht gesetzt, wird nur summary dargestellt, sonst das komplette details. HTML5 legt nicht fest, wie der Zustand des Attributes interaktiv geändert werden kann. Das Darstellungsprogramm muß also eine Funktion bereitstellen, die dies dem Leser deklarativ ermöglicht. Typisch wäre etwa ein 'Aufklappen', wenn ein Zeigergerät über der summary ist oder der Fokus auf summary gesetzt wird.
Das Element summary kann Phrasenelemente oder Text enthalten.