Zur Info: Interessanter Artikel zu sectioning content

[Beat]

Ich finde den Artikel
http://www.456bereastreet.com/archive/201103/html5_sectioning_elements_headings_and_document_outlines/
lesenwert für alle, die sich mit HTML5 beschäftigen und der Frage, wie sich jetzt normale Webpages strukturiert präsentieren.

Ich bin sicher, er beantwortet nicht nur eine offene Frage, sondern wirft auch (zum Güggel nochmal) neue auf.

mfg Beat

[ChrisB]

Hi,

Ich finde den Artikel
http://www.456bereastreet.com/archive/201103/html5_sectioning_elements_headings_and_document_outlines/
lesenwert für alle, die sich mit HTML5 beschäftigen und der Frage, wie sich jetzt normale Webpages strukturiert präsentieren.

Ich bin sicher, er beantwortet nicht nur eine offene Frage, sondern wirft auch (zum Güggel nochmal) neue auf.

Wobei “WTF were they thinking?” in Bezug auf HTML5 ja nun keine sonderlich neue Frage sein dürfte ...

Insb. die angesprochenen Punkte bzgl. ARTICLE finde ich iritierend bzw. besorgniserregend.
Ich hatte bisher angenommen, für eine bspw. blog-artige Struktur könnte man ARTICLE sowohl für Auflistungen von Einträgen als auch Einzelseiten, die nur diesen Eintrag darstellen, verwenden, und somit im Markup konsistent bleiben, was die Auszeichnung eines Eintrages angeht, egal in welchem Kontext. Aber wie es aussieht, macht einem der outline algorithm in seiner derzeitigen Form einen Strich durch die Rechnung. Um ein und das selbe darzustellen, wären also unterschiedliche Auszeichnungen erforderlich, je nach Kontext. Klingt nicht besonders logisch und konsequent für mich.

MfG ChrisB

[suit]

Wobei “WTF were they thinking?” in Bezug auf HTML5 ja nun keine sonderlich neue Frage sein dürfte ...

Aufpassen und nicht zu viel gegen HTML5 wettern, sonst gibt es schlechte Stimmung.

Ich hatte bisher angenommen, für eine bspw. blog-artige Struktur könnte man ARTICLE sowohl für Auflistungen von Einträgen als auch Einzelseiten, die nur diesen Eintrag darstellen, verwenden, und somit im Markup konsistent bleiben, was die Auszeichnung eines Eintrages angeht, egal in welchem Kontext.

Davon ging ich auch aus - aber das hatten die Superfriends afaik auch schon mal bemängelt, dass die Benennung der Elemente etwas impliziert, was aktuell gängige Praxis ist aber in der Spezifikation offensichtlich ganz anders ist.

z.B. beim footer-Element.

[molily]

Davon ging ich auch aus - aber das hatten die Superfriends afaik auch schon mal bemängelt, dass die Benennung der Elemente etwas impliziert, was aktuell gängige Praxis ist aber in der Spezifikation offensichtlich ganz anders ist.

z.B. beim footer-Element.

Diese Kritik zielte in erster Linie darauf ab, dass das Content-Model von footer restriktiver als header war. Das ist schon lange nicht mehr der Fall und wurde IIRC kurz nach Veröffentlichung der Superfriends-Kritik abgeändert. Ein Footer kann jetzt genauso aufgeblasen sein wie ein Header. Er sollte es nur nicht.

Wenn man hier weitere Kritik dieser Art anbringt, ...

»For example, “footer” is commonly used to denote a portion of the template at the bottom of the page. Footers may well contain copyright or other meta information, but generally it is understood to simply be content which is secondary to that which is within the #body. It may contain tertiary navigation, sections, or even headings.«

... dann müsste man schon das gesamte Sectioning-Modell infrage stellen, welches Header und Footer eben nicht als dokumentweit, sondern immer als einer Section zugehörig definiert. Damit sind sie beide logischerweise nicht gleichzeitig eigene Sections. Das finde ich erst mal konsequent und das komplett aufzuweichen würde wirklich das Sectioning-Modell sprengen. Kann man natürlich fordern.

Mathias

[suit]

... dann müsste man schon das gesamte Sectioning-Modell infrage stellen, welches Header und Footer eben nicht als dokumentweit, sondern immer als einer Section zugehörig definiert. Damit sind sie beide logischerweise nicht gleichzeitig eigene Sections. Das finde ich erst mal konsequent und das komplett aufzuweichen würde wirklich das Sectioning-Modell sprengen. Kann man natürlich fordern.

Diese Sache ist ja gerade das, was für mich unverständlich ist. Jetzt schon kann kaum jemand ein halbwegs ordentlich semantisch nachvollziehbares Dokument verfassen - HTML5 stellt zusätzlich eine vordefinierte Semantik bereit die kaum jemand versteht, wenn er die Spezifikation nicht genau liest.

Zwar begrüße ich, dass HTML5 semantischer wird, aber die Grundidee dahinter, dass eine Maschine aufgrund der Auszeichnung den Inhalt zerlegen kann (Outlining) ist imho von vorne herrein zum Scheitern verurteilt. Ein überwiegender Großteil der Webseiten ist nicht valide und fern ab von jeglicher Semantik - die Arbeitsweise derjenigen die diese Seiten erstellt haben wird sich durch HTML5 nicht ändern. Die daraus resultierenden Dokumente werden vom Erwartungswert abweichen und es somit quasi unmöglich machen, dass jemand ein Dokument maschinell aufgrund den Outline-Regeln von HTML5 verarbeitet.

Der Sinn dahinter wäre - soweit ich das verstanden habe - dass man sich redundanten geschichten wie etwa RSS sparen kann, da man im HTML-Dokument ja schon alles ordentlich und logisch auszeichnen kann - aber dass das fruchtet bezweifle ich.

[molily]

Diese Sache ist ja gerade das, was für mich unverständlich ist. Jetzt schon kann kaum jemand ein halbwegs ordentlich semantisch nachvollziehbares Dokument verfassen

Nein, kann man nicht. Es ist nicht möglich, Abschnitte semantisch zu kennzeichnen. Es gibt Überschriften, klar. Die kennzeichnen die jeweils folgenden Inhalte. Das Modell von Sections ist da natürlich komplizierter, letztlich aber weitaus mächtiger und semantischer.

HTML5 stellt zusätzlich eine vordefinierte Semantik bereit die kaum jemand versteht, wenn er die Spezifikation nicht genau liest.

Semantikdiskussionen gab es vor zehn Jahren schon und wird es immer geben. Man denke nur an abbr vs. acronym. Auch die neuen HTML5-Elemente bedürfen einer Erläuterung. Einfach und selbsterklärend ist das alles nicht. Sinnvolles HTML ist nicht einfach. Ich persönlich würde das aber auch nicht erwarten.

Zwar begrüße ich, dass HTML5 semantischer wird, aber die Grundidee dahinter, dass eine Maschine aufgrund der Auszeichnung den Inhalt zerlegen kann (Outlining) ist imho von vorne herrein zum Scheitern verurteilt.

Die Möglichkeit der automatisierten Verarbeitung war und ist die Grundlage von HTML. Suchmaschinen und Screenreader sind wohl die wichtigsten UAs, die massiv auf Outlining basieren.

Die daraus resultierenden Dokumente werden vom Erwartungswert abweichen und es somit quasi unmöglich machen, dass jemand ein Dokument maschinell aufgrund den Outline-Regeln von HTML5 verarbeitet.

Das Problem wurde nun nicht mit HTML5 eingeführt, schon bei HTML4 hatten etwa Screenreader das Problem, dass Überschriftenhierarchien nicht konsequent umgesetzt wurden. Und Google musste damit rechnen, dass es 15 »h1« genauso gibt wie nur fünf »h4«, und trotzdem irgendwie versuchen, eine Art Outline zu erstellen, indem es den Hauptinhalt identifiziert.
Das heißt ja nicht, dass HTML nicht definieren sollte, wie man es richtig macht, denn richtig angewandt ist der Nutzwert sehr hoch.

Der Sinn dahinter wäre - soweit ich das verstanden habe - dass man sich redundanten geschichten wie etwa RSS sparen kann, da man im HTML-Dokument ja schon alles ordentlich und logisch auszeichnen kann - aber dass das fruchtet bezweifle ich.

Jein. HTML5 ist ja nicht gleich hAtom oder Microdata. Atom und andere Syndication-Formate verfolgen noch einmal einen anderen Ansatz als HTML. Klar, man kann so etwas wie Syndication auch mit HTML5 machen, wenn ein Blog ordentlich mit article und Co. ausgezeichnet ist. Die Anwendungsfälle sind da aber noch etwas anders gelagert.

Mathias

[Tim Tepaße]

Jein. HTML5 ist ja nicht gleich hAtom oder Microdata.

Der HTML-zu-Atom-Algorithmus ist derzeit trotz diverser Kritik wie am GUID-Generierungs-Mechanismus wieder in der Spec drin.

[suit]

Diese Sache ist ja gerade das, was für mich unverständlich ist. Jetzt schon kann kaum jemand ein halbwegs ordentlich semantisch nachvollziehbares Dokument verfassen

Nein, kann man nicht. Es ist nicht möglich, Abschnitte semantisch zu kennzeichnen. Es gibt Überschriften, klar. Die kennzeichnen die jeweils folgenden Inhalte. Das Modell von Sections ist da natürlich komplizierter, letztlich aber weitaus mächtiger und semantischer.

HTML5 stellt zusätzlich eine vordefinierte Semantik bereit die kaum jemand versteht, wenn er die Spezifikation nicht genau liest.

Semantikdiskussionen gab es vor zehn Jahren schon und wird es immer geben. Man denke nur an abbr vs. acronym. Auch die neuen HTML5-Elemente bedürfen einer Erläuterung. Einfach und selbsterklärend ist das alles nicht. Sinnvolles HTML ist nicht einfach. Ich persönlich würde das aber auch nicht erwarten.

Zwar begrüße ich, dass HTML5 semantischer wird, aber die Grundidee dahinter, dass eine Maschine aufgrund der Auszeichnung den Inhalt zerlegen kann (Outlining) ist imho von vorne herrein zum Scheitern verurteilt.

Die Möglichkeit der automatisierten Verarbeitung war und ist die Grundlage von HTML. Suchmaschinen und Screenreader sind wohl die wichtigsten UAs, die massiv auf Outlining basieren.

Das halte ich für ein Gerücht - zwar ist das Outlining hier wichtig, aber die Struktur der Dokumente ist Google sicher herzlich egal. Ob du da <font size="5"> oder <h2> notierst ist denen egal, die finden die Inhalte schon auch wenn sie nicht vernünftig ausgezeichnet oder hochgradig invalide (mit Verschachtelungsfehlern) sind. Das müssen sie eben auch, weil der Großteil der vorhandenen Dokumente nicht sinnvoll ausgezeichnet ist oder ungükltig ist.

Das heißt ja nicht, dass HTML nicht definieren sollte, wie man es richtig macht, denn richtig angewandt ist der Nutzwert sehr hoch.

Das streite ich auch nicht ab - nur ist mittlerweile HTML5 in dieser hinsicht so "kompliziert", dass es die die es bei HTML 4.01 schon falsch machen ohnehin wieder falsch machen werden und die Gefahr aufgrund der genannten Verwirrungen hinsichtlich Benennung auch andere falsch machen werden.

Der Sinn dahinter wäre - soweit ich das verstanden habe - dass man sich redundanten geschichten wie etwa RSS sparen kann, da man im HTML-Dokument ja schon alles ordentlich und logisch auszeichnen kann - aber dass das fruchtet bezweifle ich.

Jein. HTML5 ist ja nicht gleich hAtom oder Microdata. Atom und andere Syndication-Formate verfolgen noch einmal einen anderen Ansatz als HTML. Klar, man kann so etwas wie Syndication auch mit HTML5 machen, wenn ein Blog ordentlich mit article und Co. ausgezeichnet ist. Die Anwendungsfälle sind da aber noch etwas anders gelagert.

Sicher - aber ein ordentlich ausgezeichneter News- oder Artikelbereich auf einer statischen Seite kann dadurch auch ohne RSS-Feed als solcher identifiziert und ordentlich weiterverarbeitet werden ohne dass man jetzt gleich per Hand zweigleisig fahren müsste und einen RSS-Feed ebenfalls noch aktuell halten muss.

[molily]

Insb. die angesprochenen Punkte bzgl. ARTICLE finde ich iritierend bzw. besorgniserregend.

Und was irritiert dich nun daran?

Das article-Element kennzeichnet einen Abschnitt des Gesamtdokuments als einen in sich geschlossenen Artikel.

Ich hatte bisher angenommen, für eine bspw. blog-artige Struktur könnte man ARTICLE sowohl für Auflistungen von Einträgen

Vor allem in diesem Kontext ergibt es überhaupt Sinn, einen Haufen Inhalte gegenüber dem Restinhalt als gesonderten »article« auszuzeichnen und somit abzugrenzen.

als auch Einzelseiten, die nur diesen Eintrag darstellen, verwenden

Kann man doch. Aber man kann doch nicht erwarten - darum geht es hier ja -, dass die Überschrift eines extra als gesonderten »article« gekennzeichneten Teilabschnittes im Outlining-Algorithmus plötzlich automatisch zur Überschrift des ganzen Dokuments wird.

Das *könnte* man natürlich so definieren, aber das wurde aus mir naheliegenden Gründen nicht getan. Die »False Positives« wären zu häufig gewesen. Woher weiß denn der Algorithmus, dass es nicht noch andere Abschnitte gibt, die sich nicht kurzerhand unter die Überschrift des Artikels fassen lassen? Nur weil in einem Dokument (nur) ein (einziger) »article« auftaucht heißt da nicht, dass das ganze Dokument nichts anderes als die Wiedergabe dieses »articles« zum Ziel hat. Zumal header und aside in Johanssons Beispiel eben noch als weitere, eigenständige Abschnitte gelten. Ein Blogeintrag hat zusätzlich meistens noch ein header, aside und z.B. eine weiteren Abschnitt mit Kommentaren, der logisch gesehen nicht Teil des gesonderten »Articles« ist.

Problematisch ist dann doch eher die Definition, dass footer nicht als Inhaltsabschnitt gesehen wird. Das an sich ist vielleicht diskussionswürdig – ein »footer« soll halt mehr kurze Metainformationen wie Kontakt- und Impressumslink beinhalten, während die verbreiteten Mega-Footer eher mit aside auszuzeichnen wären. Schwierig ist jedoch das (logisch folgerichtige) »Erheben« einer etwaigen Footer-Überschrift zur Dokument-Überschrift. Das ist wahrscheinlich nicht das, was Autoren erwarten würden.

Um ein und das selbe darzustellen, wären also unterschiedliche Auszeichnungen erforderlich, je nach Kontext. Klingt nicht besonders logisch und konsequent für mich.

Konsequent muss es ja auch nicht sein, logisch schon. Wenn ein gewisser Inhalt Teil einer List ist, zeichnest du ihn ggf. mit li aus, in anderen Kontexten zeichnest du den Inhalt anders aus, weil er nicht Teil einer Liste ist. »article« ist eben mit einem solchen »li« vergleichbar.

Mathias

[ChrisB]

Hi,

Konsequent muss es ja auch nicht sein, logisch schon. Wenn ein gewisser Inhalt Teil einer List ist, zeichnest du ihn ggf. mit li aus, in anderen Kontexten zeichnest du den Inhalt anders aus, weil er nicht Teil einer Liste ist. »article« ist eben mit einem solchen »li« vergleichbar.

LI erfordert eine Liste, die es ggf. mit anderen LI zusammen gruppiert.
ARTICLE aber nicht - es kann auch für sich allein stehen.
Wie du nun schreibst, ergibt das aber im Zweifelsfalle keinen besonders großen Sinn.

Vielleicht erwarte ich hier einfach nur eine Vorgabe für die Nutzung oder bewusste Nicht-Nutzung von ARTICLE in bestimmten Kontexten, die die Spezifikation aber nicht macht.

MfG ChrisB

[molily]

LI erfordert eine Liste, die es ggf. mit anderen LI zusammen gruppiert.
ARTICLE aber nicht - es kann auch für sich allein stehen.

Das gilt für alle Sections. Das Dokument ist eine Liste von Sections. Das »ul« für Sections lautet insofern »body«.

Mathias