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,
Das sagte ich ja bereits. Nur was habe ich dann durch HTML5 "gewonnen"? Nach meinem Verständnis sollte doch gerade die Problematik der Überschriften Hierarchien (insbesondere bei dynamisch generierten Seiten) gelöst werden.
zweitens hast du Sections anscheinend missverstanden.
Nein, habe ich nicht.
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.
Den Eindruck habe ich auch. Was ich sagen will, ist dass das Problem der Überschriften Hierarchien nicht gelöst, sondern lediglich verlagert worden ist, nämlich von den Überschriften zu den Sections. Damit hat man als Autor unterm Strich nichts gewonnen. Stattdessen muss man aber zukünftig verdammt darauf aufpassen, dass man die gewünschte Dokument Struktur (Outline) erhält.
http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-outlining-algorithm/ bietet eine gute Übersicht und Links.
Danke - die Quellen sind mir alle bekannt und ich habe die meisten davon auch bereits ausführlich studiert.
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.
Du irrst hier übrigens, was das header und footer Element anbelangt - http://www.w3.org/TR/html5/sections.html#the-header-element
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.
OK. Und welchen Nutzen/Sinn hat das (für 90% aller Webseiten)?
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.
Ach, du meinst so wie beim Weblog?
Das kommt für mich dem Zwang zu
<body><h1></h1>...
gleich. Und ich frage ernsthaft nach dem Sinn & Zweck. Wenn die Body (=Root) Sektion keine Überschrift hat, warum wird dann nicht automatisch der <title> genommen? Das würde ja nun wirklich keinem weh tun, aber sehr wirkungsvoll verhindern, dass eine Outline mit fehlender oberster Überschrift entsteht. Frei nach dem Motto "Keep it as simple as possible!" und nicht immer mehr "Stolpersteine" ...!
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 wenn ich dir im Kern durchaus zustimme, würde mich dennoch interessieren warum?
Denn prinzipiell zählt ja wohl erstmal die syntaktische Korrektheit. Und die Semantik (für den User) ergibt sich bei visuellen Ausgabemedien durch die Präsentation (also letztlich durch die CSS Formatierung).
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.
Es geht nicht um die Frage Neuerungen Ja oder Nein, sondern darum Wie!
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.
Alle diese Varianten setzen Javascript voraus. Aber darum geht es auch nicht. Bisher war eine der obersten Grundregeln, dass ein Browser alles ignoriert, was er nicht kennt. Wenn man sich weiterhin an diesen Grundsatz hält (der sich imho sehr bewährt hat), dann erscheint mir es zumindest sinnvoller, eher neue Attribute anstelle von neuen Elementen zu verwenden. Denn wenn ein Attribut mangels Kenntnis ignoriert wird, dann geht lediglich ein Stück der Semantik des Markups "verloren"!
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/
Es kann doch nicht Sinn der Sache sein, dass wenn ich schon einen Standard erweitere, bzw. teilweise völlig neu definiere, von vorneherein auf Bestandteile anderer Standards zurückzugreifen, anstatt diese direkt in den Standard zu implementieren.
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?
Man kann Dinge auch absichtlich missverstehen ...! Wie man das Attribut nennt, sei doch erstmal dahingestellt. Von mir aus kannst du es auch "meaning" oder sonstwie nennen. Und imho geht eben vielen der neuen Elemente eine entsprechende semantische Bedeutung ab, bzw. ist so "verschwommen", dass die Bedeutung gegen Null geht - bspw. beim <aside> Element. Aber auch <header> und <footer> sind nicht viel eindeutiger. Hier wäre man eben m.E.n. mit einem, bzw. mehreren neuen Attributen und einer entsprechenden Vielzahl möglicher Werte wesentlich besser bedient gewesen. Zumal dieses "System" wesentlich besser und einfacher zu erweitern wäre und außerdem die Möglichkeit der Angabe mehrerer Werte zu einer genaueren Spezifizierung zugelassen hätte.
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.
Sagt wer?
Zitat:"The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links." (http://www.w3.org/TR/html5/sections.html#the-nav-element)
Das kann man aber auch völlig anders interpretieren. Das ist im Grunde auch einer meiner Kritikpunkte, dass ich der Auffassung bin, dass der Wunsch nach semantisch korrekterem Markup bei der gewählten Umsetzung eher zum Gegenteil führt.
Gunnar Bittersmann
Der Martin