nicht angemeldet
Hallo,
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.
Nein, musst du nicht.
Erstens kannst du weiterhin h1, h2, h3 verwenden, wie es in HTML 4 üblich ist, zweitens hast du Sections anscheinend missverstanden. Wenn du sämtliche Abschnitte sinnvoll mit Sectioning-Elementen auszeichnest, dann funktioniert das auch hervorragend. Ob mit h1, h2, h3 ... oder mit ausschließlich h1. Ich verstehe dein Problem damit nicht.
http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/ bietet eine gute Übersicht und Links.
Zusätzlich wird mein Quellcode dadurch noch aufgebläht, weil ich jedesmal noch ein weiteres 'sectioning' Element drumherum benötige.
?? Ein Abschnitt wird mit section (oder article, aside, footer, header, nav) ausgezeichnet, das ist der Sinn davon.
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).
Doch. Du hast Abschnitte explizit als solche ausgezeichnet, als dass es nur implizit über die Überschriftenhierarchie getan wird.
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!?
Weil der Titel des Dokuments gleich nicht die oberste Überschrift des Dokuments ist?
Davon abgesehen sehe ich nicht, was so schwierig dabei ist, die oberste Überschrift mit h1 auszuzeichnen und dafür zu sorgen, dass sie vom Sectioning zur obersten body-Section gehört. Man macht m.M.n. etwas falsch, wenn es nicht automatisch so ist.
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.!
Ja. Das nennt sich semantisches Markup. Das ist, was HTML seit 15 Jahren tut. Der Benutzer sieht ggf. nicht, ob ein ihm fett erscheinender Text mit <b> ausgezeichnet ist oder mit <strong>, welches per CSS fett formatiert wurde. Der Benutzer sieht ggf. nicht, ob eine Überschrift mit <br><font></font><br> ausgezeichnet ist, oder mit <h2>. Semantisches Markup ist trotzdem vorzuziehen.
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.
So ist die Welt der Browsertechnik. Neuerungen sind anfangs nie von allen Browsern unterstützt. Ist das jetzt ein Argument, das prinzipiell gegen sämtliche Erweiterungen spricht? Sicher nicht.
Wie schwierig Erweiterungen sind, hängt ganz vom jeweiligen Element ab. Beim Sectioning ist es eigentlich kein Problem, wenn man den IE per HTML5-Shiv versorgt. Bei komplexeren Elementen wie canvas bedarf es aufwändigerer Polyfills.
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.
role ist Bestandteil von WAI-ARIA und WAI-ARIA ist in HTML5 direkt nutzbar, oft zusätzlich zu den HTML5-Elementen. Andere HTML5-Elemente haben von Haus aus eine Landmark-Role.
http://dev.w3.org/html5/spec/content-models.html#wai-aria
http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/
Denn mal ehrlich - wo ist der Unterschied zwischen <nav> und <div role="nav">?
Das eine ist ein spezifisches HTML-Element mit der passenden Semantik und das andere ist ein generisches HTML-Element mit einer Erweiterung aus einem anderen Sprachvokabular, um seine Bedeutung zu spezifizieren. Welches ist wohl vorzuziehen?
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?
Wenn man nav richtig verwendet, dann ist der Nutzen groß.
Ein Blogroll oder eine Linksammlung sollten nicht mit nav ausgezeichnet werden.
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).
Dagegen spricht nichts. Die header- und footer-Elemente können auf oberster Section-Ebene für viele bestehende Header und Footer verwendet werden. Nicht immer, aber häufig.
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).
Das ist kein Widerspruch.
Und zumindest bei "aufwändigeren" Layouts wird man auch zukünftig nicht um die Verwendung von DIVs herumkommen.
Selbstverständlich. div-Elemente existieren weiterhin und haben ihre Anwendungszwecke. Sectioning-Elemente waren nie als ein Ersatz für div als rein gruppierendes Element ohne Sectioning-Bedeutung gedacht.
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).
Das tun die neuen Sectioning-Elemente.
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).
Jeder kann darum herum kommen. Es wird niemand dazu gezwungen, die neuen Elemente zu verwenden.
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.
Das ist nun nichts neues. Auch die Elemente von HTML 4 waren ständig Gegenstand einer Diskussion um deren richtige Benutzung. HTML 5 hat da aber mehr für Aufklärung gesorgt. Es ist weitgehend gut definiert, für was die neuen Elemente gedacht sind. Was natürlich nicht verhindern kann, dass irgendjemand sie falsch verwendet. Diese Möglichkeit ist aber kein Argument gegen sie.
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?
Zumindest scheinst du noch einigen Missverständnissen aufzusitzen.
Mathias
suit
Gunnar Bittersmann
Der Martin