molily: HTML5 - Schuss in den Ofen ?

Beitrag lesen

Hallo,

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.

Was ist das Problem dabei? Was ist daran so schwierig?
Ich sehe nicht, dass man »verdammt aufpassen« muss. Man muss jeden Abschnitt in eine Section hüllen, das ist alles. Ich habe damit schon einige Websites umgesetzt, auch dynamisch generierte, mehrfach verschachtelte Sections.

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

Du kannst sie per CSS formatieren, du kannst sie per Script z.B. auf- und zuklappen, ein Inhaltsverzeichnis generieren und vieles mehr.

Ach, du meinst so wie beim Weblog?
Das kommt für mich dem Zwang zu
<body><h1></h1>...
gleich.

Auch wenn ich es präferiere, so muss auf oberster Ebene muss nicht unbedingt nur eine Section liegen, die alle anderen umschließt. Für beide Varianten gibt es Vor- und Nachteile und m.W. sind auch beide verbreitet. Ich sehe kein praktisches Problem darin, dass der body eine »Untitled Section« bildet. Beispielsweise Screenreader, welche einem ein Outline erzeugen und dem Nutzer präsentieren, werden sicherlich nicht »Unbenannter Abschnitt« o.ä. daraus machen. Ihnen steht es frei, unbenannte Abschnitte auf oberster Ebene nicht in diese Navigation aufzunehmen.

Das SELFHTML-Weblog ist so eingerichtet, dass die Struktur auf einer Einzelseite Sinn ergibt (wo es nur ein h1 gibt). Dass auf der Übersichtsseite dasselbe Markup verwendet wird und somit viele <h1> auf einer Ebene liegen, hat liegt mehr an Template-Beschränkungen.

Semantisches Markup ist trotzdem vorzuziehen.
Auch wenn ich dir im Kern durchaus zustimme, würde mich dennoch interessieren warum?

Weil ein sinnvoll strukturiertes Dokument viele Präsentationen haben kann anstatt nur eine. Weil User-Agents die Daten vielseitig auswerten können, was bei <font> nicht möglich ist.

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

Nicht ausschließlich. Der Nutzer kann etwa durch die Überschriften springen, wenn sie sinnvoll ausgezeichnet sind. Es ist überhaupt möglich, eine Präsentation auf Dokumentenstruktur basieren zu lassen, beispielsweise durch User-Stylesheets.

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

Bei Elementen ist dasselbe der Fall, wie Daniel auch schreibt. Lediglich ältere IEs parsen ohne Shim die Elemente nicht. Die Idee ist jedoch, dass unbekannte Elemente und Attribute ins DOM aufgenommen werden. HTML5 spezifiziert diese Aufwärtskompatibilität.

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.

Selbst angenommen, die Bedeutung wäre schlecht definiert – eine Meinung, die ich nicht teile –, so sehe ich nicht, welchen Vorteil es gehabt hätte, an ihrer statt Attribute zu definieren.

Mathias