HTML5 Semantik: TOC und <details>

[Gunther]

Hallo werte Selfgemeinde!

Ich tue mich immer noch etwas schwer mit den neuen HTML5 Elementen und dem Thema "Semantik".
Aktuell suche ich nach der/ einer "Lösung" für die Auszeichnung der TOC (table of content).

Bei meinen Recherchen bin ich u.a. auf die Verwendung des details Elementes gestoßen.

Das hat ja durchaus einige Vorteile, aktuell zumindest in den Browsern (Chrome + Safari 6+), die es bereits unterstützen.

Ein möglicher Aufbau sähe wie folgt aus:

<details id="toc" role="directory" aria-label="Table of contents">  
	<summary>Auf dieser Seite (TOC)</summary>  
		<ol>  
			<li><a href="#">...</a></li>  
			<li><a href="#">...</a></li>  
			<li><a href="#">...</a></li>  
		</ol>  
</details>

Das ist auch valide.

Mit diesem Markup wird kein Eintrag in der Outline erzeugt.
Dazu müsste man das Details-Element also z.B. noch in ein Section-Element stecken.

Oder, und das ist mein derzeitiger Favorit, man umschließt die Liste noch mit einem Nav-Element:

<details id="toc" role="directory" aria-label="Table of contents">  
	<summary>Auf dieser Seite (TOC)</summary>  
	<nav>  
		<h1>Table of contents</h1>  
		<ol>  
			<li><a href="#">...</a></li>  
			<li><a href="#">...</a></li>  
			<li><a href="#">...</a></li>  
		</ol>  
	</nav>  
</details>

Hierbei stellt sich mir dann u.a. die Frage, wohin dann mit WAI-ARIA Role-Attribut - zu dem Detail-Element, oder zu dem Nav-Element?

Meinungen, Vorschläge?

Gruß Gunther

[1UnitedPower]

Meine Herren!

Bei meinen Recherchen bin ich u.a. auf die Verwendung des details Elementes gestoßen.

Das details-Element selber spielt imho. nur eine schwache semantische Rolle. Mit einem details-Element trifft man eine Aussage über die Art der Präsentation und über Benutzerinteraktion, weniger über die Bedeutung des Inhalts. Möchte ich damit einen Film-Spoiler umschließen oder irgendwelche Objekt-Eigenschaften aggregieren? Das Wesen ist sehr abstrakt.

Mit diesem Markup wird kein Eintrag in der Outline erzeugt.

Der Outline-Algorithmus ist sowieso ein "Feature at risk". Was schade ist, denn ich finde er ist eine weitere Bereicherung im Zuge der Semantik-Welle.

Hierbei stellt sich mir dann u.a. die Frage, wohin dann mit WAI-ARIA Role-Attribut - zu dem Detail-Element, oder zu dem Nav-Element?

Oder auf das ol-Element?
Kleiner Ausschweifer: Bist du sicher, dass eine geordnete Liste die beste Wahl ist? Geordnete Listen erfüllen dann ihren Zweck, wenn etwa der Inhalt aufeinander aufbaut, beispielsweise bei einer Lego-Baueinleitung, wo Schritt 1 unbedingt vor Schrhitt 2 erledigt werden sollte.

Meinungen, Vorschläge?

Am details-Element würde ich die ARIA-Rolle aus oben genanntem Grund nicht anbringen. Das nav-Element scheint mir eine gute Wahl zu sein, weil es sozusagen als Wurzel eines Outline-Bereiches agiert.

Als letzter Tipp: Oft ergibt es logisch [!sic] Überschriften mit IDs zu versehen, dadurch werden die Bereiche, die sie erzeugen, einfach ansteuerbar.

Als aller letzter Tipp: Semantik ist nichts starres, Hauptsache deine Argumentation für eine gewisse Variante ist schlüssig.

[Gunther]

Mein Herr!

Besten Dank für deine äußerst hilfreiche Antwort!

Bei meinen Recherchen bin ich u.a. auf die Verwendung des details Elementes gestoßen.

Das details-Element selber spielt imho. nur eine schwache semantische Rolle. Mit einem details-Element trifft man eine Aussage über die Art der Präsentation und über Benutzerinteraktion, weniger über die Bedeutung des Inhalts. Möchte ich damit einen Film-Spoiler umschließen oder irgendwelche Objekt-Eigenschaften aggregieren? Das Wesen ist sehr abstrakt.

ACK.

Mit diesem Markup wird kein Eintrag in der Outline erzeugt.

Der Outline-Algorithmus ist sowieso ein "Feature at risk". Was schade ist, denn ich finde er ist eine weitere Bereicherung im Zuge der Semantik-Welle.

Und derzeit scheint auch noch "Unklarheit/ Unsicherheit" über den exakten Algorithmus zu bestehen. Je nach verwendetem Tool erhält man unterschiedliche Outlines ...!

Hierbei stellt sich mir dann u.a. die Frage, wohin dann mit WAI-ARIA Role-Attribut - zu dem Detail-Element, oder zu dem Nav-Element?

Oder auf das ol-Element?
Kleiner Ausschweifer: Bist du sicher, dass eine geordnete Liste die beste Wahl ist?

Ja, bin ich! ;-)

Geordnete Listen erfüllen dann ihren Zweck, wenn etwa der Inhalt aufeinander aufbaut, beispielsweise bei einer Lego-Baueinleitung, wo Schritt 1 unbedingt vor Schrhitt 2 erledigt werden sollte.

Da der Inhalt einer Seite immer eine feste Abfolge/ Reihenfolge hat, halte ich hier eine OL zumindest für angebrachter, als eine UL.

Meinungen, Vorschläge?

Am details-Element würde ich die ARIA-Rolle aus oben genanntem Grund nicht anbringen. Das nav-Element scheint mir eine gute Wahl zu sein, weil es sozusagen als Wurzel eines Outline-Bereiches agiert.

Ja, scheint mir auch die beste Variante zu sein ...!

Als letzter Tipp: Oft ergibt es logisch [!sic] Überschriften mit IDs zu versehen, dadurch werden die Bereiche, die sie erzeugen, einfach ansteuerbar.

Ja, schon klar ...! ;-)
Aber trotzdem danke für den Hinweis.

Als aller letzter Tipp: Semantik ist nichts starres, Hauptsache deine Argumentation für eine gewisse Variante ist schlüssig.

Das "Problem" dabei ist aber, dass einem selber die eigene Argumentation immer schlüssig erscheint. Insofern ist es äußerst hilfreich, wenn zumindest noch ein anderer Mensch diese ebenfalls für schlüssig hält.

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

Als aller letzter Tipp: Semantik ist nichts starres, Hauptsache deine Argumentation für eine gewisse Variante ist schlüssig.

Das "Problem" dabei ist aber, dass einem selber die eigene Argumentation immer schlüssig erscheint. Insofern ist es äußerst hilfreich, wenn zumindest noch ein anderer Mensch diese ebenfalls für schlüssig hält.

Nicht zwingend, du solltest deine gewählte Semantik nur innerhalb einunddesselben Projektes nicht ändern.

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Als aller letzter Tipp: Semantik ist nichts starres, Hauptsache deine Argumentation für eine gewisse Variante ist schlüssig.

Das "Problem" dabei ist aber, dass einem selber die eigene Argumentation immer schlüssig erscheint. Insofern ist es äußerst hilfreich, wenn zumindest noch ein anderer Mensch diese ebenfalls für schlüssig hält.

Nicht zwingend,

Zwingend vielleicht nicht, aber dennoch extrem vorteilhaft ...! ;-)
Spaß beiseite - in vielen Fällen ist es ja so, dass es eine "vorherrschende Meinung" über die jeweils beste Variante gibt (ich erinnere dich an die Diskussion über die Auszeichnung von Naviagtionen - UL oder nicht UL, das war hier die Frage).

du solltest deine gewählte Semantik nur innerhalb einunddesselben Projektes nicht ändern.

Das sowieso nicht. Hilft aber nichts, wenn die gewählte Semantik semantisch nicht korrekt ist.
Sprich ein Fehler wird nicht dadurch richtig, dass man ihn ständig wiederholt.
Das ist dann zwar konsequent, aber leider immer noch konsequent falsch.

Gruß Gunther

[Matthias Apsel]

Om nah hoo pez nyeetz, Gunther!

Als aller letzter Tipp: Semantik ist nichts starres, Hauptsache deine Argumentation für eine gewisse Variante ist schlüssig.

Das sowieso nicht. Hilft aber nichts, wenn die gewählte Semantik semantisch nicht korrekt ist.
Sprich ein Fehler wird nicht dadurch richtig, dass man ihn ständig wiederholt.
Das ist dann zwar konsequent, aber leider immer noch konsequent falsch.

Das ist ja genau das, was 1up meint. Es gibt in gewissen Fällen kein richtig oder falsch, sondern nur ein kann man so sehen, muss man aber nicht. Ich würde vielleicht auf das details-Element verzichten, sondern nur eine Navigation verwenden, denn zusätzliche Informationen erhält der Benutzer ja nicht, wenn ihm die Zwischenüberschriften des aktuellen Dokuments angezeigt werden.

details lässt mich eher an details denken, also etwa in einer Liste von Personen, weitere (nebensächlichere) Details, die aber auch kein aside rechtfertigen würden. Siehe selfblog zu aside.

Wenn du das so siehst, wie beschrieben, sieht es in diesem Fall keiner von uns falsch.

Matthias

[Gunther]

Om nah hoo pez nyeetz, Matthias!

Als aller letzter Tipp: Semantik ist nichts starres, Hauptsache deine Argumentation für eine gewisse Variante ist schlüssig.

Das sowieso nicht. Hilft aber nichts, wenn die gewählte Semantik semantisch nicht korrekt ist.
Sprich ein Fehler wird nicht dadurch richtig, dass man ihn ständig wiederholt.
Das ist dann zwar konsequent, aber leider immer noch konsequent falsch.

Das ist ja genau das, was 1up meint. Es gibt in gewissen Fällen kein richtig oder falsch, sondern nur ein kann man so sehen, muss man aber nicht.

Das ist ja genau das, was ich mit diesem Thread von euch wissen will. ;-)
Ob man es (überhaupt) so sehen kann, oder wie man es sonst noch sehen könnte.

Ich würde vielleicht auf das details-Element verzichten, sondern nur eine Navigation verwenden, denn zusätzliche Informationen erhält der Benutzer ja nicht, wenn ihm die Zwischenüberschriften des aktuellen Dokuments angezeigt werden.

Das sehe ich anders! ;-)
Eine TOC ist ja kein "zusätzlicher" Content/ Inhalt in dem Sinne, sondern lediglich eine Art "Navigations- und Übersichtshilfe" zu dem (eigentlichen) Content/ Inhalt.

details lässt mich eher an details denken, also etwa in einer Liste von Personen, weitere (nebensächlichere) Details, die aber auch kein aside rechtfertigen würden. Siehe selfblog zu aside.

Ich glaube, dass du hier von der deutschen Bedeutung im engeren Sinne "fehlgeleitet" wirst.
Google schmeisst z.B. neben Details auch noch die Begriffe Einzelheiten, Informationen, Beiwerk und Angaben aus.

Die Spec ist auch ganz hilfreich:"The details element represents a disclosure widget from which the user can obtain additional information or controls. ..."

Mir fällt kaum ein Verwendungszweck ein, der passender dafür wäre, als eine TOC.

Und ich stimme mit 1UP darin überein, dass dem details Element ansich gar keine Semantik innewohnt, sondern diese vielmehr aus dem Inhalt des Elements kommt.

Wenn du das so siehst, wie beschrieben, sieht es in diesem Fall keiner von uns falsch.

Danke, das reicht mir dann schon! :-)

Gruß Gunther