Die Startseite

Die "klassische" Startseite eines Blogs listet üblicherweise die letzten Artikel auf, das passende Tag hierfür ist article.

    <article>
      <header>
        <h1>Titel des ersten Artikels</h1>
      </header>
      <div class="entry-content">
        <p>Dies ist ein erster Beispielartikel im
           Beispielblog. Sein einziger und
           ausschlie&szlig;licher Sinn ist es, nun ja, ein
           Beispielartikel zu sein. Mehr nicht. Keine wirklich
           schwere Aufgabe.</p>
        <p>In weiteren Artikeln wird vermutlich mehr passieren
           als nur so ein bi&szlig;chen Text wie hier. Wir
           werden sehen.</p>
      </div>
      <footer>
        <p>Geschrieben am
          <time datetime="2009-08-24T16:02+01:00"
            pubdate="pubdate">
            24. August 2009 um 16:02
          </time> Uhr von Autor.
          <a href="#">Kategorie 1</a>
        </p>
      </footer>
    </article>

Balsam für geschundene Semantikherzen von Webautoren: Im header des article findet sich der Artikel-Titel, jegliche Metainformation wandert in einen footer und dazwischen steht der eigentliche Artikelinhalt, hier zum Zweck der einfacheren Gestaltung in ein div verpackt.

Das Datum findet sich im neuen time-Element, durch pubdate wird gekennzeichnet, dass es das Veröffentlichungsdatum des Artikels ist.

Die Artikelseite

Typisch für die Einzelansicht eines Blogeintrages ist, dass das soeben erwähnte Markup der Eintrage um Kommentare zum Artikel sowie ein Kommentarformular ergänzt wird.

Auf den footer im obigen Codebeispiel folgt dabei zunächst der Abschnitt, welcher die Kommentare zum Artikel darstellt:

      <section id="kommentare">
        <header>
          <h1>Kommentare</h1>
        </header>
        <article>
          <header>
            <h2>Kommentator A schrieb am
              <time datetime="2009-08-25T11:17+01:00"
                pubdate="pubdate">
                25.08. um 11:17</time>:</h2>
          </header>
          <div class="kommentar-content">
            <p>Ein erster Testkommentar.</p>
          </div>
        </article>
        <article>
          <header>
            <h2>Kommentator B schrieb am
              <time datetime="2009-08-25T11:19+01:00"
                pubdate="pubdate">
                25.08. um 11:19</time>:</h2>
          </header>
          <div class="kommentar-content">
            <p>Noch ein Testkommentar.</p>
          </div>
        </article>
      </section>

Die Auszeichnung der Kommentare ist im Wesentlichen analog zur Auszeichnung der Blogeinträge — als verschachtelte article-Elemente wird ihr Bezug zum Elternartikel, innerhalb dessen sie einen eigenen Abschnitt (section) einnehmen, deutlich.

Grundsätzlich wäre natürlich durchaus denkbar, die Metadaten des Kommentars auch hier als footer des Kindartikels auszuzeichnen.

Eine weitere section enthält das Kommentarformular. Es unterscheidet sich lediglich durch Feinheiten von gängigen Kommentarformularen.

      <section id="kommentar-schreiben">
        <header>
          <h1>Kommentar schreiben</h1>
        </header>
        <p><strong>Hinweis:</strong> Hellgrün hinterlegte
          Formularfelder sind Pflichtfelder.</p>
        <form id="kommentar-formular" action="#">
          <fieldset id="benutzer-daten">
            <legend>Benutzerdaten</legend>
            <label for="benutzer-name">Name</label>
            <input id="benutzer-name"
              name="benutzer-name" required="required"
              size="22">
            <label for="benutzer-email">Email</label>
            <input id="benutzer-email"
              name="benutzer-email" type="email"
              required="required" size="22">
            <label for="benutzer-url">
              <abbr title="Uniform Resource Locator"
                lang="en">
                URL</abbr>
            </label>
            <input id="benutzer-url"
              name="benutzer-url" type="url"
              size="22">
          </fieldset>
          <fieldset id="benutzer-text">
            <legend>Ihre Nachricht</legend>
            <label for="benutzer-kommentar">
              Kommentar</label>
            <textarea id="benutzer-kommentar"
              name="benutzer-kommentar" required="required"
              rows="10" cols="30">
            </textarea>
          </fieldset>
          <input type="submit"
            value="Senden">
        </form>
      </section>
    </article>

Über das Attribut required sowie die neuen input-Typen email und url stellt HTML5 Mechanismen zur Überprüfung des Formulares bereit, welche bislang über das auswertende Skript gelöst werden mussten. Auch die Ausgestaltung entsprechender Felder wird möglich gemacht, etwa durch CSS-Anweisungen wie input[required].

Da gängige Screenreader das neue Attribut required noch nicht unterstützen, ist es empfehlenswert, einstweilen zusätzlich das entsprechende WAI-ARIA-Attribut aria-required zu verwenden.

Die Archivseite

Der Inhalt der Archivseite schließlich ist relativ unspektakulär ausgezeichnet — beide Archivvarianten als Kindsektionen samt eigenem header.

      <header>
        <h1>Archiv</h1>
      </header>
      <section id="nach-jahren">
        <header>
          <h1>Nach Jahren</h1>
        </header>
        <ul>
          <li><a href="#">2009</a></li>
          <li><a href="#">2008</a></li>
          <li><a href="#">2007</a></li>
          <li><a href="#">2006</a></li>
        </ul>
      </section>
      <section id="nach-kategorien">
        <header>
          <h1>Nach Kategorien</h1>
        </header>
        <ul>
          <li><a href="#">Dieses</a></li>
          <li><a href="#">Jenes</a></li>
          <li><a href="#">Welches</a></li>
        </ul>
      </section>

Hier stellt sich natürlich die Frage: section oder article? Die Spezifikation merkt dazu an, dass article vorzuziehen sei, wenn der Inhalt in einem Newsfeed angeboten werden soll. Das ist bei solchen Archivlisten sinnfrei, daher wurde hier section gewählt. Damit steht nun der grundsätzliche HTML5-Code für das neue Blog. Fehlen nur noch die Inhalte.

Zum Abschluss

In den anderen Teilen unserer Serie ist zu lesen, dass HTML5 noch nicht fertig ist. Wir werden gespannt beobachten, wie sich die Spezifikationen noch entwickeln werden. Neues über HTML5 gibt es in den kommenden Monaten sicher immer öfter zu lesen, unter anderem auch hier bei den Webkrauts.

Zum Autor:

Matthias Mees lebt in Eutin in Schleswig-Holstein – unter anderem auch davon, Webseiten zu gestalten. Er fühlt sich im Texteditor deutlich wohler als im Grafikprogramm und ist auch, aber nicht nur deswegen, Linux-Enthusiast.

So soll das Beispielblog aussehen:

Der Beispielcode sowohl in diesem Artikel als auch im Beispielblog ist dabei bewußt auf das Wesentliche reduziert und lediglich sparsam mit CSS ausgestaltet. Auch auf "verwendungsfähigen" Code für ein Template für eines der gängigen Blogsysteme wurde verzichtet. Der Fokus soll auf der korrekten Wahl der HTML5-Elemente liegen.

Als Beispielseiten dienen die Übersichtsseite eines Blogs, eine Einzelansicht eines Artikels inklusive Kommentaren und Kommentarformular sowie eine (sehr einfach gehaltene) Archivseite.

Das Grundgerüst

Das Grundgerüst bildet den gemeinsamen Rahmen aller drei Beispielseiten. Gehen wir den Code schrittweise durch.

<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="utf-8">
  <title>Beispielblog: HTML5 &bull; Startseite</title>
<!--[if IE]>
  <script src="http://html5shiv.googlecode.com/
     svn/trunk/html5.js" type="text/javascript">
  </script>
<![endif]-->
  <link rel="stylesheet" type="text/css"
     href="screen.css" media="screen,projection">
</head>

Ein — stark vereinfachter — Kopfbereich mit DOCTYPE, Angabe der Sprache des Dokumentes sowie des verwendeten Zeichensatzes, Titel des Dokumentes und Einbindung eines Stylesheets.

Das über Conditional Comments nur für den Internet Explorer eingebundene Javascript ist das HTML5 enabling script von Remy Sharp — es sorgt dafür, dass auch der IE die neuen HTML5-Elemente erkennt.

<body>
  <header>
    <h1><a href="index.html">Beispielblog:
        <abbr title="HyperText Markup Language">HTML</abbr>5
        </a></h1>
    <p>Anhand eines Blogs den Einsatz von
       HTML5 demonstrieren</p>
  </header>

Auf das öffnende Tag des body-Elementes folgt mit #kopfbereich ein header-Element als Seitenkopf oder Banner, in welchem der Titel des Blogs als Überschrift erster Ordnung sowie eine Blogbeschreibung stehen.

  <div id="inhalt">
  <!-- Inhaltsbereich -->
  </div>

Dieser relativ unspektakuläre Teil bildet den Inhaltsbereich des Blogs, welcher im zweiten Teil dieses Artikel mit den eigentlichen Inhalten (abhängig von der betreffenden Seite des Blogs) befüllt werden wird. Es gibt derzeit kein semantisch passendes Element für den Hauptinhalt, also bedienen wir uns des bewährten div-Containers.

Die Spezifikation schlägt — derzeit — ausdrücklich vor, für Seitenleisten in Blogs das aside-Element als Container zu verwenden:

<aside id="seitenleiste">
  <nav>
    <h2>Hauptnavigation</h2>
    <ul>
      <li><a href="index.html">Startseite</a></li>
      <li><a href="einzel.html">
          Einzelansicht eines Artikels</a></li>
      <li><a href="archiv.html">Archiv</a></li>
    </ul>
  </nav>

Die Hauptnavigation wird als ungeordnete Liste ausgezeichnet, als Container-Element dient das neue nav-Element. Somit ist semantisch deutlich, dass es sich hier um die primäre Navigation des Blogs handelt.

Es folgt ein Suchformular.

    <form id="suchformular">
      <fieldset>
        <legend>Suche</legend>
        <label for="suchbegriff" class="invisible">
          Suchbegriff(e) eingeben
        </label>
        <input name="suchbegriff"
          id="suchbegriff" type="search"
          size="15">
        <input type="submit" value="Suche">
      </fieldset>
    </form>

Hier nutzen wir ein neuen input-Typ für die Suche. Im form-Element können method="get" auslassen, da es automatisch eingesetzt wird, falls keine genauere Anweisung vorliegt.

Abschließend noch eine Liste der Kategorien als zusätzliche Navigationshilfe in der Seitenleiste — ebenfalls mit dem passenden Element nav ausgezeichnet.

    <nav>
      <h2>Kategorien</h2>
      <ul>
        <li><a href="#">Kategorie 1</a></li>
        <li><a href="#">Kategorie 2</a></li>
        <li><a href="#">Kategorie 3</a></li>
      </ul>
    </nav>
  </aside>

Den Abschluss des Grundgerüstes bildet ein Seitenfuß, welcher mit dem neuen Element footer ausgezeichnet wird.

  <footer>
    <p>&copy; 2009 Autor &bull; <a href="#">Impressum</a></p>
  </footer>
</body>
</html>

Im zweiten Teil wird dann der oben leer gelassene Inhaltsbereich abhängig von der jeweiligen Seite mit Inhalten befüllt.

Zum Autor:

Matthias Mees lebt in Eutin in Schleswig-Holstein – unter anderem auch davon, Webseiten zu gestalten. Er fühlt sich im Texteditor deutlich wohler als im Grafikprogramm und ist auch, aber nicht nur deswegen, Linux-Enthusiast.

Die folgenden Codebeispiele gibt es gesammelt als zip-Datei.

Übersicht der neuen <input>-Typen

Das input-Element ist ein Feld, in das der Nutzer einer Internetseite Daten eintragen kann. Das type-Attribut kontrolliert die Art der Dateneingabe und bedingt auch weitere mit diesem Typen verbundene Attribute. Die folgende Tabelle zeigt die neuen input-Typen gemäß des Working Draft der WHATWG Spezifikation.

Viele der neuen input-Typen funktionieren bisher nur im Opera Browser Version 10: url, email, datetime, date, month, week, time, datetime-local, number und range. Die input-Typen search und color werden derzeit von keinem Browser unterstützt.

Übersicht der neuen Attribute

Mit der Entwicklung von HTML5 wurden auch die Attribute aktuellen Anforderungen angepasst und neue Attribute geschaffen: autocomplete, autofocus, form, inputmode, list, max, min, pattern, replace, required, step und template.

Eine vollständige Liste aller Attribute wird bereitgestellt unter w3schools.com.

Zwei dieser Attribute sind allen neuen input-Typen zugeordnet: autocomplete und list.

Ersteres, von Opera auch die »Google-Suggest-Funktion« genannt, bietet die Möglichkeit der Autovervollständigung eines input-Feldes. Es ist per default aktiviert und lässt sich durch den Wert off deaktivieren. Das ist besonders beim input type="search" interessant, da so im deaktivierten Zustand die Google-Suggest-Funktion umgangen werden kann. Das Attribut hilft im aktivierten Zustand aber auch bei der Vervollständigung der URL oder der E-Mail-Adresse.

Das list-Attribut steht im Zusammenhang mit einem DropDown-Menü, wie hier im Codebeispiel zu sehen und kann ebenso auf alle anderen input-Typen angewandt werden. So entstehen zum Beispiel Listen für Suchanfragen, URL-Listen, E-Mail-Listen oder auch diverse Listen für Zeitangaben.

<input list="input_types" name="input_types">
<datalist id="input_types">
  <option value="search"></option>
  <option value="url"></option>
  <option value="email"></option>
</datalist>

Der input-Typ search

Codebeispiel

<input type="search">

Attribute

autocomplete, list, maxlength, pattern, placeholder, readonly, required, size, selectedOption, select(), selectionStart, selectionEnd, setSelectionRange(), input event, change event

Anwendungsbeispiele

Da der Typ search noch in keinem Browser funktioniert, ist es noch nicht möglich Anwendungsbeispiele zu zeigen.

Sinn dieses Elements ist es jedoch, ein Suchfeld in einem Internetauftritt zu identifizieren und es so von einem normalen Textfeld zu unterscheiden. Vom Verhalten her gleicht der Typ search dem Typ text.

So könnte beispielsweise das Suchfeld mit dem Attribut list um eine Liste von häufigen Suchbegriffen erweitert oder durch das Attribut pattern einem Muster unterworfen werden, dem die Suchanfragen genügen sollten.

Der input-Typ url

Codebeispiel

<input type="url">

Screenshot

Attribute

autocomplete, list, maxlength, pattern, placeholder, readonly, required, size, selectedOption, select(), selectionStart, selectionEnd, setSelectionRange(), input event, change event

Anwendungsbeispiele

Wird dem Typ url das required-Attribut hinzugefügt, überprüft der Browser automatisch die Semantik der eingegeben Internetadresse. Die Standardeinstellung erfordert ein http:// vor der eigentlichen Adresse. Jedes andere Format wird als Fehler ausgegeben.

Ebenso kann das Element mit dem list-Attribut durch eine Liste von vorgegeben Internetadressen erweitert werden. Diese werden angezeigt, sobald der User in das Feld hineinklickt.

Der input-Typ email

Codebeispiel

<input type="email">

Screenshot

Attribute

autocomplete, list, maxlength, multiple, pattern, placeholder, readonly, required, size, selectedOption, select(), selectionStart, selectionEnd, setSelectionRange(), input event, change event

Anwendungsbeispiele

Durch Hinzufügen des Attibuts required wird das E-Mail-Feld zum Pflichtfeld und beim Abschicken des Formulars abgefragt. Ist es nicht ausgefüllt, erscheint eine Fehlermeldung:

Eine große Arbeitserleichterung ist meiner Meinung nach das Attribut pattern. Hiermit kann dem input-Element zusätzlich ein Muster zur Verfügung gestellt werden, welches abgefragt wird und so die Semantik der E-Mail-Adresse beeinflusst.

Hier das Codebeispiel inklusive des Screenshots mit der Fehlermeldung, die ausgelöst wird, wenn die Logik des Musters nicht eingehalten wird.

<input type="email" required="required"
  pattern="([\w]+)(([-\.][\w]+)?)
     *@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)
     |(([\w-]+\.)+))([a-zA-Z]{2,4}
     |[0-9]{1,3})(\]?)"
  name="email">

J. David Eisenberg nutzt das pattern-Attribut in dem Artikel »Get ready for HTML5« von A List Apart auch als Muster für ein Postleitzahlenfeld. Hierfür fügt er einfach einem normalen Textfeld das Attribut pattern hinzu und erweitert dieses noch durch ein Attribut title, das einen Hinweis auf die korrekte Schreibweise enthält. Das Hinzufügen des Attributs title ist allerdings nur bei einem normalen Textfeld möglich.

<p>Enter a US or Canadian Postal Code:
<input type="text" name="postCode"
required="required"
pattern="([0-9]{5}(-[0-9]{4})?)
  |([0-9][A-Z][0-9]\s+[A-Z][0-9][A-Z])"
title="US: 99999-1234; Canadian: 0A1 B2C;" />
</p> 

Das Kalender-Widget

Eine Kalenderfunktion auf der Internetseite ist eine sehr praktische Sache. Gleich fünf der neuen input-Typen warten mit diesem Feature auf. Schade ist nur, dass es sämtlichen Versuchen widersteht, sich grafisch anpassen zu lassen. Einzig elementare Dinge, wie die Schriftgröße und Farbe lassen sich ändern. Die Farbe allerdings auch nur im input-Feld direkt und nicht im Kalender-Widget selbst. Dort sind nur die Schaltflächen »Heute« und »Keins« betroffen.

Ob Designer sich mit diesen eingeschränkten Gestaltungsmöglichkeiten zufrieden geben werden ist fraglich. Vielleicht wird in der zukünftigen Entwicklung der input-Elemente noch die Möglichkeit berücksichtigt, die einzelnen Felder individuell gestalten zu können, aktuell ist es jedoch nicht so. Aus dem gestalterischen Blickwinkel stellt sich die Frage, ob die Typen datetime, datetime-local, date, month und week dann überhaupt angenommen werden.

Da die Entwicklung von HTML5 allerdings noch nicht abgeschlossen ist, besteht die Möglichkeit, dass die gestalterische Anpassung des Kalenders noch nachträglich hinzugefügt wird.

Der input-Typ datetime

Codebeispiel

<input type="datetime">

Screenshot

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsDate, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ datetime verfügt als einziges der neuen Zeit/Datum-Elemente über die Angabe einer Zeitzone. Diese bezieht das input-Element aus der Systemzeit. Die Möglichkeit, die aktuelle Zeit mitzugeben, funktioniert noch nicht.

Der input-Typ datetime-local

Codebeispiel

<input type="datetime-local">

Screenshot

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ datetime-local funktioniert analog zum Typ datetime, gibt aber nur die lokale Zeit aus – ohne die Nennung der Zeitzone. Es ist möglich, dass datetime-local im Laufe der Entwicklung von HTML5 ein Teil von datetime wird und die Zeitzone als Attribut hinzugefügt werden kann, da sich die beiden Typen nur in der genannten Eigenschaft unterscheiden.

Die input-Typen date, month und week

Codebeispiele

<input type="date">
<input type="month">
<input type="week">

Screenshots

Screenshot vom neuen Input-Typ date, month und week ohne Kalenderwidget

Screenshot vom neuen Input-Typ date mit Kalenderwidget

Screenshot vom neuen Input-Typ month mit Kalenderwidget

Screenshot vom neuen Input-Typ week mit Kalenderwidget

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsDate, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ date funktioniert analog zum Typ datetime, gibt aber anstelle eines Datums inklusive der Uhrzeit nur das Datum (Jahr-Monat-Tag) aus. Der Typ month funktioniert analog zum Typ date, ist aber auf den Monat und das Jahr beschränkt. Der Typ week schließlich funktioniert analog zum Typ date, gibt aber anstelle eines Datums die Kalenderwoche aus.

Der input-Typ time

Codebeispiel

<input type="time">

Screenshots

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsDate, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ time zeigt eine Uhrzeit an, die standardmäßig in Sekundenschritten hoch- oder runtergezählt wird. Mit dem Attribut step kann die Uhrzeit bis auf Millisekunden genau eingestellt werden und bietet so genügend Freiraum zur Modifizierung.

Der input-Typ number

Codebeispiel

<input type="number">

Screenshot

Attribute

autocomplete, list, max, min, readonly, required, step, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ number eignet sich für die Eingabe verschiedener Zahlenwerte. Durch das Attribut step kann das Zählintervall beeinflusst werden und durch die Attribute min und max kann der Bereich abgesteckt werden, in dem sich die ausgewählte Zahl befinden soll.

Der Screenshot zeigt das input-Feld number, wenn das Attribut step den Wert 0.001 hat.
Standardmäßig ist dem Attribut step der Wert 1 zugeordnet, sowie dem Attribut min 0 und dem Attribut max 100.

Der input-Typ range

Codebeispiel

<input type="range" min="2000" max="2050" value="2009" onInput="year.value=value">
<output name="year"></output>

Screenshot

Attribute

autocomplete, list, max, min, step, valueAsNumber, selectedOption, stepDown, stepUp, input event, change event

Anwendungsbeispiele

Der Typ range funktioniert analog zum Typ number, nur dass er zum einen weniger Attribute besitzt und zum anderen, wie im Screenshot zu sehen, eine andere grafische Ausgabe. Zudem kommt der Typ mit dem neuen output-Element daher, das den durch den Schieberegler erzeugten Wert ausgibt.

Da dieser Typ auch in den Webforms2 von Weston Ruter nicht aufgegriffen wird (siehe unten) und auch das Element output dort keine Verwendung findet, kann man die Schiebereglerfunktion im Alltag noch nicht verwenden. Für die Zukunft bietet dieser Regler allerdings eine interessante grafische Variante zur Darstellung von Zahlenwerten. Da auch dieses Element noch nicht grafisch anpassbar ist, stellt sich allerdings auch hier die Frage, ob sich die Verwendung dieses Reglers durchsetzen wird.

Der input-Typ color

Codebeispiel

<input type="color">

Attribute

autocomplete, list, selectedOption, input event, change event

Anwendungsbeispiele

Da der Typ color noch in keinem Browser funktioniert, ist es noch nicht möglich, Anwendungsbeispiele zu zeigen. Gedacht ist dieser Typ als Farbauswahlfeld auf 8-bit-Basis. Das bedeutet, dass voreingestellte Hexadezimalwerte ausgewählt werden können, die einem bestimmten Farbwert entsprechen. Es ist immer automatisch ein Farbwert ausgewählt, denn dieses Feld darf per Definition niemals leer sein. Wird ein invalider Wert eingegeben, wird der Inhalt des Feldes automatisch auf #000000 gesetzt.

Und die anderen Browser?

Da die neuen input-Typen bisher nur im Opera 10 funktionieren, stellt sich natürlich die berechtigte Frage, ob diese schon mit dem ein oder anderen Workaround in anderen Browsern genutzt werden können.

Weston Ruter hat über Google Code die Webforms2 zur Verfügung gestellt, welche es ermöglichen, die neuen Typen auch schon in folgenden Browsern zu nutzen:

• Mozilla Firefox 1.0.8
• Mozilla Firefox 1.5.0.9
• Mozilla Firefox 2
• Internet Explorer 6
• Internet Explorer 7
• Safari 2.0.4
• Safari 3 (Windows)

Die oben genannten Browser wurden laut Weston Ruter getestet; ich kann hinzufügen, dass der Firefox 3.5 mit den Webforms2 kompatibel ist.

Obwohl diese Lösung natürlich unkompliziert und sehr vorteilhaft ist, ist sie dennoch bloß der Krückstock unter den Gehhilfen. Solange einem nichts besseres bekannt ist, ist es auch in Ordnung; hat der User aber den Vergleich im Opera 10 gesehen, ist der Unterschied offensichtlich. Es soll natürlich auch nur eine Übergangslösung sein, bis alle Browser die HTML5 Standards integriert haben. Dennoch gibt es genügend Kritikpunkte.

Zunächst einmal übernehmen die Webforms2 nicht die grafischen Unterscheidungen der input-Felder. Das bedeutet, dass jeder Typ wie ein normales Textfeld aussieht. Die einzelnen Widgets, zum Beispiel beim Typ datetime wurden auch noch nicht umgesetzt, was wiederum bedeutet, dass diese Felder wie ein normales Textfeld reagieren. Es gibt einen Workaround für den Typ date, der aber durch eine CSS-Datei erst gestylt werden muss, das heißt, dass das Webforms2-Standardmodell dem HTML5-Standardmodell nicht gerade ähnlich sieht. Hier ist noch viel Eigeninitiative gefragt. Ebenso wenig funktionieren die Typen time, number und range. Hierfür gibt es auch noch keine Javascript-Workarounds.

Die Fehlermeldungen sind standardmäßig in englischer Sprache. Sie können aber im Javascript in die gewünschte Sprache umgeschrieben werden. Javascript ist natürlich der nächste Punkt: Wer es ausgeschaltet hat, wird automatisch ausgeschlossen. Damit fallen die Webforms2 in einen experimentellen und nicht alltagstauglichen Bereich, der gegen eine offizielle Benutzung spricht.

Die Webforms2 unterstützen auch noch nicht alle neuen Attribute. Bisher integriert sind die Attribute pattern, required, min und max, step und das autofocus. Da das list-Attribut noch nicht unterstützt wird, funktioniert mein Beispiel dazu auch nur im Opera 10.

Das Einbinden der Webforms2 behindert die standardmäßige Interpretation des Opera 10 nicht, von daher kann dies bedenkenlos getan werden. Will der Webworker jedoch auf Nummer Sicher gehen und keinen Nutzer ausschließen, sollte er mit der Verwendung der neuen input-Typen besser bis zur Integration in allen Browser warten. Denn trotz aller schönen Neuerungen ist der Opera nur ein Nischenprodukt.

Diese Einschränkungen machen die neuen input-Typen und die Attribute zu Versuchsobjekten und verhindern eine weite Verbreitung und öffentliche Nutzung.

Fazit:

Die neuen input-Typen sind vielversprechend und kommen mit vielen neuen Features daher, die jeden Internetauftritt aufwerten können. Der Code ist schlank und durch die neuen Attribute können viele Javascript-Lösungen, etwa zur Pflichtfeldabfrage oder zur Syntax einer E-Mail-Adresse, eingespart werden.

Dennoch werden die neuen Typen wohl erst in ferner Zukunft vermehrt genutzt werden, denn der bisherige Workaround mit den Webforms2 ist alles andere als befriedigend. Hier bleibt einem nichts anderes übrig, als darauf zu warten, dass die input-Typen bald in allen gängigen Browsern integriert werden. Oder aber der ambitionierte Webworker schreibt sich auf Basis der Webforms2 einfach seine eigenen Workarounds.

Das kann jedoch nicht die Lösung sein und so wird es nun wohl zunächst nur zu einer Arbeitserleichterung durch die Attribute required und pattern kommen – und das auch nur durch ein Javascript-Workaround.

Ich persönlich bin gespannt, was die Zukunft in Sachen HTML5 noch bringen wird und bin mit meiner Spannung auch nicht allein. Sowohl in der neuen Weave als auch in dem Artikel von J. David Eisenberg auf A List Apart und auch noch in vielen anderen Diskussionen im World Wide Web, kann man lesen, dass Spannung in der Luft liegt.

»Although some developers have reservations about the direction in which HTML5 is taking the web (and although I share these reservations), HTML5 has enough new and interesting features to be well worth exploring. So, start looking at other people’s markup, experiment on your own, and go wild with the new form validation and canvas features.«

Und mit diesen Worten von J. David Eisenberg möchte ich auch schließen. Experimentiert selbst ein wenig mit den neuen input-Typen und bildet euch euer eigenes Urteil – ihr werdet es nicht bereuen.

Zur Autorin:

Stefanie Rückert macht sich mit ihrem Hang zur Usability auch gerne mal unbeliebt und engagiert sich, wann immer es geht, für Webstandards.

Das Element ermöglicht Zeichenoperationen, mit Hilfe derer wir (fast) beliebige geometrische Formen und Pfade zeichnen können. Dies ermöglicht beispielsweise die Erstellung von Charts und/oder Diagrammen, die durch dynamische Werteangaben beim Laden einer Seite unmittelbar erstellt werden. Zum anderen bietet das Element umfangreiche Möglichkeiten zur Komposition, Animation und Manipulation von Bilder und Grafiken und auch Filmen.

Sozusagen zum Leben erweckt wird das initial leere Element durch die DOM Methoden, die das Element in großer Anzahl bereitstellt. Diese sind über eine Script-Schnittstelle (Javascript) ansprechbar.

Die Komplexität der Anwendungsmöglichkeiten bedingt es dann auch, dass in diesem Artikel nur grundlegende Beispiele beschrieben werden und am Ende auf lesens- und sehenswerte Seiten verwiesen wird.

Browser-Unterstützung

Alle Browser mit mind. Gecko 1.8 Engine (Firefox ab 1.5), Safari ab 3.x, Opera ab 9.x und der aktuelle Google-Browser Chrome unterstützen das canvas Element. Der Internet Explorer interpretiert das Element noch nicht. Über eine Javascript Lösung kann man dem IE hier Beine machen.

Einbindung

Quelltext: Einbindung des Element canvas

<canvas id="sample" width="290" height="150">
  Ihr Browser unterstützt das Element
    <code>canvas</code> nicht.
</canvas>

Das Element¹ hat lediglich zwei optionale Attribute (width, height). Werden diese nicht gesetzt, wird es mit einer Weite von 300 Pixel und einer Höhe von 150 Pixel initialisiert. Die Definition des globalen Attributes id ist diesem Zusammenhang sinnvoll, um das Element in einem Scriptkontext gezielt ansprechen zu können.

Das Element canvas kann über CSS gestylt werden. Die Deklarationen beziehen sich dabei alleine auf den Element-Container. Die innerhalb des Elementes ausgeführten Operationen bleiben hiervon unberührt. In seinem Standardzustand wird das Element transparent angezeigt.

Wie bei den Elementen video und audio wird ein Fallback unterstützt. Ist einem Browser das Element unbekannt, wird der innerhalb des Start- und End-Tag liegende Inhalt angezeigt. Unterstützt der Browser das Element, wird der alternative Inhalt ignoriert und die Operationen innerhalb des Elementes werden ausgeführt.

Raster und Koordinatensystem

Bevor wir anfangen, uns konkreten Beispielen zuzuwenden, ein paar Worte zum Raster, auf das sich sämtliche Koordinaten unserer späteren Anwendungen beziehen.

Bild: Grafische Darstellung des Rasters/Koordinatensystems

Ausgangspunkt der Positionierung aller Elementen ist immer die obere linke Ecke des Rasters (0,0). So beschreibt X immer den Abstand zum linken, Y den zum oberen Rand des Rasters. Da dies für einige Anwendungen nicht wirklich ausreichend ist, gehe ich zu einem späteren Zeitpunkt auf die Möglichkeit ein, diese relative Fixierung zu umgehen.

Formen und Pfade

Das canvas Element stellt eine oder mehrere pixelbasierte Zeichenebenen bereit, die in einem drei- oder zweidimensionalen Kontext gerendert werden. Hiermit ist es unter anderen möglich, Tabellen und Diagramme dynamisiert zu zeichnen, aber auch einfache Animationen zu erstellen. Aufgrund einer bislang nicht eindeutigen Spezifikation der Schnittstelle für den 3D Kontext, konzentriere ich mich im folgenden auf die Möglichkeiten der zweidimensionalen Darstellung.

Quelltext: Initialisieren des Elementes canvas im Script-Kontext

<script>
var canvas = document.getElementById('sample');
var ctx = canvas.getContext('2d');
}
</script>

Um Operationen auszuführen, muss in einem ersten Schritt über die bereitgestellten DOM Methode getContext() des Elementes canvas der Darstellungskontext definiert werden. Die genannte DOM Methode benötigt als Paramenter den Typ des Darstellungkontextes. Hier setzen wir das Definitionskürzel für den zweidimensionalen Kontext ein.

Rechtecke

canvas unterstützt  – im Gegensatz zu SVG  – nur das Rechteck als unmittelbar zu zeichnende Form. Um daraus ableitende geometrische Formen zu ermöglichen wie Kreise, Dreiecke und komplexe Kombinationen aus beiden, müssen Pfade kombiniert werden. Hierzu weiter unten im Artikel mehr.

Rechtecke werden über folgende DOM Methoden des Elementes canvas erstellt:

Quelltext Beispiel 1: Rechtecke zeichnen

<!DOCTYPE html>
<head>
<meta charset="UTF-8">
<script type="text/javascript">
function zeichne() {
  var canvas = document.getElementById('sample');
  if (canvas.getContext) {
  var ctx = canvas.getContext('2d');

    ctx.fillStyle = "rgba(30,144,255,0.5)";
    ctx.fillRect (10, 10, 120, 120);

    ctx.fillStyle = "rgba(30,144,255,0.7)";
    ctx.fillRect (70, 30, 120, 120);

    ctx.fillStyle = "#1E90FF";
    ctx.fillRect(230, 10, 120, 120);
    ctx.clearRect(250, 30, 80, 80);
    ctx.strokeRect(255, 35, 70, 70);
  }
}
</script>
</head>

<body onload="zeichne();">

<canvas id="sample" width="460" height="150">
  Ihr Browser unterstützt das Element
  <code>canvas</code> nicht.
</canvas>

</body>
</html>

Beispiel 1: Rechtecke zeichnen

Für die Beispiele des Artikels nutzen wir im head einen Script-Tag. Dort legen wir eine Funktion zeichne() an und überprüfen als Erstes, ob das Element canvas dem Browser bekannt ist, in dem wir stellvertretend das Vorhandensein der Methode getContext() abfragen. Anschließend initialisieren wir das Element canvas mit dem zuvor erwähnten zweidimensionalen Kontext, um als nächstes die Anweisungen der Funktion zu schreiben. Um sie unmittelbar nach dem Laden der Seite auszuführen, nutzen wir das onload Event des Body-Tags. In den nachfolgenden Beispielen wird auf die wiederholte Listung dieses Grundaufbaus verzichtet.

Wie im Quelltext zu sehen, wird zusätzlich noch die Methode fillStyle() einsetzt. Hiermit wird die Füllfarbe des gezeichneten Objektes angegeben. Im Abschnitt Farben und Transparenzen gehe ich näher auf Methoden ein, die sich mit der farblichen Gestaltung der Objekte befassen.

Pfade

Während die Methoden zur Erstellung von Rechtecken das gezeichnete Element ohne weitere, explizite Anweisungen zeichnen, ist es beim Zeichnen von Pfaden erforderlich, dem Element canvas deutlich zu machen, wo ein Pfad beginnt, wo er aufhört und in welcher Art und Weise er schließlich gezeichnet werden soll. Hierzu dienen folgende, parameterlose Funktionaufrufe:

Mit beginPath() wird ein neuer Pfad eingeleitet. Zu beachten ist hierbei, dass der Pfad zu dem Zeitpunkt noch nicht tatsächlich gezeichnet wird. Hierzu nutzt man im Anschluß die Methode stroke() oder/und fill(). Wird fill() eingesetzt, ist ein dezidiertes Schließen des Pfades über closePath() nicht erforderlich, da die Methode die Zeichenoperationen automatisch beendet.

Zeichnen wir als erstes Beispiel eine einfaches Dreieck.

Quelltext Beispiel 2: Pfad zeichnen (Dreieck)

ctx.beginPath();
ctx.fillStyle = "rgb(30,144,255)";
ctx.moveTo(10,10);
ctx.lineTo(100,10);
ctx.lineTo(10,100);
ctx.fill();

Beispiel 2: Pfad zeichnen (Dreieck)

Schauen wir uns das letzte Beispiel an, sehen wir, dass zwei noch unbekannte Methoden verwandt werden:

Mit moveTo(x,y) wird festgelegt, an welcher Koordinate (x,y) die nachfolgende Zeichenoperation begonnen werden soll. Der Startpunkt des aktuellen Pfades schließt automatisch an dem Endpunkt des vorherigen Pfades an. Gleichzeitig definiert der Endpunkt des aktuellen Pfades immer auch den Startpunkt eines nachfolgenden Pfades. Mit der Funktion lineTo(x,y) wird die eigentliche Linie gezeichnet.

Neben Linien gibt es dankenswerter Weise auch eine direkte Methode zur Definition von Kreisen (oder besser: gebogenen Linien), die mit arc() benannt ist.

Parameter x und y beschreiben die Koordination des Kreises bezogen auf den Mittelpunkt des Kreis. Der radius bestimmt den Umfang des Kreises, startAngle und endAngle legen den Beginn und das Ende des Kreispfades anhand der X-Koordinate fest. Der boolsche Paramenter anticlockwise bestimmt, ob unser Kreis im oder gegen den Uhrzeigersinn gezeichnet wird.

Quelltext Beispiel 3: Kreis zeichnen

ctx.beginPath();
ctx.fillStyle = "rgba(30,144,255,0.5)";
ctx.strokeStyle = "rgba(30,144,255,1)";
ctx.arc(70,80,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();
ctx.stroke();

Beispiel 3: Kreis zeichnen

Hinweis: Durch die Parameterangabe Math.PI*2 wird ein geschlossener Kreis erzeugt. Um Teilkreise zu erstellen, kann dieser Parameter angepasst werden.

Auch Bezier-Kurven (quadraticCurveTo(), bezierCurveTo()) können über bereitgestellte Methoden gezeichnet werden. Deren detailierte Anwendung wird hier aber nicht beschrieben, da dieses den Rahmen des Artikels sprengen würde. Details zu Anwendung und Parameter findest du auf den am Ende des Artikels gelisteten Seiten.

Gleiches gilt für weitere, hier nicht erwähnte Methoden, die das Element canvas bereitstellt. Zu erwähnen sind hier besonders die Möglichkeit Verläufe zu definieren, Schatten zu erzeugen und Methoden um Objekte zu transformatieren und skalieren.

Bilder und Grafiken

Spannend ist auch die Fähigkeit des Elementes canvas, Bilder/Grafiken und Zeichenoperationen zu kombinieren und sie zu einer Ansicht zusammenzufügen. Methoden zum Schneiden und Skalieren eines Bildes oder einer Grafik werden ebenfalls bereitgestellt.

Um ein Bild oder eine Grafik innerhalb des canvas zu referenzieren, gibt es verschiedene Methoden. Eine davon ist die Erzeugung eines neues Bildes über das DOM Objekt Image.

Quelltext: Erstellen eines Bildes anhand des DOM Objekt Image

var img = new Image();
img.onload = function(){
  Hier definieren wir später die Funktionen/Methoden
}
img.src = 'koordinaten-hintergrund.png';

Da unsere Funktion nicht vor dem vollständigen Laden des neuen Bildes ausgeführt werden sollen, wird deren Ausführung an den onload Event Handler des Image Elementes gebunden. Die hier genutzte Grafik koordinaten-hintergrund.png ist in dem Fall unsere Bezugsdatei, über die wir unseren Pfad zeichen wollen. Zur Einbindung nutzen wir die Methode drawImage().

Während die Koordinaten x und y für die Positionierung auf der Leinwand zuständig sind, beinhaltet der Parameter image die Referenz unseres Bildes/unserer Grafik oder eines anderen canvas Objektes.

Zu Beispiel 4: Referenzierte Grafik

Quelltext Beispiel 4: Bild/Grafik und Pfad kombinieren

function zeichne() {
  var canvas = document.getElementById('sample');
  if (canvas.getContext) {
    var ctx = canvas.getContext('2d');
    var img = new Image();
    img.onload = function(){
      ctx.drawImage(img,0,0);
      ctx.beginPath();
      ctx.strokeStyle = "rgb(30,144,255)";
      ctx.moveTo(40,146);
      ctx.lineTo(100,96);
      ctx.lineTo(140,126);
      ctx.lineTo(170,62);
      ctx.lineTo(210,100);
      ctx.lineTo(240,32);
      ctx.stroke();
    }
    img.src = 'koordinaten-hintergrund.png';
  }
}

Beispiel 4: Bild/Grafik und Pfad kombinieren

Farben und Transparenzen

In nahezu allen bisherigen Beispielen werden die Methoden fillStyle() oder/und strokeStyle() verwandt. Hiermit geben wir unseren Formen und Pfaden den farblichen Anstrich.

Verschiedene Notationen der Farben sind möglich, die auf der Spezifikation des W3C Farbmoduls basieren. Folgende Notationen sind in Ihrer Ausgabe identisch:

Quelltext: Werteangaben und Notationen für Farben

ctx.fillStyle = "dodgerblue";
ctx.fillStyle = "#1E90FF";
ctx.fillStyle = "rgb(30,144,255)";
ctx.fillStyle = "rgba(30,144,255,1)";

Das W3C Farbmodul erlaubt auch eine Notation im HSL(A) Format. Dieses wird aber bislang nur unzureichend von wichtigen Browsern unterstützt.

Hinweis: Definiert man eine Farbangabe, ist diese für alle Elemente gültig. Möchte man verschiedenfarbige Elemente haben, muss sie explizit für jedes Element überschrieben, respektive neu gesetzt werden.

Über rgba und der canvas Methode globalAlpha haben wir zwei Möglichkeiten, Transparenzen zu nutzen. Schauen wir uns zuerst die rgba Notation an.

Quelltext: Transparenzen über die rgba Notation

ctx.fillStyle = "rgba(30,144,255,0.5)";
ctx.fillStyle = "rgba(30,144,255,1)";

Die Notation innerhalb rgba ist identisch mit der von rgb, hat aber einen zusätzlichen Parameter am Ende der Notation. Der letzte Parameter bestimmt die Sichtbarkeit des Elementes, wobei 1.0 vollständige Deckung, 0.0 vollständige Transparenz bedeutet.

Quelltext Beispiel 5: Transparente Kreise mit rgba Notation

ctx.beginPath();
ctx.fillStyle = "rgba(30,144,255,0.4)";
ctx.arc(70,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

ctx.beginPath();
ctx.fillStyle = "rgba(30,144,255,0.7)";
ctx.arc(120,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

Beispiel 5: Transparente Kreise mit rgba Notation

Die zweite Möglichkeit, die elementunabhängige Definition über die Methode globalAlpha(), macht es möglich, übergreifend für alle Elemente der Leinwand einen Standardwert für Transparenzen zu setzen, der alle Farbangaben beeinflußt.

Der Wertebereich liegt auch hier zwischen 1.0 (vollständige Deckung) und 0.0 (vollständige Transparenz).

Quelltext Beispiel 6: Transparente Kreise mit Methode globalAlpha()

ctx.globalAlpha = 0.5;

ctx.beginPath();
ctx.fillStyle = "#1E90FF";
ctx.arc(70,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

ctx.beginPath();
ctx.fillStyle = "#1E90FF";
ctx.arc(120,75,65,0,Math.PI*2,true);
ctx.closePath();
ctx.fill();

Beispiel 6: Transparente Kreise mit Methode globalAlpha()

Animationen

Durch die Bindung des Elementes canvas an DOM Methoden, die über eine Script-Schnittelle nutzbar sind, ist es grundsätzlich möglich, Objekte zu animieren. Dass das Element nicht konzipiert wurde um komplexer Animations-Software wie Flash oder Silverlight Konkurrenz zu machen, lässt sich an einigen Limitierungen erkennen. Nicht nur aufgrund der Komplexität und der damit notwendigen Ausführlichkeit in der Beschreibung, möchte ich auf die im Anschluß an den Artikel verlinkten Seiten verweisen. Dort findet man detailierte Beschreibungen, Beispiele und vieles mehr.

Zugänglichkeit (Accessibility)

Momentan können Inhalte des Elementes canvas ausschließlich über die Script-API erreicht werden. Auch der Umstand, dass als Fallback beliebige Elemente innerhalb der Element-Tags plaziert werden können, kann dem generierten Inhalt nicht in jeden Fall entsprechen, bzw. ihn nicht alternativ abbilden. Das W3C scheint sich dieses Problems bewusst zu sein und arbeitet an einem Fahrplan, wie eine erhöhte Zugänglichkeit für das Element erreicht werden kann.

Weiterführende Informationen zum Element canvas

Spezifikation

• WHATWG – Element canvas
• W3C – Bugtracker um Fehler zu melden (Anmeldung erforderlich)

Tutorials und Informationen

• Mozilla Development Center Tutorial – Canvas
• HTML5 Doctor – Informationen zu den HTML5 Specs und deren Anwendung

Beispiele

• Animationen – Uhren
• Animationsexperiment
• Chrome Experiments – Komplexe Experimente unter Einsatz verschiedener Technologien
• Testoberfläche um die Möglichkeiten von Canvas interaktiv zu testen

Fazit

Meine Bewertung der aktuellen Implementierung des Elementes canvas ist ambivalent. Zum einen bietet es interessante Merkmale und Methoden um Webseiten zukünftig mit neuen, im jeweiligen Kontext sinnvollen Funktionen zu bestücken und zu erweitern. Auf der anderen Seite schaue ich ein wenig sorgenvoll auf die Tatsache, dass der Einsatz des Elementes im Moment vollständig abhängig ist von aktivierten Javascript. Mag man auch der Meinung sein, dass zusätzliche Funktionalität mit zusätzlicher Technik erkauft werden muss, ist die augenblicklich unzureichende Zugänglichkeit der Inhalte für Nutzerkreise, denen diese Technik nicht zur Verfügung steht, in meinen Augen durchaus eine Kritikpunkt.

Erfreulicherweise ist dieses Problem dem W3C bereits bewusst, und es wird an einer Lösung gearbeitet.

Zum Autor:

Olaf Gleba ist selbständiger Frontend- und Software-Entwickler in Köln, Autor des WCMS Welcompose und engagiert sich in der täglichen Arbeit für Webstandards.

Im heutigen Teil unserer HTML5-Serie geht es um die Elemente <video> und <audio>.

1. Element <video>

Filme im Web bereitzustellen ist momentan mit enormen Aufwand verbunden, will man möglichst alle Besucher einer Seite in den Genuß der Filme bringen. Neben mehrfacher Konvertierung und Einbindung verschiedener Formate, muss die unterschiedliche Einbindungs-Syntax der Browser berücksichtigt werden. Oftmals ist der einzig gangbare Weg der Einsatz zusätzlicher Funktionalitäten und Techniken in Form von Plugins und Script-Sprachen (Flash, Javascript).

Mit dem Element video verspricht die HTML5 Spezifikation eine native, also von zusätzlicher Technik und Software unabhängige, Einbindung von Filmen in Webseiten.

1.1 Browser-Unterstützung

Neben Firefox ab Version 3.5 und Safari ab 3.2 unterstützt der aktuelle Google Chrome Browser (Version 3.x) das HTML5 Element video insofern, als dass erste Tests mit diesen Versionen möglich sind. Opera hat für Version 10.1 eine Unterstützung des Elementes video angekündigt. Redmonder Browser (IE) bleiben augenblicklich komplett außen vor.

Man sollte immer im Hinterkopf behalten, dass die Implementierung von HTML5 Elementen bis zur endgültigen Verabschiedung des Standards (oder sich die normative Kraft des Faktischen durchsetzt) immer nur vorläufigen Charakter hat. So unterscheidet sich momentan die Art und Weise der Implementierung, und es gibt keine Gewähr, dass und in welcher Form die Elemente in zukünftigen Versionen der Browser verfügbar sein werden.

1.2 Codecs und Formate

Mit der Einführung des neuen Elementes video verband sich bei vielen Entwicklern sicherlich die Hoffnung, dass man sich auf einen einheitlichen Codec einigen würde, den alle Browser unterstützen und das Bereitstellen verschiedener Formate überflüssig macht. Dass Weihnachten und Geburtstage aber in der Regel nicht auf einen Tag fallen, scheint sich leider auch in diesen Fall zu bewahrheiten, wie der Beitrag von Ian Hicks (englisch) auf der WHATWG-Mailingliste andeutet.

Während die Browser der Mozilla Foundation und Opera ausschließlich Ogg Media Container(.ogg, .ogv) und den Theora Video Codec unterstützen, bedient sich Apple's Safari¹ des H.264 Codec (.mp4, .mp4v), der Google Browser Chrome wiederum unterstützt beide, lässt sich aber eine Hintertür (siehe Ian Hicks' Beitrag) offen. Redmond schweigt momentan komplett zu einen zukünftig unterstützten Codec.

1.3 Einbindung

Die Syntax, um filmische Inhalte in eine Seite einzubinden, ist schlicht und einfach:

Quelltext Beispiel 1: Einbindung einer .ogg/Theora Filmdatei

<video src="sample.ogg" controls>
  Ihr Browser unterstützt das Element
  <code>video</code> nicht
  oder erkennt das Format der Datei nicht.
</video>

Beispiel 1: Einbindung einer Ogg/Theora (.ogg) Filmdatei

Quelltext Beispiel 2: Einbindung einer MPEG-4/H.264 (.mp4) Filmdatei

<video src="sample.mp4" controls>
  Ihr Browser unterstützt das Element
  <code>video</code> nicht
  oder erkennt das Format der Datei nicht.
</video>

Beispiel 2: Einbindung einer MPEG-4/H.264 (.mp4) Filmdatei

Neben dem Attribut src, das den Pfad zur Quelldatei angibt, fügt das optionale Attribut controls dem Film die notwendigen Steuerungselemente hinzu. Erkennt der Browser das Format der Filmdatei nicht oder ist ihm das Element video unbekannt, wird der Inhalt zwischen dem öffnenden und schließenden Tag angezeigt, bzw. gerendert. Dieses Verhalten bedeutet zum Einen eine attributlose, textliche Fallbacklösung², zum Anderen ermöglicht es aber auch, die Filmdatei an dieser Stelle konventionell in einem Flash-Container über das object Element einzubinden.

Beispiel: Fallback unter Anwendung des object Elementes

<video src="sample.mp4" controls>
  <object data="flvplayer.swf"
      type="application/x-shockwave-flash">
    <param value="flvplayer.swf" name="movie"/>
  </object>
</video>

Um Filmdateien mit unterschiedlichen Formaten einzubinden, wird das generische source Element genutzt:

Quelltext Beispiel 3: Einbindung multipler Formate

<video controls>
  <source src="sample.ogg" type="video/ogg" />
  <source src="sample.mp4" type='video/mp4';
     codecs="mp4v.20.240"' />
  Ihr Browser unterstützt das Element
  <code>video</code> nicht oder beide Formate
  (mp4, ogg) der Filmdatei(en) sind unbekannt.
</video>

Beispiel 3: Einbindung multipler Formate

Unterstützt der Browser das Ogg Container Format nicht, wird er versuchen den MPEG4 Film abzuspielen. Kennt er keines der beiden Formate/Codecs oder ist ihm das HTML5 Element video unbekannt, wird der sonstige Inhalt zwischen dem öffnenden und schließenden Tag angezeigt ².

Das Attribut type des Elementes source ist optional. Neben dem MIME-Typ kann zusätzlich über den Parameter codecs ein dezidierter Codec angegeben werden. Ist dem Browser dieser Codec nicht bekannt, wird der Film nicht angezeigt.

Wird das Attribut type nicht gesetzt, erhält der Browser die MIME-Information vom Server und gleicht sie mit den Möglichkeiten des Browsers ab. Gibt man das Attribut type an, wird der Browser ohne Rücksprache mit dem Server versuchen den MIME-Typ zu interpretieren. Um Bandbreite zu sparen, empfehle ich den MIME-Typ grundsätzlich anzugeben, da damit eine unnötige Kommunikation zwischen Client und Server vermieden wird.

Wird der MIME-Typ dennoch weggelassen, sollte darauf geachtet werden, dass der Server die Dateien mit dem korrekten MIME-Typ ausliefert. Ist dies nicht in der Konfigurationsdatei des Webservers angegeben, kann dies mit der folgenden Angabe in einer .htaccess Datei nachgereicht werden (Voraussetzung hier ist natürlich die Berechtigung die Direktive in einer .htaccess Datei editieren zu können).

Quelltext: Server die relevanten Mime-Typen in einer .htaccess bekannt machen:

AddType video/ogg .ogg
AddType video/mp4 .mp4

1.4 Attribute

controls="true|false"

controls

1.5 Media Elemente und Attribute

Wie an anderer Stelle schon erwähnt, blendet das Attribut controls die Steuerelemente eines Films ein oder aus. Das Aussehen, Anzahl und Position dieser Elemente ist abhängig von der Implementierung des Attributes in den verschiedenen Browsern und Betriebssystemen. Dankenswerterweise stellt die HTML5 Spezifikation über eine Script-Schnittstelle eine Vielzahl von Media Elementen und Attributen zur Verfügung, so dass unter Anwendung von Javascript die Steuerung und Anzeige eines Films individuell gestaltet werden kann.

Quelltext: Individuellen Wiedergabe/Pause Button programmieren

<script>
function playPause() {
  var meinFilm = document.getElementsByTagName('video')[0];
  if (meinFilm.paused)
    meinFilm.play();
  else
    meinFilm.pause();
}
</script>

<input type=button onclick="playPause()"
  value="Wiedergabe/Pause" />

Quelltext: Öffne ein Alert-Fenster, wenn das Event ended einen Status zurückliefert.

<script>
meinFilm.addEventListener('ended', function () {
  alert('Das Ende des Films ist erreicht')
});
</script>

Auch hier ist es wichtig im Hinterkopf zu behalten, dass die Anzahl und Benennung der Media Elemente und Attribute noch nicht in Stein gemeißelt sind und das ein oder andere Element/Attribut hinzukommen oder auch ersatzlos wegfallen kann.

1.6 Fazit

Während alleine nur die Aussicht auf Nutzbarkeit des Elementes video ein Leuchten in die Augen von Frontend-Entwicklern zaubert, fällt die Enttäuschung über die (bisher  – die Hoffnung stirbt zumindest ziemlich weit hinten) verpasste Chance einen einheitlichen Codec zum originären Teil der Spezifikation zu machen, dann umso größer aus. Dies ist allerdings weniger der WHATWG anzulasten, sondern auf die Süppchen der einzelnen Browserhersteller und Lizenzgeber der Codecs zurückzuführen.

Ohne konkret auf die lizenzrechtlichen Probleme einzugehen, ist es aus Sicht eines Entwicklers einfach schade, dass ein Konsens zwischen WHATWG, Browserherstellen und Codec-Lizenzgebern auch zu einem späteren Zeitpunkt eher unwahrscheinlich ist. So wird viel Potential des neuen Elementes verschenkt.

Zieht Microsoft in den nächsten Monaten nach, bleibt zumindest der Vorteil einer einheitlichen Syntax, die zukünftig übergreifend in allen aktuellen Browsern ohne Redundanz von Quelltext und zusätzlichen Techniken eingesetzt werden kann.

2. Element <audio>

Auch hier stehen wir momentan vor der gleichen Ausgangslage. Um möglichst viele Besucher zu erreichen, müssen bisher multiple Formate erstellt werden und die Anzeige und Einbindung in die Webseite unter zur Hilfenahme weiterer Techniken (Flash) und Funktionalitäten (Javascript) realisiert werden.

Durch das Element audio verspricht die HTML5 Spezifikation auch hier eine native Einbindung von Audio Dateien in Webseiten.

2.1 Browser-Unterstützung

Neben Firefox ab Version 3.5, Safari ab 3.2 unterstützt der aktuelle Google Chrome Browser (Version 3.x) das HTML5 Element audio in einer Art und Weise, die sich für erste Tests eignet. Opera hat für Version 10.1 – zeitgleich mit der video Unterstützung – die Verfügbarkeit des Elementes audio angekündigt. Der Internet Explorer steht auch hier in der Ecke mit dem Gesicht zur Wand.

Auch gilt das Gesagte zur Vorläufigkeit der Implementierung in den einzelnen Browsern. Sicher ist, dass nichts sicher ist.

2.2 Codecs und Formate

Browser der Mozilla Foundation unterstützen Ogg Media Container (.ogg) verbunden mit dem Vorbis Audio Codec, Apple's Safari das MPEG-1, Audio Layer 3 Format (.mp3), der Google Browser Chrome erkennt beide Formate/Codecs. Das Wave (.wav) Format wird von FF ab 3.1, Safari ab 3.x und zukünftig Opera ab 10.1 (für letztgenannten vorläufig als einziges Format) unterstützt.

2.3 Einbindung

Quelltext Beispiel 1: Einbindung einer Wave (.wav) Audiodatei

<audio src="sample-audio.wav" controls>
  Ihr Browser unterstützt das Element
  <code>audio</code>
  oder erkennt das Format der Datei nicht.
</audio>

Beispiel 1: Einbindung einer Wave (.wav) Audiodatei

Um Audiodateien mit unterschiedlichen Formaten einzubinden, wird das generische source⁵ Element genutzt:

Quelltext Beispiel 2: Einbindung multipler Formate

<audio controls>
  <source src="sample-audio.ogg" type="audio/ogg" />
  <source src="sample-audio.mp3" type="audio/mpeg" />
  Ihr Browser unterstützt das Element
  <code>audio</code> nicht oder beide Formate
  (Ogg/Vorbis, MPEG3) der Audiodatei(en) sind unbekannt.
</audio>

Beispiel 2: Einbindung multipler Formate

Es sollte grundsätzlich darauf geachtet werden, dass der Server die Datei(en) mit dem korrekten MIME-Typ überträgt. Hier gelten die gleichen Hinweise die zuvor in der Beschreibung des Elementes video erwähnt wurden. Mime-Typen für Audiodateien:

Quelltext: Server die relevanten (Audio) Mime-Typen in einer .htaccess bekannt machen:

AddType audio/x-wav .wav
AddType audio/ogg .ogg
AddType audio/mpeg .mp3

2.4 Attribute

controls="true|false"

controls

2.5 Media Elemente und Attribute

Die HTML5 Spezifikation stellt über eine Script-Schnittstelle Media Elemente und Attribute zur Verfügung, mit deren Hilfe man individuell die Steuerung und Anzeige einer Audiodatei beeinflußen kann.

Beispiel 3: Individuellen Wiedergabe Button anlegen

<script>
function playFile() {
  var audioobj = new Audio("sample.mp3");
  audioobj.play();
}
</script>

<input type=button onclick="playFile()" value="Wiedergabe" />

Die Vorläufigkeit der Anzahl, Benennung einzelner Elemente und Attributen wurde ja schon mehrfach erwähnt, aber ein erneuter Hinweis hierauf soll deutlich machen, dass man die Glacé-Handschuhe beim Coden anbehalten sollte…

2.6 Fazit

Auch hier ist die (Vor)Freude aufgrund des Format- und Codecs Durcheinanders nicht ungetrübt. Zur Freude, zukünftig ein standardisiertes Element unter den Händen zu haben, gesellt sich eine gewisse Enttäuschung über die Aussagen und Pläne der Browserhersteller zur Format/Codec Implementierung in Ihren Produkten.

3. Weiterführende Informationen zu den Elementen video und audio

Spezifikation

• WHATWG – Element video
• WHATWG – Element audio
• WHATWG – Media Elemente
• W3C – Bugtracker um Fehler zu melden (Anmeldung erforderlich)

Tutorials und Informationen

• MDC Tutorial – Using audio and video in Firefox (en)
• HTML5 Doctor – Informationen zu den HTML5 Specs und deren Anwendung (en)

Anwendungen

• Theora Ogg Dateien erstellen auf Mac OS X (en)

Viele Webdesigner beginnen ihre Entwürfe mit der Entwicklung eines Wireframes (Drahtgitter, Gittermodell). Damit wird ein sehr früher konzeptueller Prototyp einer Website bezeichnet, der die wichtigsten Bereiche wie Header, Navigation, Spaltenraster und Footer schematisch darstellt, häufig in Form verschiedenfarbiger oder in verschiedenen Grautönen abgestufter Kästen. Dabei reicht es aus, den grundlegenden konzeptuellen Entwurf nur sehr rudimentär abzubilden, um die Platzierung der einzelnen Bereiche zu verdeutlichen, und anschließend Schritt für Schritt zu verfeinern. Abbildung 1 zeigt, wie ein Wireframe in einem fortgeschrittenen Stadium aussehen könnte.

Abb. 1: Ein Wireframe veranschaulicht Größe, Position und Wirkung der Hauptelemente einer Website

Webautoren gehen so ähnlich vor, wenn sie beginnen, das Markup für eine Webseite aufzubauen. Auch sie arbeiten sich von außen nach innen vor. Am Anfang steht die Auszeichnung der groben Struktur, deren Inhalte im Anschluss Schritt für Schritt ausgezeichnet werden. In Ermangelung geeigneter Elemente für Seitenbereiche wie Header, Logo, Suche, Hauptmenü, Seitenspalte oder Footer greifen Webautoren auf div-Elemente zurück und vergeben geeignete Bezeichner und Klassen. Ein solches »Grundskelett« einer Website zeigt Listing 1.

<body>
  <div id="header">
    <div id="logo">Logo</div>
    <div id="search">Suche</div>
    <div id="nav">Hauptmenü</div>
  </div>

  <div id="content">
    <h1>Hauptbereich</h1>

    <div class="section">
      <h2>Sektion</h2>
      <h3>Abschnitt</h3>

      <!-- Content -->
    </div>

    <div class="section">
      <h2>Sektion</h2>

      <!-- Content -->
    </div>
  </div>

  <div id="sidebar">
    <div id="subnav">Bereichsmenü</div>
  </div>

  <div id="footer">Footer</div>
</body>

Je nach den persönlichen Vorlieben des Webautoren oder den Vorgaben des eingesetzten Frameworks unterscheiden sich die Namen der Bezeichner und Klassen, im Wesentlichen haben wir es aber stets mit denselben Strukturen zu tun.

Neue Elementtypen und neue Konzepte

Die HTML5-Arbeitsgruppe hat sich dieser Problematik angenommen und eine Reihe neuer Sektionselemente eingeführt, die Webautoren die Möglichkeit an die Hand geben, den Aufbau des Endoskeletts ihrer Webseiten zu standardisieren, darunter header, nav, article, section, aside und footer. Listing 2 zeigt die Übersetzung von Listing 1 in HTML5.

<body>
  <header>
    <div id="logo">Logo</div>
    <div id="search">Suche</div>
    <nav>Hauptmenü</nav>
  </header>

  <article>
    <h1>Hauptbereich</h1>

    <section>
      <h2>Sektion</h2>
      <h3>Abschnitt</h3>

      <!-- Content -->
    </section>

    <section>
      <h2>Sektion</h2>

      <!-- Content -->
    </section>
  </article>

  <aside>
    <nav>Bereichsmenü</nav>
  </aside>

  <footer>Footer</footer>
</body>

Sektionen: Der Elementtyp section

Das Element section zeichnet eine Sektion in einem Dokument oder einer Web-Applikation aus.

Eine Sektion ist eine Gruppe von Elementen, die thematisch zusammengehören. Beispiele dafür sind Abschnitte eines Textes, einzelne Register (Tabs) in einer registerbasierten Benutzeroberfläche oder einzelne Bereiche einer Website wie die Einleitung, der Newsbereich oder Kontaktinformationen. Sektionen enthalten häufig eine Überschrift und gelegentlich einen Footer, der (sichtbare) Metainformationen zur Sektion enthält.

Sektionen eignen sich dazu, Inhalte und deren Überschriften in einem gemeinsamen Element zusammenzufassen. Das geht in HTML5 über die reine Auzeichnungsebene hinaus; dazu später mehr. section ist kein semantisch leeres, bedeutungsloses Element; ebenso wenig wie die anderen in diesem Artikel vorgestellten Elemente. Wer einen Container benötigt, um Elemente fürs Styling zusammenzufassen, der sollte weiterhin div verwenden.

Kopfbereiche: Der Elementtyp header

Das Element header definiert den »Kopfbereich« einer Webseite oder eines Sektionselements.

Als Auszeichnung des Kopfbereichs einer Webseite enthält es Elemente wie die Hauptüberschrift, das Logo, das Suchfeld oder die Hauptnavigation. Innerhalb eines Sektionselements enthält es Überschriften oder Elemente wie das Inhaltsverzeichnis oder die Einleitung der Sektion.

Navigationsbereich: Der Elementtyp nav

Das Element nav zeichnet einen Bereich mit Navigationslinks aus, entweder mit Links zu anderen Seiten oder zu Sprungankern innerhalb derselben Seite.

Webautoren sollten nicht jede Gruppe von Links mit nav auszeichnen, sondern nur zentrale Navigationsbereiche wie das Haupt- und das Bereichsmenü. Typischerweise enthält das nav-Element Listen, welche die Navigation repräsentieren.

<nav>
  <h2>Navigation</h2>

  <ul>
   <li class="home"><strong title="Hier befinden Sie sich
     gerade.">Startseite</strong></li>
   <li><a href="/adventskalender/">Adventskalender</a></li>
   <li><a href="/mission-statement/">Mission Statement</a></li>
   <li><a href="/linkliste/">Linkliste</a></li>
   <li><a href="/krautcosmos/">KrautCosmos </a></li>
   <li><a href="/impressum/">Impressum</a></li>
  </ul>
</nav>

Eigenständige Bereiche: Der Elementtyp article

Das Element article zeichnet einen inhaltlich eigenständigen Bereich auf einer Webseite aus, der zwar im Kontext der Seite steht, aber für sich unabhängig ist.

Ein Inhalt ist dann eigenständig, wenn er auch außerhalb der Seite für sich allein Sinn ergibt, beispielsweise wenn er in einem anderen Kontext wiedergeben oder in einem Portal als eigenständige Komponente dargestellt wird. Das kann ein Weblog-Eintrag sein, ein Artikel, ein Forumsbeitrag oder ein interaktives Widget.

<article>
  <header>
    <h1>Frontendentwicklung ist nicht einfach!</h1>
    <p class="postmetadata">31. Juli 2009 | Abgelegt in
    <a href="/category/artikel/" rel="category tag">Artikel</a>
    | Tags: <a href="/tag/css/">CSS</a>, <a href="/tag/html/">
    HTML</a></p>
  </header>

  <p>»Aber CSS ist doch einfach!« Man könnte stattdessen auch
  »Frontendentwicklung« oder »HTML« setzen. (...) Lasst es
  Euch nicht einreden: Frontendentwicklung ist nicht einfach,
  sondern eine ständige Herausforderung!</p>

  <section>
    <h2>Keine Kommentare</h2>

    <p>Du kannst einen Kommentar hinterlassen oder einen
    Trackback auf deiner Website einrichten.</p>
  </section>
</article>

article-Elemente können verschachtelt werden. In diesem Fall repräsentieren die inneren article-Elemente Bereiche, die zwar im Kontext des äußeren stehen, aber eigenständig sind. Ein häufiger Anwendungsfall sind Weblog-Einträge mit Kommentaren, wobei jeder Kommentar in ein eigenes article-Element eingeschlossen wird.

<article>
  <header>
    <h1>Frontendentwicklung ist nicht einfach!</h1>
    <p class="postmetadata">31. Juli 2009 | Abgelegt in
    <a href="/category/artikel/" rel="category tag">Artikel</a>
    | Tags: <a href="/tag/css/">CSS</a>,
    <a href="/tag/html/">HTML</a></p>
  </header>

  <p>»Aber CSS ist doch einfach!« Man könnte stattdessen
  auch »Frontendentwicklung« oder »HTML« setzen. (...) Lasst
  es Euch nicht einreden: Frontendentwicklung ist nicht
  einfach, sondern eine ständige Herausforderung!</p>

  <section>
    <h2>1 Kommentar</h2>

    <p>Du kannst einen Kommentar hinterlassen oder einen
    Trackback auf deiner Website einrichten.</p>

    <article id="comment-42">
      <header>
        <h3><cite>Kommentar von Max Mustermann</cite></h3>
        <p class="commentmetadata">02. August 2009</p>
      </header>

      <p>Toller Artikel! Danke!</p>
    </article>
  </section>
</article>

Marginalien und Randbereiche: Der Elementtyp aside

Das Element aside enthält erläuternde und weiterführende Informationen, welche die Hauptinhalte ergänzen.

Gute Beispiele für den richtigen Einsatz dieses Elements sind Marginalien mit Definitionen oder Erläuterungen, Querverweise zu anderen relevanten Ressourcen oder Kästen mit Hintergrundinformationen, aber häufig wird aside auch einfach zur Auszeichnung von Randspalten mit Navigationsbereichen, Kommentaren etc. verwendet werden. In einem Artikel über Webstandards und das diesbezügliche Engagement der Webkrauts könnten wir wie folgt vorgestellt werden.

<aside>
  <h1>Webkrauts Mission Statement</h1>

  <p>Die Webkrauts setzen sich dafür ein, die Vorteile der
  Webstandards auch im deutschsprachigen Raum stärker zur
  Geltung zu bringen.</p>

  <p>Sie leisten Aufklärungsarbeit durch Veröffentlichungen
  im Netz und in anderen Medien.</p>
</aside>

Fußbereiche: Der Elementtyp footer

Das Element footer enthält sichtbare Metainformationen über eine Webseite oder ein Sektionselement.

Typische Inhalte sind Informationen darüber, wer den Inhalt der Seite oder Sektion verfasst hat (wobei diese mit address ausgezeichnet werden), oder Links zu anderen Dokumenten, beispielsweise das Impressum oder Angaben zum Datenschutz. Der Footer muss nicht unbedingt am Ende der Sektion stehen, aber üblicherweise tut er das (daher der Name). footer-Elemente können section-Elemente enthalten, um die Inhalte zu unterteilen.

<footer>
  <section>
    <h1>Systemlinks</h1>

    <ul>
      <li><a href="/login/">Anmelden</a></li>
      <li><a href="/login/?action=register">
         Registrieren</a></li>
    </ul>
  </section>

  <section>
    <h1>Lizenzbestimmungen</h1>

    <p>© Webkrauts 2005-2009. Alle Rechte vorbehalten.</p>
  </section>
</footer>

Sektionen und Überschriften

Bisher stehen Webautoren die Elemente h1 bis h6 zur Verfügung, um Überschriften auszuzeichnen. Dokumente enthalten ein oder mehrere h1, die die Hauptüberschriften (Überschriften der ersten Ordnung) der jeweiligen Abschnitte auszeichnen. Die Überschriften h2 sind dann die gering weniger wichtigen Überschriften (die Überschriften zweiter Ordnung) der Unterabschnitte. Überschriften dritter Ordnung h3 unterteilen wiederum diese Unterabschnitte. Dieses Prinzip lässt sich hierarchisch weiter fortführen bis zur Überschrift h6, der geringstwichtigen Überschrift. Allerdings gibt es dabei zwei Nachteile:

• Sechs Überschriftebenen sind mehr, als Webautoren in den (aller)meisten Fällen benötigen. Aber was ist, wenn doch einmal weitere Ebenen notwendig sind, beispielsweise in sehr langen, für den Druck aufbereiteten Dokumenten? Es gibt kein Element h7, kein Element h8 und so weiter, also müssen Webautoren sich mit Hilfskonstruktionen behelfen.
• In seinem Artikel Passende Überschrift hier einsetzen beschreibt Webkraut Tomas Caspers ein weiteres Problem: Darf man Überschriftenebenen auslassen oder müssen diese immer streng hierarchisch und ohne Lücken aufgebaut sein? Der HTML-Standard ist diesbezüglich sehr schwammig, aber die gängige Praxis hat die Frage längst beantwortet. In vielen Fällen lässt es sich nämlich nicht vermeiden, Überschriftenebenen zu überspringen, beispielsweise wenn Webseiten auf Content-Management-Systemen basieren und dieselben Inhalte in verschiedenen Kontexten verwendet werden, wobei deren Überschriftebene nicht angepasst werden kann.

HTML5 löst beide Probleme dadurch, dass Überschriften stets einer Sektion zugeordnet werden, wobei Sektionen beliebig tief verschachtelt werden können und so die Ebene einer Überschrift definieren; unabhängig davon, um welche Überschrift welcher Ordnung es sich handelt. Jede Sektion bringt ihren eigenen Überschriftenkontext mit. Im folgenden Beispiel enthält jedes section-Element ein eigenes h1, obwohl die einzelnen Apfelsorten eigentlich der Hauptüberschrift »Äpfel« untergeordnet wären.

<article>
  <h1>Äpfel</h1>

  <p>Der Apfel bildet eine Gattung der Kernobstgewächse aus der
  Familie der Rosengewächse.</p>

  <section>
    <h1>Red Delicious</h1>

    <p>Der Red Delicious ist einer der beliebtesten Tafeläpfel,
       vor allem in den USA, und weltweit die meist angebaute
       Sorte. </p>
  </section>

  <section>
    <h1>Granny Smith</h1>

    <p> Der Granny Smith gehört zu den sauersten
      Apfelarten überhaupt. Er wird gern zum Backen und
      Kochen verwendet. </p>
  </section>
</article>

Der HTML5-Arbeitsentwurf spricht von der »Outline« eines Dokuments. Die Outline besteht aus einer Liste von verschachtelten Sektionen und deren Überschrift. Der Outline-Algorithmus assoziiert jeden DOM-Knoten mit einer speziellen Sektion und (falls vorhanden) deren Überschrift.

Sektionen können explizit im Dokument stehen (section-Element) oder implizit eingeleitet werden durch eine Überschrift. Folgendes HTML-Fragment soll dies deutlich machen:

<article>
  <h1>Überschrift A</h1>
  <p>Absatz B</p>

  <h2>Überschrift C</h2>
  <p>Absatz D</p>

  <h2>Überschrift E</h2>
  <p>Absatz F</p>
</article>

Das Element h1 leitet eine Sektion ein, ebenso die Elemente h2, deren Sektionen in der ersten Sektion verschachtelt sind. Abbildung 2 visualisiert dies.

Abb. 2: Überschriften leiten implizite Sektionen ein

Betrachten wir ein komplizierteres Beispiel:

<article>
  <h1>Foo</h1>

  <h2>Bar</h2>

  <p>Baz</p>

  <h2>Quux</h2>

  <section>
    <h4>Thud</h4>
  </section>

  <p>Grunt</p>
</article>

In diesem gibt es folgende Sektionen (siehe auch Abbildung 3:

• Die implizite Hauptsektion mit der Überschrift »Foo« und dem Absatz »Grunt«.
• Eine implizite Sektion zweiter Ebene, die von der Überschrift »Bar« eingeleitet wird und den Absatz »Baz« enthält.
• Eine weitere implizite Sektion zweiter Ebene, die von der Überschrift »Quux« eingeleitet wird.
• Eine explizite Sektion zweiter Ebene mit der Überschrift »Thud«.

Abb. 3: Sektionsgerüst eines Fragments mit expliziten und impliziten Sektionen

In diesem Beispiel gibt es einige Besonderheiten, die mit folgender Regel zusammenhängen: Explizite Sektionen, die durch das section-Element ausgezeichnet werden, schließen implizite Sektionen ab. In diesem Beispiel hat das folgende Auswirkungen:

• Die Sektionen Bar, Quux und Thud sind gleichberechtigt auf einer Ebene. Die Outline ist unabhängig davon, welche Hierarchie die Überschriften (h1 bis h6) im Dokument tatsächlich haben. <h4>Thud</h4> wird in der Outline zu einer Überschrift derselben Ebene wie <h2>Bar</h2>!
• Die explizite Sektion Thud schließt alle impliziten Sektionen ab. Der Absatz Grunt gehört damit wieder zur Hauptsektion!

Dies zeigt, wie mächtig das neue Outline-Konzept in HTML5 ist und wie schnell es Verwirrung stiften kann. Überschriften haben nicht immer die Ebene, die das Markup vermuten lässt, und Elemente stehen manchmal in einem anderen Kontext als es auf den ersten Blick aussieht. Der HTML5-Entwurf empfiehlt daher,

• entweder nur Überschriften erster Ordnung (h1) zu verwenden oder darauf zu achten, dass die Überschriftenebenen korrekt sind, und
• Sektionen explizit mit section-Elementen auszuzeichnen und sich nicht auf implizite Sektionen zu verlassen.

So ist das folgendes Listing 11 zwar korrekt im Sinne von HTML5, aber besseres, semantisch hochwertigeres Markup zeigt Listing 12 (obwohl die Outline exakt dieselbe ist):

<body>
  <h4>Äpfel</h4>

  <p>Äpfel sind Früchte.</p>

  <section>
    <h2>Geschmack</h2>
    <p>Sie schmecken toll.</p>

    <h6>Süße</h6>
    <p>Rote Äpfel sind süßer als grüne.</p>

    <h1>Farbe</h1>
    <p>Äpfel gibt es in verschiedenen Farben.</p>
  </section>
</body>

<body>
  <h1>Äpfel</h1>

  <p>Äpfel sind Früchte.</p>

  <section>
    <h2>Geschmack</h2>
    <p>Sie schmecken toll.</p>

    <section>
      <h3>Süße</h3>
      <p>Rote Äpfel sind süßer als grüne.</p>
    </section>
  </section>

  <section>
    <h2>Farbe</h2>
    <p>Äpfel gibt es in verschiedenen Farben.</p>
  </section>
</body>

Überschriftengruppen: Der Elementtyp hgroup

Das Element hgroup gruppiert Elemente vom Typ h1 bis h6 und fasst diese zu einem Element zusammen.

Ein typischer Anwendungsfall sind Titel und Untertitel wie in folgendem Beispiel:

<hgroup>
 <h1>Einführung in XHTML, CSS und Webdesign</h1>
 <h2>Standardkonforme, moderne und barrierefreie Websites
    erstellen</h2>
</hgroup>

Die Ordnung des hgroup-Elements entspricht der Ordnung der höchsten darin enthaltenen Überschrift, im oberen Fall repräsentiert das hgroup-Element eine Überschrift erster Ordnung. Die weiterne Überschriften werden für die Berechnung der Outline ignoriert – sie öffnen somit keine weiteren Sektionen.

Und die Browser? Praktischer Einsatz der neuen Elemente

Aktuelle Versionen von Opera, Safari und Firefox stellen alle in diesem Artikel vorgestellten Elemente wie gewünscht dar. Lediglich ein

article, aside, footer, header, hgroup, nav, section
  { display: block; }

ist notwendig, damit die neuen Elemente sich so verhalten, wie man es erwarten könnte. Ältere Browser haben allerdings einige Probleme.

• Firefox 2 (und jeder andere Browser mit einer Gecko-Version kleiner als 1.9b5) schließt unbekannte Elemente, sobald er auf ein Blockelement stößt wie p, h1, div und so weiter. Auf diese Browser brauchen Webentwickler allerdings heute nicht mehr zu achten. Die Mozilla Foundation hat die Unterstützung für Firefox 2 mittlerweile eingestellt – und auch wir sollten das tun.
• Im Internet Explorer gibt es ein ähnliches Problem, und das zieht sich durch sämtliche Versionen, die heute noch relevant sind – leider sind das alle Versionen bis hinab zum IE 6. Der IE schließt unbekannte Elemente stets sofort, ganz gleich, welches Element dem unbekannten Element nachfolgt.

Im DOM (Document Object Model) dieser Browser wird aus

<section class="sektion">
  <h1>Foo</h1>

  <p>Bar</p>
</section>

<p>Baz</p>

folgendes:

<section class="sektion"></section>
<h1>Foo</h1>
<p>Bar</p>
</section><//section>
<p>Baz</p>

<section> und </section>; werden also nicht als öffnenden und schließenden Tag eines Elements erkannt, sondern in beiden Fällen als Start-Tag eines eigenen Elements, dem jeweils ein schließender Tag hinzugefügt wird. So entsteht <//section> als schließendes Tag für </section>. Aus Container-Elementen, die sich per CSS stylen oder per Scripting ansprechen lassen, werden so leere Elemente, mit denen Webautoren nichts mehr anfangen können.

Dieses Problem können Webautoren nicht ignorieren. Peter Kröner schlägt daher in einem lesenswerten Artikel einige Workarounds vor.

Die beste Lösung stellt dabei das HTML5 enabling script von Remy Sharp dar. Darüber kann jedes (unbekannte) Element beim Browser per JavaScript angemeldet werden. Für das section-Element sieht das beispielsweise so aus:

document.createElement('section');

Die angemeldeten Elemente werden dann wie bekannte Elemente behandelt, d.h. Webautoren können mit ihnen in allen Belangen arbeiten. Das HTML5 enabling script meldet alle neuen HTML5-Elemente an und wird im Gleichschritt mit dem HTML5-Entwurf aktualisiert. Gewissenhafte Webautoren sehen jedoch sofort das Problem an dieser Methode: Wenn im Browser JavaScript nicht aktiviert ist, funktioniert das Skript und somit vermutlich die gesamte Website nicht. Im professionellen Einsatz ist diese Methode folglich untauglich, da es schlichtweg schlechter Stil ist, aktiviertes JavaScript vorauszusetzen.

Fazit

Die neuen Elemente geben Webautoren die Möglichkeit, semantische Strukturen aufzubauen, wo sie bisher auf div-Container zurückgreifen mussten. Die Anzahl und Namen der neuen Elemente sind gut durchdacht, dennoch gibt es Stimmen, die das anders sehen und denen dieser Teil der HTML5-Empfehlung nicht weit genug geht, darunter Adrian Bateman von Microsoft. Er kritisiert in seinem Posting an die HTML-Mailingliste des W3C unter anderem, dass die neuen Elemente zu unspezifisch seien und keinen Fortschritt gegenüber bewährten Auszeichnungen darstellten. Er schreibt:

»It's not clear why these new elements in particular are necessary. Those that use HTMLElement for their interface provide no extra functionality beyond <div class="xxx"> or <span class="">. If they are necessary, do we know if this is the correct set? Are there any missing?

Wer würde ihm nicht widersprechen und klarstellen wollen, dass <header> gegenüber <div class="header"> definitiv ein Fortschritt ist? Es liegt auf der Hand, dass HTML als Auszeichnungssprache, die nur auf eine Handvoll Elemente beschränkt ist, nicht für jeden denkbaren Fall das richtige Element parat hat. Hilfskonstruktionen mit semantisch bedeutungslosen div- und span-Elementen werden Webautoren in Zukunft weiter nutzen müssen, mit HTML5 allerdings weit weniger als bisher.

Das Outline-Konzept, das die Hierarchie von Überschriften unabhängig vom tatsächlichen Markup auf der Basis von (expliziten und impliziten) Sektionen berechnet, ist eine gute Idee und löst einige Probleme, die Webautoren und Programmierer derzeit mit Überschriften haben. Allerdings fügt es eine Komplexität auf einer neuen Ebene hinzu, die womöglich andere Probleme mit sich bringt.

In Zukunft werden sich – wie es ja bereits heute mit dem bisherigen Sprachumfang der Fall ist – typische Muster herausbilden, die das Markup für Standardauszeichnungen vorgeben. Es wird weniger die Frage sein, wie die neuen Elemente einzusetzen sind, sondern eher, ob Webautoren sie einsetzen sollten. Heute gibt es noch keine Möglichkeit sicherzustellen, dass die neuen Elemente in allen Browsern funktionieren, die derzeit in relevantem Umfang im Einsatz sind. Alle Lösungen haben einen Haken. Ich persönlich würde die neuen Elemente (und somit HTML5) heute im privaten Umfeld bereits einsetzen, aber keinesfalls in Kundenprojekten oder auf Websites, die sich nicht erlauben können, Nutzer veralteter Browser mit eigenwilligen Konfigurationen auszuschließen. Eric Eggert hat das auf seiner (privaten) Website auf den Punkt gebracht:

»HTML5 wird von keinem Browser aktiv unterstützt, es geht im Moment nur nichts kaputt. Das ist eine tolle Sache, eignet es sich doch für Experimente wie diese Seite hier oder für das ein oder andere Experiment zum Beispiel mit den audio und video-Elementen. Alle, die nicht experimentieren wollen oder können, zum Beispiel bei Projekten für Kunden oder den Arbeitgeber, sollten HTML5-Features nur ganz, ganz sparsam einsetzen und nur Teile, die sicher sind.«

Zum Autor

Michael Jendryschik konzipiert und entwickelt Websites. Er leitet den Bereich Webentwicklung bei der itemis AG in Lünen. Er ist Buchautor (Einführung in XHTML, CSS und Webdesign), schreibt Fachartikel und hält Vorträge, hauptsächlich zu Web-Frontend-Themen. Seine Arbeitsschwerpunkte sind XML-Technologien, Web-Usability und vor allem professionelles Webdesign mit (X)HTML und CSS.

HTML5 wird der neue Markup-Standard, daran gibt es mittlerweile keinen Zweifel mehr. Grund genug einmal zu schauen was eigentlich dahinter steckt.

Weshalb wurde HTML5 entwickelt?

Das Web hat sich seit 1999, als HTML4/XHTML1 entwickelt wurde, grundlegend verändert. Aus einem Web von statischen Dokumenten wurden hochkomplexe Applikationen, für die aber kaum semantisches Fundament vorhanden ist. Das soll sich in HTML5 ändern.

Die Entwicklung begann bei der WHATWG, einer Gruppe von Browserherstellern, die mit dem W3C-Prozess nicht einverstanden waren. Dort wurde der (zu vorigen (X)HTML-Versionen inkompatible) XHTML2-Standard entwickelt, der aber auf keinerlei Akzeptanz bei den Browserherstellern stieß. 2006 sah das W3C ein, dass HTML5 eine gute Sache ist und reaktivierte die alte HTML-Arbeitsgruppe. Beide Organisationen existieren heute nebeneinander und arbeiten an einer gemeinsamen Spezifikation, Editor Ian Hickson (Google) sammelt die Vorschläge und führt sie zusammen.

Was sind die Prinzipen und Ziele der HTML5-Entwicklung?

1. Unterstütze existierende Inhalte: Parser (nicht Autoren!) sollen mit alten, aber dennoch existierenden Techniken umgehen können, auch wenn sie nicht in HTML5 festgelegt sind. So werden bspw. fehlerhaft verschachtelte Elemente (<b>a<i>b</b>c</i>) genauso unterstützt wie Elemente, die nicht mehr zum Standard gehören (<u> etwa).
2. Graceful degradation (etwa: „Schrittweises Zurückfallen“): Wird eine Komponente in HTML5 nicht von einem Browser unterstützt, so darf das nicht dazu führen, dass die gesamte Webseite unzugänglich wird. Beispiel: Das (vorgeschlagene) irrelevant-Attribut kann per CSS emuliert werden: [irrelevant] {display:none;}
3. Das Rad nicht neu erfinden: Wenn es schon eine weit verbreitete und implementierte Technik gibt, dann sollte sie übernommen werden statt etwas komplett neues zu entwickeln. Beispiel: contenteditable="" (um Bereiche der Seite bearbeitbar zu machen) ist bereits in vielen Browsern vorhanden und wird daher übernommen.
4. Paving the Cowpaths (etwa: „Trampelpfade pflastern“): Wenn es schon weit verbreitete Techniken gibt, dann sollte in Erwägung gezogen werden diese zu nutzen. Beispiel: <br /> kommt oft in HTML statt <br> vor und es schadet niemandem, wenn man die Nutzung erlaubt.
5. Evolution statt Revolution: HTML5 entwickelt (X)HTML weiter und wirft altbekannte Grundsätze nicht weg. Das bedeutet, dass Webentwickler nichts komplett neues erlernen müssen, sondern nach und nach neue Features einbauen können. Das gilt natürlich auch für die Hersteller von Browsern.

Muss ich jetzt HTML statt XHTML schreiben?

Nein. HTML5 verfügt über beide Serialisationen (Schreibweisen), kann also sowohl als X(HT)ML als auch als HTML geschrieben und interpretiert werden. Wichtig ist: Beide verfügen nach dem Parsen über den selben DOM-Baum. Es wird also tendenziell einfacher JavaScripts für HTML und XHTML zu schreiben.

Der DOM-Baum von HTML4 und XHTML1-Dokumenten konnte zuvor trotz gleicher Schreibweise unterschiedlich sein. Bei einem HTML4-Dokument wird zum Beispiel bei folgender Tabelle ein <tbody> explizit in das DOM eingefügt, bei XHTML nicht:

<table><tr><td>Text</td></tr></table>

Das bedeutet, dass CSS wie table > tr > td in HTML4 keine Wirkung zeigt.

Zum anderen erlaubt HTML5 ausdrücklich die Nutzung der XML-Syntax für Elemente ohne End-Tag: <img … /> führt nicht mehr zu Validierungsfehlern, auch wenn man ein HTML-Dokument benutzt.

Wann wird HTML5 fertig?

„Fertig“ ist im aktuellen W3C-Prozess ein sehr dehnbarer Begriff. Ein (vorgeschlagener) Standard muss heute viele Tests überstehen und Bedingungen erfüllen, um vom W3C final abgesegnet werden. Für HTML5 wird dafür extra eine Testsuite erstellt, die dann auch noch von 2 Browsern (oder vom Marktführer) bestanden werden müssen. Dieser letzte Teil, der sich bis 2022 hinziehen könnte, ist aber in der Praxis für Webentwickler relativ uninteressant – wir nutzen ja auch CSS2.1, das sich seit Jahren in der Entwicklung befindet, weitgehend implementiert ist, aber eben noch keine W3C-Empfehlung ist. Trotzdem würde kein Webentwickler sagen CSS2.1 sei nicht „fertig“.

Die HTML5-Arbeitsgruppe im W3C bereitet gerade die Veröffentlichung eines ersten Last Call vor, die im Oktober erscheinen soll. HTML5 definiert dann praktisch eine Todo-Liste für die Browserhersteller.

Gerade in den letzten Wochen hat sich mit der Gründung der HTML5 Super Friends, unter der Führung von Jeffrey Zeldman, und der Einreichung ihrer Anregungen einiges an der Spezifikation geändert, was Autoren betrifft.

Sollte man HTML5 jetzt verwenden?

Das kommt auf das Projekt an. Es schadet nichts, gewohntes (X)HTML zu nutzen und den neuen Doctype drüber zu schreiben, doch es hat auch keine wirklichen Vorteile. Die neuen Elemente (<nav>, <article>, <section>) funktionieren in vielen Browsern noch nicht (IEs, Firefox 2) und haben dort wo sie funktionieren auch noch keine semantischere Bedeutung als divs. Will man alle Browser mit im Boot haben und die IEs auch ohne JavaScript unterstützen, so kommt man um Hilfkonstruktionen und mehrfachverschachtelte divs wohl nicht herum.

Für kleine, private Seiten, die nicht den Anspruch haben unter jeder Konfiguration gleich (gut) auszusehen, lohnt sich der Blick über den Tellerrand aber bereits, erst recht wenn man auch mit den neuen JavaScript-APIs spielen möchte. Für die alltägliche Arbeit sollte man aber vielleicht heute noch auf altbekannte Elemente setzen und eine Namenskonvention mit Klassen einführen, die HTML5-Elemente widerspiegelt.

Wie geht’s hier weiter?

In den nächsten zwei Wochen stellen euch einige unserer Autoren auf webkrauts.de die wichtigsten neuen Elemente im Detail vor – ausgehend vom aktuellen Entwurf. Es wird um die semantische Grundaufteilung einer Webseite gehen, um Elemente für Video- und Audiodateien, um Spielereien mit und um die neuen Möglichkeiten für das input-Element. Den Abschluss bildet ein Beispiel aus der Praxis: Wir nutzen HTML5 für ein Blog-Projekt.

Zum Autor

Eric Eggert glaubt an das offene und für jeden zugängliche Web. Deshalb setzt er sich im W3C mit dem neuen HTML5-Standard auseinander und hilft der BAD TF dabei gute Beispiele für Barrierefreie Webseiten zu entwickeln. Er bloggt (von Zeit zu Zeit) auf yatil.de.