Gunther: HTML5 - Schuss in den Ofen?

Beitrag lesen

Hallo werte Selfgemeinde!

Ich beschäftige mich seit einiger Zeit mit den Neuerungen von HTML5 und deren Konzept.
Vermutlich bin ich nicht intelligent genug, um die Dinge alle richtig und vollständig zu verstehen, denn so manches erschließt sich mir auch nach dem 20. Mal lesen nicht ...!

Deshalb hier mal in loser Reihenfolge einige Punkte, die ich nicht (so ganz) verstehe, und auch meine Meinung zu einigen Dingen. Wohl gemerkt - einige Aussagen sind bewußt etwas provokant gehalten. Ich hoffe ggf. auf eine rege Diskussion, die die Dinge vlt. etwas erhellt.

Outline algorithm:
Mal abgesehen davon, dass dieser derzeit noch von keinem HTML verarbeitenden Programm unterstützt wird, scheint mir hier in erster Linie das Problem im möglichen Styling per CSS zu liegen.
Folgender Beispielcode:

  
<body>  
<h1>My fantastic site</h1>  
<section>  
  <h1>About me</h1>  
  <p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>  
  <section>  
    <h1>What I do for a living 1</h1>  
    <p>I sell enterprise-managed ant farms.</p>  
    <h2>What I do for a living 2</h2>  
    <p>I sell enterprise-managed ant farms.</p>  
  </section>  
</section>  
<section>  
  <h1>Contact</h1>  
  <p>Shout my name and I will come to you.</p>  
</section>  
</body>  

erzeugt folgende Outline:
1. My fantastic site
    1. About me
        1. What I do for a living 1
            1. What I do for a living 2
    2. Contact

Das Problem dabei ist, dass neuere Browser "What I do for a living 1" per default als <h3> Element behandeln, wohingegen "What I do for a living 2" aber völlig regulär als <h2> behandelt wird, obwohl es ja laut unserer Outline eindeutig ein <h4> Element sein müsste.
Damit es entsprechend funktioniert, ohne die Outline zu verändern, muss ich anstelle des <h2> Elements ein <h1> verwenden und dieses aber wiederum in ein weiteres <section> Element verpacken:

  
<body>  
<h1>My fantastic site</h1>  
<section>  
  <h1>About me</h1>  
  <p>I am a man who lives a fascinating life. Oh the stories I could tell you...</p>  
  <section>  
    <h1>What I do for a living 1</h1>  
    <p>I sell enterprise-managed ant farms.</p>  
    <section>  
      <h1>What I do for a living 2</h1>  
      <p>I sell enterprise-managed ant farms.</p>  
    </section>  
  </section>  
</section>  
<section>  
  <h1>Contact</h1>  
  <p>Shout my name and I will come to you.</p>  
</section>  
</body>  

Das heißt für mich, dass wenn ich Überschriften gemäß ihrer eigentlichen Gewichtung optisch entsprechend dargestellt haben möchte (was ja nicht ganz unwesentlich ist), dann muss ich auf das Konzept der ausschließlichen Verwendung von <h1> Elementen zurückgreifen. Zusätzlich wird mein Quellcode dadurch noch aufgebläht, weil ich jedesmal noch ein weiteres 'sectioning' Element drumherum benötige. Von der Einbindung von Code aus "fremden" Quellen (bspw. als Zitat) mal ganz zu schweigen ...! Oder es bleibt alles beim alten, indem ich selber für die Wahl des korrekten <hx> Elements zuständig bin (womit ja dann nichts gewonnen wäre).

Ebenso unverständlich ist mir, warum man, will man eine fehlende Überschrift in der Outline vermeiden, der Body Sektion zwingend eine Überschrift verpassen muss, und warum man dafür nicht das <title> Element aus dem <head> verwendet hat!?

Oft liest man im Zusammenhang mit HTML5 und der damit verbundenen Einführung neuer Elemente, dies diene der besseren semantischen Gliederung eines Dokuments. Schön und gut, aber halten wir mal fest, dass User/ Besucher einer Seite nicht den Quellcode präsentiert bekommen, sondern das durch einen UA interpretierte Ergebnis dessen. Hier handelt es sich also schon mal nicht um eine Neuerung, Bereicherung oder Verbesserung für den User (zumindest nicht für visuelle Ausgabemedien), sondern allenfalls um welche für Suchmaschinen & Co.!
Auch erscheint mir der gewählte Weg, nämlich der der neuen Elemente, wenig sinnvoll. Denn erstens reichen diese paar neuen Elemente garantiert nicht aus und zweitens sind Veränderungen/ Erweiterungen schwierig, da diese immer von der jeweiligen Unterstützung durch die Browser abhängig sind.
Ich hätte es als wesentlich sinnvoller erachtet, wenn man stattdessen ein/ mehrere neues/ neue Attribut/e eingeführt hätte, wie bspw. die Übernahme des 'role' Attributs aus XHTML. Denn mal ehrlich - wo ist der Unterschied zwischen <nav> und <div role="nav">? Einen Unterschied gibt es auf jeden Fall: Die Handhabung unbekannter Elemente (im Vergleich zu der unbekannter Attribute) seitens der Browser. Und wie groß ist der tatsächliche Nutzen dieses neuen <nav> Elements, wenn es sowohl die Hauptnavigation einer Seite, als auch die Blogroll eines Blogs oder die Sammlung von Links zu anderen Artikeln in einem CMS umschließen kann?
Und mit den anderen neuen Elementen verhält es sich imho genauso. Ebenfalls bestens als "ungünstig" ist auch die Namensgebung zu erachten. So ist es doch schon ein quasi Standard, dass sehr viele Autoren ihre Seiten mittels DIV Container in <div id="header">, <div id="nav">, <div id="content"> und <div id="footer"> unterteilen (nicht zuletzt auch durch die weit verbreiteten Skripte wie Wordpress & Co.). Sehr clever, genau diese Bezeichnungen zu wählen und den Elementen dabei aber eine teils völlig andere Bedeutung zukommen zu lassen. So sieht man bspw. schon sehr häufig auf Seiten, die HTML5 verwenden, den Einsatz von <header> anstelle von <div id="header"> (gleiches gilt für das <footer> Element). Tatsächlich ist das <header> Element mehr zur Kennzeichnung von Überschriften/ Titeln einzelner semantischer Blöcke gedacht (vgl. http://www.w3.org/TR/html5/sections.html#the-article-element). Mir stellt sich in dem Zusammenhang erneut die Frage nach dem Sinn & Nutzen, außer dass der Quelltext zusätzlich aufgebläht wird?

Und zumindest bei "aufwändigeren" Layouts wird man auch zukünftig nicht um die Verwendung von DIVs herumkommen. Das bestärkt mich in meiner Meinung, dass es besser gewesen wäre, Autoren die Möglichkeit zu geben, bestimmten ansonsten "inhaltsleeren" DIV Elementen per Attribut eine entsprechende semantische Bedeutung zu verpassen (und/ oder auch eine repräsentative).

Viele der weiteren Neuerungen von HTML5 mögen durchaus sehr sinnvoll sein, allerdings habe ich mich mit denen noch nicht eingehend genug beschäftigt, um mir eine Meinung zu bilden.
Die oben genannten Neuerungen sind aber für mich auch primär die, um die zukünftig kein Autor drumherum kommen wird (sofern er HTML5 verwendet). Insofern "reichen" mir diese auch für den Anfang ...!

Mit anderen Worten sehe ich es so, dass uns HTML5 im wesentlichen eine Verkomplizierung von HTML bringt (aufgrund des neuen Sectioning Modells), deren Nutzen für den "gemeinen Autor" für mich mehr als fragwürdig ist. Auch semantisch korrektes Markup zu schreiben dürfte eher schwieriger, als einfacher werden, weil gerade die neuen Elemente dafür prädestiniert sind, sie "falsch" zu verwenden.

Ferner werden zumindest auch neue "Stolpersteine" bezüglich des Stylings durch CSS geschaffen.

Mein Fazit:
Wesentliche Teile der Neuerungen sind wenig sinnvoll und hätten anders besser gelöst werden können. Auch werden teilweise unnötig neue Probleme geschaffen. Und das alles mit einem fragwürdigen Nutzen für Autoren und Besucher.

Das bringt mich zu der alles entscheidenden Frage: "Warum ich sollte ich HTML5 (jetzt|zukünftig|jemals) verwenden?"

Aber vielleicht liegt es wie eingangs bereits erwähnt auch nur daran, dass sich mir der "große Zusammenhang" (bisher zumindest) noch nicht erschlossen hat?

Wie ist eure Meinung/ Sicht der Dinge?

Gruß Gunther