nicht angemeldet
Man hätte evt. auch Überschrift und Slogan als
<hgroup>
<h1>Unsere tolle Site</h1>
<h2>Unser toller Slogan</h2>
</hgroup>
> auszeichnen können?
Ja, das wäre eine mögliche Alternative.
> Denn nach <http://dev.w3.org/html5/spec/Overview.html#the-nav-element> ist imho das TOC doch genau der zweite Anwendungsfall für das <nav> Element neben der Hauptnavigation, während eben bspw. die Links im Head und im Footer eben nicht in <nav> eingeschlossen werden (müssen).
Stimmt, das wäre wohl die bessere Variante.
> Ich hätte eher ein <aside> für die Kommentare erwartet.
Passt durchaus auch, ja.
> Und ich habe auch schon des öfteren gesehen, dass Autoren jeden Kommentar als eigenständigen <article>, teils mit <header> und <footer>, ausgezeichnet haben.
Von der Struktur her ist das sicher gerechtfertigt, für mich wäre das im Kontext von Blogs Sectioning-Overkill.
> Irgendwo (kann es gerade nicht wiederfinden) habe ich mal gelesen (sinngemäß):
> "aside != sidebar".
Es gab mal einen HTML5Doctor-Artikel, der aber [revidiert wurde](http://html5doctor.com/aside-revisited/).
Die aktuelle Spezifikation erlaubt es durchaus, dass eine Blog-Sidebar mit aside ausgezeichnet wird (auf Ebene der body-Section).
Ein [Beispiel in der Spec](http://dev.w3.org/html5/spec/sections.html#the-aside-element) zeigt den Code eines Blogs und nutzt aside + mehrere navs für die klassische Sidebar.
> Also wäre imho im vorliegenden Fall bspw. ein <aside> für den Block "mit diversen Links (intern + extern)" semantisch richtiger, als ein <section>
Du meinst im Footer?
Wenn diese Linklisten aside sein sollen, was ist der Hauptinhalt des Footers?
Ein Footer als Liste von asides? Das ergibt keinen Sinn. footer auf oberster Ebene sagt ja bereits, dass es sich um Zusatz- oder Meta-Inhalt handelt. Das jeweils nochmal in asides zu verpacken, halte ich für doppelt gemoppelt.
> > Nicht sichtbar, aber helfen bei der Tastaturnavigation!?
Ja. Erstens kann man Überschriften »zugänglich« verstecken, sodass sie beispielsweise in Screenreadern existent sind und durch entsprechende Tastatur-Shortcuts (z.B. auch im Opera) angesprungen werden können. Zweitens gibt es Techniken, bei denen z.B. eigentlich versteckte Sprunglinks beim Fokussieren eingeblendet werden.
> Also mich bestärkt alleine dieses kleine und sehr gängige Beispiel in meinem Eindruck, dass es wesentlich schwieriger ist mit HTML5 semantisch korrektes Markup zu schreiben, als mit HTML 4.
Mehr Möglichkeiten heißt auch mehr Lösungsvarianten.
> Denn ich bin mir ziemlich sicher, dass unsere beiden Entwürfe mit HTML 4 wesentlich ähnlicher gewesen wären.
Das denke ich nicht. Jeder hätte seine ganz eigene div-Suppe gekocht und wir hätten uns trefflich über sinnvolle Gruppierung und sinnvolle Benennung der IDs und Klassen streiten können.
> Und wenn noch 5 Leute einen HTML 5 Entwurf erstellen, werden vermutlich noch mind. 2 andere Varianten dabei sein ...!
Wo ist das Problem? Es gibt nicht die eine korrekte Auszeichnung und alle anderen sind falsch oder suboptimal. Man kann unterschiedliche Schwerpunkte setzen.
> Und dann habe ich noch eine ganz andere Frage: Ich habe die letzten Jahre eigentlich immer XHTML 1.0 strict verwendet. Nun erlaubt HTML5 ja einige Dinge (<a> für Blöcke, <noscript> im <head> u.a.), die bisher bei HTML 4 nicht erlaubt waren. Allerdings sind diese dann ja nicht XHTML konform.
a für Blöcke sollte XHTML5-konform sein. Habe ich gerade mit dem [Validator](http://validator.nu/) geprüft (als Preset XHTML5 einstellen).
noscript wird in XHTML5 – welches sich immer als application/xhtml+xml definiert – an sämtlichen Stellen nicht unterstützt, weil es eine Parseranweisung ist, welche von einem XML-Parser nicht unterstützt werden kann. Das ist aber nichts neues, das galt auch für XHTML 1.x als application/xhtml+xml.
Mathias
suit
Gunnar Bittersmann
Der Martin