Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Das Endoskelett einer Webseite

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Das Endoskelett einer Webseite

Webworker nutzen zur Zeit div-Konstrukte, um ihre Webseite zu unterteilen. Mit HTML5 kommen eine Reihe neuer Elemente ins Spiel, die einzelne Bereiche einer Webseite endlich auch semantisch sinnvoll auszeichnen. Michael Jendryschik stellt die neuen Typen anhand zahlreicher Beispiele vor.

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.

Wireframe
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>

Listing 1: Grundskelett einer Website mit div-Suppe

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>

Listing 2: Grundskelett einer Website mit den neuen strukturierenden Elementen aus HTML5

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>

Listing 3: Navigationsbereich mit Hauptmenü

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>

Listing 4: Auszeichnung eines Weblog-Eintrags mit 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>

Listing 5: Auszeichnung eines Kommentars als verschachteltes article-Element

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>

Listing 6: Informationen über die Webkrauts als erläuternder Kasten

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>

Listing 7: Systemlinks und Copyrighthinweise gehören in footer-Elemente

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>

Listing 8: Aufbau einer Überschriftenhierarchie über section-Elemente

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>

Listing 9: Implizite Sektionen

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

Implizite Sektionen
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>

Listing 10: Explizite und implizite Sektionen

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«.

Sektionsgerüst mit expliziten und impliziten Sektionen
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>

Listing 11: Schlechtes HTML5-Markup mit falschen Überschriftenebenen und impliziten Sektionen

<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>

Listing 12: Gutes HTML5-Markup mit passenden Überschriftenebenen und vollständigem Sektionsgerüst

Ü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>

Listing 13: Überschriften mit hgroup zusammenfassen

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.«

Kommentare

Stephan Zavodny
am 24.09.2009 - 15:14

Super Artikel, danke! Was mir bis dato noch gar nicht so bewusst war, dass man <header> nicht nur ausschließlich als Kopfbereich der kompletten Webseite, sondern auch innerhalb eines Sektionselementes einsetzen kann.

Permanenter Link

Claude
am 24.09.2009 - 16:44

Ganz spontan ein grosses Lob. Selten las ich auf so kleinem Raum so viel nützliche Informationen und Klärungen von Details.

Sehr gut dargelegt!

Permanenter Link

Nathanael
am 24.09.2009 - 23:35

Ich schlage als Problemlösung für IEs und ältere Browser eine serverseitige Filterlösung vor: Gute Frameworks bieten ja eine Möglichkeit einen Filter in die Ausgabe einzuklinken (andere können das etwa mit dem PHP Output Buffer selber implementieren), alternativ könnte man eine Apache-Modul dafür bauen.

Dabei ersetzt der relativ simple Filter bei älteren Browsern die neuen Elemente durch DIVs mit entsprechender Klasse. Ein IE bekommt dann etwa Navigation statt Navigation

Im CSS müsste man das dann entweder direkt vorsehen oder den Filter auch das CSS bearbeiten lassen.

Vorteil des Ganzen wäre die vorwärtsgerichtete Code-Entwicklung mit HTML5, um die Browser-Kompatibilität kann sich ein allgemeingültiges Modul kümmern, dass man bloß einrichten muss.

Permanenter Link

Thomas Weise
am 26.09.2009 - 08:47

Danke für diesen verständlich geschriebenen Ausblick auf html5. Wenn man "immer mal wieder" so einen Artikel liest, dann geht dann der Umstieg bestimmt ohne große Umstellerei von der Hand. Ich freu mich schon drauf, ein neues Projekt dann mal mit html5 anzugehen, jetzt wart ich erstmal noch ab.

Permanenter Link
Olaf Gleba

Olaf Gleba (Webkraut)
am 26.09.2009 - 21:15

Sehr schöner Artikel, der durch seine Detailgenauigkeit und Ausführlichkeit viele Denkanstösse gibt, aber auch Fragen aufwirft, mit denen man sich zukünftig genauer auseinandersetzen sollte/kann.

Permanenter Link

Fabian
am 30.09.2009 - 12:47

Dankeschön! Ein sehr gelungener Beitrag zu HTML5. Gerade die Erklärung mit den Überschriften fand ich sehr verständlich.
Das leidige Browser-Problem ist letztlich ja nichts neues. Aber immerhin gibt es Lösungsansätze, die zumindest im privaten Gebrauch machbar sind.

Permanenter Link

Gunther
am 30.09.2009 - 13:49

Hallo!

Ich kann den Optimismus und die angepriesenen Vorteile der neuen Elemente in HTML 5 nicht ganz teilen. Ich schließe mich u.a. der Kritik von Adrian Bateman an. Bisher ging mein Verständnis von HTML eher in die Richtung, dass Elemente in erster Linie dazu da sind, ihrem jeweiligen Inhalt eine entsprechende (formale) und vorallem eindeutige Semantik zu verleihen.

Davon kann aber bei den allermeisten der neuen Elemente keine Rede sein. Denn was z.B. sollte die formale Semantik eines Header-Elementes sein, außer dass es am Beginn einer HTML Datei steht? Das ergibt sich aber bereits zwangsläufig aus dem linearen Aufbau einer solchen Datei.

Ich sehe keinerlei praktische Vorteile in den neuen Elementen - im Gegenteil! Imho "verwässern" sie das Konzept der Hypertext Markup Language nur und blähen diese dadurch unnötig auf.

Für eine rein der Strukturierung dienenden Aufgabe gibt und gab es bereits die beiden inhaltsleeren Elemente SPAN und DIV. Diese sind imho völlig ausreichend. Und anstatt neuer eigener Elemente, hätte ich hier die Einführung eines neuen Attributes für wesentlich sinnvoller und stimmiger erachtet.

Auch das unsägliche Problem der Hx Überschriften Thematik hätte man auf diese Art und Weise per Attribut einfach und elegant lösen können. Denn entweder ist Text eine Überschrift oder nicht. Die häufig geforderte Frage nach der Ordnung hätte man also ganz einfach per Attribut mit einem entsprechenden Zahlenwert zwischen 1 und ~ regeln können, und hätte somit auch das Problem der Begrenztheit gelöst. Denn mal rein praktisch betrachtet, spielt das jeweilige Element doch eigentlich eh nur eine untergeordnete Rolle, da kein Mensch in den Quelltext guckt, um zu sehen, um welche Überschrift welcher Ordnung es sich handelt. Vielmehr spielt doch nur die Darstellung(sgröße) eine Rolle (zumindest bei visuellen Ausgabemedien) und die wird ohnehin per CSS geregelt.

Nachteilig kommt bei diesem Thema noch dazu, dass es gegen die sich seit Jahren eingebürgerte vorherrschende Meinung läuft, dass jedes HTML Dokument bspw. nur eine H1 Überschrift haben sollte, die dem Seitentitel entspricht.

Ich bin auch imnmer wieder erstaunt darüber, dass man scheinbar aus der ganzen Problematik der Browserinkompatibilitäten aus den letzten Jahren nichts gelernt hat. Denn gerade auch unter diesem für die Praxis so wichtigen Aspekt, wären neue Attribute für bestimmte bestehende Elemente weitaus "allgemeinverträglicher", als neue Elemente!

Ich finde es zunehmend erschreckend und gleichzeitig auch frustrierend, dass zumindest meinem Eindruck nach, die zuständigen Experten jeglichen Bezug zu den Anforderungen der täglichen Praxis des Webdesigns verloren zu scheinen haben. Anders kann ich mir die aktuellen Entwicklungen im Bereich HTML und CSS nicht mehr erklären.

Mal ehrlich: Ich lese und höre so gut wie keine Beschwerden von Webdesignern über fehlende Elemente in HTML. Überhaupt scheint es wenig Grund zur Klage über HTML 4.01 zu geben. Womit sich für mich schon mal die Frage der grundsätzlichen Notwendigkeit von HTML 5 stellt! Und wenn ich mir die Neuerungen dann so angucke, sehe ich bis auf neuerliche Probleme aufgrund unterschiedlicher Browserunterstützung wenig hilfreiches für die Praxis.

Nur kann und sollte man HTML ja auch nicht nur einzeln betrachten, gehört doch CSS untrennbar dazu. Aber auch hier kann ich wenig bis gar keine sinnvollen Neuerungen im aktuellen Entwurf von CSS 3 im Zusammenhang mit HTML 5 erkennen.

Mein Fazit:
HTML 5 ist absolut überflüssig, da es in der Praxis keinerlei wirklichen Vorteile/ Vorzüge bietet, nichts ermöglicht, was nicht vorher auch schon mit HTML 4.01 möglich gewesen wäre, sondern im Gegenteil nur wieder Probleme bezüglich der Browserimplementierungen mit sich bringt!

Und ich finde auch, dass es höchste Zeit ist, den Experten beim W3C & Co. mal deutlich zu sagen, dass ihre Entwicklungen an den Anforderungen der Praxis vorbei zielen, anstatt jede noch so unsinnige Neuerung "schön zu reden" oder "euphorisch" zu feiern, als sei sie das Größte seit Erfindung des Rades!

Gruß Gunther

Permanenter Link
Michael Jendryschik

Michael Jendryschik (Autor)
am 30.09.2009 - 16:25

@Gunther Danke für deinen ausführlichen Kommmentar. Ich finde es gut, dass du deine Bedenken gegen HTML5 mit uns teilst und uns so die Möglichkeit zur Diskussion gibst. Darauf gehe ich gern ein.

Wir unterscheiden uns in der Ansicht, ob der aktuelle HTML5-Entwurf sinnvolle neue Semantiken vorschlägt oder nicht.

Du bist der Ansicht, dass die neuen Elemente »keinerlei praktische Vorteile« mit sich bringen und schreibst stattdessen:

»Ich lese und höre so gut wie keine Beschwerden von Webdesignern über fehlende Elemente in HTML. Überhaupt scheint es wenig Grund zur Klage über HTML 4.01 zu geben.«

Ich bin anderer Meinung. Dass sich niemand regelmäßig offen über die begrenzten Möglichkeiten des heutigen HTML beklagt, hat meiner Ansicht nach weniger damit zu tun, dass HTML kein Wünsche offen ließe, sondern vielmehr damit, dass Klagen darüber bisher nichts brachten.

Dennoch hat Die Vergangenheit gezeigt, dass viele Webautoren mit den bisher vorhandenen Möglichkeiten unzufrieden waren. Anderes lässt sich beispielsweise der Hype um Mikroformate nicht erklären, die Semantiken dort hinzufügen, wo reines HTML keine bereit hält. Mikroformate sind aus meiner Sicht allerdings keine Lösung, weil sie Klassen und andere Attribute »zweckentfremden« bzw. mit Bedeutung überlasten. Aus demselben Grund funktioniert <div id="aside"> auch nicht so gut wie <aside>.

Ich schreibe in meinem Artikel:

»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.«

Die neuen Elemente sind sinnvoll, weil sie reale Bedürfnisse aus der täglichen Arbeit bedienen, nämlich den Aufbau einer grundlegenden Dokumentenstruktur.

Auch wenn wir anderer Meinung sind, kann ich deine Position in diesem Fall verstehen. Man kann immer darüber diskutieren, ob die Anzahl der Elemente, die eine Auszeichnungssprache zur Verfügung stellt, ausreichen oder nicht, ob es zu viele oder zu wenige sind, ob es die richtigen sind oder nicht. Nicht nachvollziehen kann ich allerdings, was du über Überschriften schreibst.

Hast du den Artikel Passende Überschrift hier einsetzen gelesen? Darin erklärt Tomas, weshalb ein stimmiges Überschriftenkonzept wichtig ist; gerade für Leute, die auf die nicht-visuelle Orientierung angewiesen sind. Daher läuft deine Kritik an dieser Stelle ins Leere.

Auch dein Fazit kann ich nicht teilen. Ich denke, dass diese Artikelreihe ganz gut zeit, was HTML5 für Möglichkeiten bieten wird, die Webautoren in Zukunft ihre Arbeit vereinfachen wird. Es geht uns nicht darum, etwas schön zu reden oder in Euphorie zuverfallen; schließlich empfehlen wir den Einsatz von HTML5 noch nicht.

Es ist immer einfach, etwas schlecht zu reden oder komplett abzulehnen. Aber das Ganze in Frage zu stellen, kommt mir ein wenig »kleingeistig« vor. Ich denke, jeder von uns sollte offen für Innovationen und neue Entwicklungen sein.

Permanenter Link

Markus Schlegel
am 30.09.2009 - 19:07

Die Diskussion HTML5 vs. XHTML 2.0 (bzw. mittlerweile nur noch HTML5 vs. Nicht-HTML5) ist eine Diskussion zwischen Verfechtern zweier grundlegend verschiedener Denkweisen, ein Streit zwischen Ideologie und Pragmatik, ein Streit zwischen Fundis und Realos, aber auch ein Streit zwischen Integrität und Korrumption.

HTML5 schafft mit diesem Set an neuen Elementen Werkzeuge, die man schon seit Ewigkeiten bräuchte und auch noch eine Weile brauchen wird. Man spricht bei HTML immer noch von einem Dokument und Dokumente beherbergen eine endliche Anzahl an semantisch differenzierbaren Einheiten, darunter eben header, article, section etc.

Die andere Seite argumentiert mit Erweiterbarkeit, dem seinerzeits trendigen X (eXtensibility). Alles muss erweiterbar sein, eine typische Programmiererdenke, Skalierbarkeit ist wichtig. Das W3C hatte mit XHTML 2.0 weit in die Zukunft gezielt, man kann nicht sagen, was kommt, also hält man sich alle Optionen offen. Das X stand dabei im Mittelpunkt, denn auch wenn sich der XHTML-Standard irgendwann selbst nicht mehr weiterentwickelt, kann man die Sprache ohne Komplikationen erweitern. RDF, XForms, SVG und MathML sind die bekanntesten Beispiele und werden auch noch entwickelt.

XHTML 2.0 ist tot, wie man weiß, aber in meinen Augen steht auch HTML5 alles andere als mitten im Leben. Ja, man kann vieles heute schon einsetzen und ja, der Doctype schadet (noch) niemandem. Die wirklich wichtigen Neuerungen, z.B. lokale Datenbanken, sind aber wahrscheinlich erst dann wirklich implementiert, wenn man schon wieder etwas anderes bräuchte.

We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future.
Ian Hickson

Das halte ich für eine gefährliche Einstellung. Wie lange dauert die Entwicklung von HTML5 nun schon? Und wie lange soll sie noch dauern? Und wann fängt die Zukunft an, bzw. hört die Gegenwart auf?

Dass man offen für Innovationen und Neuerungen sein sollte, ist klar und es wäre für mich als Siebzehnjährigen eine fatale Einstellung, das Gegenteil zu denken. Trotzdem finde ich es dreist, Kritiker als kleingeistig zu bezeichnen. Ich selbst vertrete nicht voll und ganz die Position, die ich hier zu vertreten scheine, ich will zu einer Diskussion und einer kritischen Auseinandersetzung anregen. Schaut man sich diesen Blogartikel und dessen Kommentare an, hat man eine kritische Diskussion vor sich, die es verdient, vom WHATWG beachtet zu werden. Im deutschen Sprachraum ist mir so eine Diskussion noch nie begegnet und das finde ich schade. Hier ist man immer gleich Kleingeist, Fundi, Purist und was weiß ich nicht alles.

Dabei verdient es HTML5 (im positiven Sinn), dass darüber gestritten wird, dass nicht alles einfach so hingenommen wird. Das footer-Element halte ich beispielsweise in der derzeitigen Form für absolut unpraktisch, denn es erlaubt nicht das, was man mit einem footer, im Allgemeinen Sinn, anstellen möchte. Finden die grundsätzlichen Diskussion nicht jetzt statt, hat man sie in fünf Jahren und dann ist es zu spät.

Permanenter Link

Gunther
am 30.09.2009 - 19:29

@Michael
Leider muss ich zu meiner Schande gestehen, dass ich einige Zeit hier nicht vorbeigeschaut habe, und dann heute für mich gleich einige neue Artikel vorhanden waren. Daraufhin habe ich jetzt gleich zu zwei Beiträgen (hier und in "Malen nach Zahlen"), die sich mit HTML 5 und seinen neuen Elementen beschäftigen, einen Kommentar geschrieben. Dass führt nun leider dazu, dass sich die sehr anregende und interessante Diskussion, an der mir sehr viel liegt, teilweise überschneidet.

Zu deiner Antwort:

... sondern vielmehr damit, dass Klagen darüber bisher nichts brachten.

Mag sein. Woran liegt das? Und ist das nicht erst recht ein Grund, den Protest gerade zu verstärken, bzw. lauter werden zu lassen, als sich über die paar mit HTML 5 "dahingeworfenen Brotkrumen" zu freuen?

Nicht nachvollziehen kann ich allerdings, was du über Überschriften schreibst.

Darin erklärt Tomas, weshalb ein stimmiges Überschriftenkonzept wichtig ist; gerade für Leute, die auf die nicht-visuelle Orientierung angewiesen sind. Daher läuft deine Kritik an dieser Stelle ins Leere.

Keineswegs. Gerade der beschriebene Artikel und deine eigene Aussage

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.

bestärken mich doch eher in der Annahme, dass sich das bisherige Konzept mit H1 - H6 Elementen schon nicht bewährt hat, und somit das Festhalten an den Elementen es genauso wenig tun wird. Im Gegenteil: Das Outline-Konzept ist eine dermaßene Verkomplizierung einer semantisch eigentlich sehr einfachen Sache, dass invalider Code und/ oder Browserbugs imho schon vorprogrammiert sind. Im übrigen sehe ich nicht, was mit diesem Konzept möglich sein sollte, was nicht auch mit meinem Vorschlag nur ein H-Element einzuführen, dessen Wertigkeit über ein entsprechendes neues Attribut gesetzt wird, möglich wäre. Über die Varianten, die Überschriften nach dem neuen System per CSS zu stylen, möchte ich dann im Moment lieber auch noch nicht nachdenken!

Auch dein Fazit kann ich nicht teilen. Ich denke, dass diese Artikelreihe ganz gut zeigt, was HTML5 für Möglichkeiten bieten wird, die Webautoren in Zukunft ihre Arbeit vereinfachen wird.

Dein Wort in Gottes Ohr. Nur teile ich nach mittlerweile 15 Jahren Erfahrung deinen Optimismus nicht. Es wird in der Praxis nur wieder eine elend lange "Umstiegsphase" geben, in der die ganzen Neuerungen mangels entsprechender Browserunterstützung nicht, oder nur teilweise verwendet werden können. Auch lassen sie die meisten der real existierenden Anforderungen des täglichen "Weballtages" genauso unangetastet und ungelöst, wie ihre Vorgänger. Was sicherlich zu Teilen auch darin begründet sein mag, dass sich diese mit HTML in der jetzigen Form auch gar nicht lösen ließen.

Es ist immer einfach, etwas schlecht zu reden oder komplett abzulehnen. Aber das Ganze in Frage zu stellen, kommt mir ein wenig »kleingeistig« vor. Ich denke, jeder von uns sollte offen für Innovationen und neue Entwicklungen sein.

Ja, netter Satz. Den unterschreibe ich auch sofort. Nur sehe ich die Kleingeistigkeit und dien mangelnde Offenheit für wirkliche Innovation und neue Entwicklungen woanders als du.

Außerdem lege ich schon wert auf die Feststellung, dass ich nicht nur einfach etwas schlecht geredet habe, sondern zu diversen Dingen auch Alternativvorschläge gemacht habe. Und in vielen Dingen sehe ich eben auch keine wirkliche Neuentwicklung, sondern eben lediglich eine "Flickschusterei". Wie du meinem Kommentar als Antwort auf Jens in dem anderen Beitrag entnehmen kannst, bin ich sicherlich der Letzte, der etwas gegen wirkliche Innovation hat - ganz im Gegenteil. Das in meinen Augen sture Festhalten an einem längst untauglichen Gesamtsystem, welches den Anforderungen um Jahre hinterhinkt, und dessen Weiterentwicklung auch noch unter der Doktrin der strikten Abwärtskompatibilität betrieben wird, das erachte ich als »kleingeistig« und »innovationshemmend«.

Und nicht zuletzt hat man ja kürzlich erst seinen Fortschrittswillen mit dem zu Grabe tragen der XHTML2 Workinggroup unter Beweis gestellt.

BTW: Ich habe die Entstehung des jetzigen HTML 5 Entwurfs eine ganze Zeit lang als sog. Invited Expert auf der Mailingliste verfolgt, bis ich von der teilweisen Engstirnigkeit und Ignoranz die Nase voll hatte. Mir sind also auch durchaus die einen oder anderen Vorschläge bekannt, die im Vorfeld gemacht wurden.

Und wie bereits schon angeschnitten, kann man imho heutzutage einen HTML Standard nicht isoliert als Einzelstück betrachten, sondern muss diesen immer im Zusammenhang/ -spiel mit CSS betrachten. Und auch hier brauchen wir uns wohl nicht über Fortschritt oder Innovationen unterhalten. Dafür dass alle Standards aus demselben Hause kommen, merkt man für meinen Geschmack recht wenig "Zusammenspiel" zwischen den einzelnen Standards. Es wirkt auf mich immer eher als ob die linke Hand nicht wüsste, was die Rechte tut.

Mag sein, dass ich das Ganze kritischer oder argwöhnischer sehe, als viele andere. Aber mich stört mittlerweile die Art, wie die Standards entwickelt werden, so dermaßen, dass ich entschieden der Meinung bin, dass sich im Web langsam mal wieder eine entsprechende Protestbewegung formieren sollte, wie es sie ja u.a. mit WASP schon einmal gegeben hat und noch gibt (allerdings ohne den nötigen Protest). Und ich mag mich von daher auch nicht über solche "Fortschritte" wie aktuell mit HTML 5 freuen oder immer versuchen, jeder Neuerung immer noch etwas Positives abzugewinnen. Denn wie gesagt, für mich sitzt die "Wurzel des Übels" mittlerweile eindeutig woanders.

Um mich aber nicht erneut dem Vorwurf auszusetzen, ich würde einfach nur alles ablehnen und schlecht reden, hier ganz kurz, wie ich mir das z.B. vorstellen könnte:
- Einen klaren Strich unter das bisherige HTML-Konzept ziehen und ein komplett neues System, aufbauend auf den Erfahrungen der letzten 15 Jahre entwickeln. Browser mit zwei separaten Rendering-Engines ausstatten, um die Abwärtskompatibilität zu gewährleisten.
- CSS auf dem jetzigen Stand einfrieren, bzw. ggf. sogar im Layout-Bereich zurückstutzen.
- Für das Layout einen neuen eigenständigen Standard einführen, der aus einer Art Kombination von Javascript und CSS besteht.
- Alle Browserhersteller hätten dieselben Ausgangsbedingungen jeweils einen neuen Browser gemäß den neuen Standards zu entwickeln. Ferner sollten sie sich verpflichten, auf die Implementierung eigener proprietärer Features zu verzichten.

Willkommen du schöne neue Webpublishing Zukunft!

Ich weiß, die Hoffnung stirbt immer zuletzt - aber träumen wird ja noch erlaubt sein. ;-)

Gruß Gunther

Permanenter Link
Michael Jendryschik

Michael Jendryschik (Autor)
am 01.10.2009 - 14:05

@Guther

»[Ich habe] zu zwei Beiträgen (hier und in "Malen nach Zahlen"), die sich mit HTML 5 und seinen neuen Elementen beschäftigen, einen Kommentar geschrieben. Dass führt nun leider dazu, dass sich die sehr anregende und interessante Diskussion, an der mir sehr viel liegt, teilweise überschneidet.«

Um diese Diskussion nicht an zwei Stellen zu führen, beschränke ich mich hier auf die Teile deines Kommentars, die sich konkret auf meinen Artikel beziehen. Deine grundlegende Kritik an der Vorgehensweise bei der Entwicklung von Standards kommentiere ich hier nicht. Lass uns an anderer Stelle darüber diskutieren.

Im übrigen sehe ich nicht, was mit diesem Konzept möglich sein sollte, was nicht auch mit meinem Vorschlag nur ein H-Element einzuführen, dessen Wertigkeit über ein entsprechendes neues Attribut gesetzt wird, möglich wäre.

Dein Vorschlag, h-Elemente als Überschriften zu etablieren und deren Ordnung über ein Attribut festzulegen, löst nicht den zweiten Nachteil, den ich im Abschnitt »Sektionen und Überschriften« anführe. Es ist nämlich häufig nicht klar, in welchem Überschriftenkontext ein »Markup-Schnipsel« steht. HTML5 bietet eine Lösung dafür an.

An dieser Stelle räume ich aber gern ein, dass ich die im XHTML2-Entwurf vorgeschlagenen h-Elemente ohne bestimmte Ordnung konsequenter finde. h1-Elemente in section-Elemente zu verschachteln, entspricht demselben Gedanken, aber mich stört die 1 an dieser Stelle.

Permanenter Link
Michael Jendryschik

Michael Jendryschik (Autor)
am 01.10.2009 - 14:11

@Markus

Das footer-Element halte ich beispielsweise in der derzeitigen Form für absolut unpraktisch, denn es erlaubt nicht das, was man mit einem footer, im Allgemeinen Sinn, anstellen möchte.

Kannst du das bitte etwas weiter ausführen? Was möchtest du denn mit einem Footer »anstellen«, was dir das vorgeschlagene footer-Element nicht gestattet?

Permanenter Link

Markus Schlegel
am 01.10.2009 - 16:21

@Michael
http://www.zeldman.com/2009/09/04/html5-redefines-footer/
http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/

Das war ein Beispiel für die notwendigen Dispute, die dann letztlich auch etwas an der Spec verändern können.

Permanenter Link

Die Kommentare sind geschlossen.