Gehört list-style-type zum Inhalt oder zur Präsentation?

[molily]

Hallo,

ich zweifle an der Vereinbarung, dass der Nummerierungstyp von geordneten Listen (ol) zur Präsentation gehört und deshalb ins Stylesheet und nicht ins Markup gehört.

Nehmen wir folgende Phantasieliste:

<ol type="a">
<li>Äpfel, Bananen, Orangen</li>
<li>Mandarinen, Zitronen, Grapefruits</li>
<li>Mangos, Birnen, Kiwis</li>
<li>Trauben, Melonen, Pfirsiche</li>
</ol>
<p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus. Fertig ist die Sauerei.</p>

Im darauffolgenden Text existiert eine Bezugnahme auf die Listenelemente in Form von deren Nummern. Der Sinn des Textes ist nur verständlich, wenn die Listennummerierungen a, b, c und d lauten. Die Nummerierung darf nicht anders lauten. Durch das type-Attribut ist dies auch unabhängig von der Präsentation gewährleistet. Das Stylesheet kann deaktiviert werden und auch ein Textbrowserbenutzer wird den Sinn des Textes erfassen können (im Allgemeinen, nicht der obige willkürliche Beispieltext).

Dagegen steht, dass das type-Attribut gemäß der W3C-Linie »deprecated« ist und nur Teil der Transitional-Variante ist. Stattdessen soll die CSS-Eigenschaft list-style-type, hier etwa mit dem Wert lower-latin, benutzt werden:

<ol style="list-style-type:lower-latin;">
<li>Äpfel, Bananen, Orangen</li>
<li>Mandarinen, Zitronen, Grapefruits</li>
<li>Mangos, Birnen, Kiwis</li>
<li>Trauben, Melonen, Pfirsiche</li>
</ol>
<p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus. Fertig ist die Sauerei.</p>

Bewirkt augenscheinlich dasselbe, im Textbrowser und beim Ausschalten des Autorenstylesheets ebenfalls sieht man aber:

1. Äpfel, Bananen, Orangen
2. Mandarinen, Zitronen, Grapefruits
3. Mangos, Birnen, Kiwis
4. Trauben, Melonen, Pfirsiche
Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus. Fertig ist die Sauerei.

Auf eine gewisse Weise geht dabei Inhalt verloren, denn Nummerierung ist nicht gleich Nummerierung und der Text verliert insgesamt seinen Sinn.

Rein intuitiv würde ich sagen, dass die Nummerierung stark und untrennbar zum Inhalt und nicht zur Präsentation gehört bzw. selbst Inhalt ist. Wie seht ihr das? CSS sieht eigentlich vor, die Nummerierungen über :before, display:marker, content:counter([bezeichner], [list-style-type]) usw. zu lösen. Immerhin wird dabei der Nummiererung bescheinigt, dass sie auch Inhalt sei und nicht willkürlich zu der Liste gehört wie eine für den Textinhalt selbst irrelevante Formateigenschaft.

Ich war bereits auf ein ähnliches Problem gestoßen, als ich das start-Attribut verwenden wollte, was meiner Meinung nach noch stärker zum Inhalt gehört: </archiv/2002/11/29991/#m162126>. Selbst hypothetisch angenommen, dass die dortgenannte CSS-Entsprechung einigermaßen brauchbar ist, würde der Sinn vollkommen verloren gehen, wenn der Browser das Autorenstylesheet nicht umsetzt.

<hX>Vorgehensweise:</hX>
<ol>
<li>[erster Schritt]</li>
<li>[zweiter Schritt]</li>
<li>[dritter Schritt]</li>
</ol>
<p>[Zusammenfassung/Ergebnis der ersten drei Schritte]</p>
<ol style="counter-reset:counter 3;">
<li>[vierter Schritt]</li>
<li>[fünfter Schritt]</li>
<li>[sechster Schritt]</li>
</ol>

Bei deaktiviertem/nicht verfügbaren CSS bekommt der vierte Schritt wieder die Nummer 1:

1. [erster Schritt]
2. [zweiter Schritt]
3. [dritter Schritt]
[Zusammenfassung/Ergebnis der ersten drei Schritte]
1. [vierter Schritt]
2. [fünfter Schritt]
3. [sechster Schritt]

Das verändert den Sinn grundlegend und eine Bezugnahme über die Nummerierung wie in »der fünfte Schritt« (der diese Zahl nur über die Nummerierung erhält) wäre unmöglich.
Dasselbe Problem ergibt sich mit Überschriftennummerierungen. Wenn im Text auf das Kapitel 1.2.3 hingewiesen wird, die Nummerierung aber über CSS eingefügt wird, ist dieser Verweise, wenn er nicht durch einen Hyperlink begleitet ist, in manchen Fällen unbrauchbar.

Natürlich könnte man sich mehr oder weniger sinnige Alternativen überlegen, die die Nummerierung fest mit dem Text verweben:

<table>
<tr><th>a.</th><td>Äpfel, Bananen, Orangen</td></tr>
<tr><th>b.</th><td>Mandarinen, Zitronen, Grapefruits</td></tr>
<tr><th>c.</th><td>Mangos, Birnen, Kiwis</td></tr>
<tr><th>d.</th><td>Trauben, Melonen, Pfirsiche</td></tr>
</table>

<dl>
<dt>a.</dt><dd>Äpfel, Bananen, Orangen</dd>
<dt>b.</dt><dd>Mandarinen, Zitronen, Grapefruits</dd>
<dt>c.</dt><dd>Mangos, Birnen, Kiwis</dd>
<dt>d.</dt><dd>Trauben, Melonen, Pfirsiche</dd>
</dl>
mit
dd {margin-left:0; padding-left:0;}
dt {float:left; width:2em;}

<ul>
<li>a) Äpfel, Bananen, Orangen</li>
<li>b) Mandarinen, Zitronen, Grapefruits</li>
<li>c) Mangos, Birnen, Kiwis</li>
<li>d) Trauben, Melonen, Pfirsiche</li>
</ul>
mit
ul {list-style-type:none;}

Und natürlich:

<p>a. Äpfel, Bananen, Orangen<br>
b. Mandarinen, Zitronen, Grapefruits<br>
c. Mangos, Birnen, Kiwis<br>
d. Trauben, Melonen, Pfirsiche</p>

Doch die gefallen mir alle nicht sonderlich. Wie sollte man nun solche Listen auszeichnen? Es kann doch nicht sein, dass man für alle Zeiten auf die Standard-Dezimalnummerierung festgelegt ist beziehungsweise auch in fünf Jahren ausschließlich deshalb Transitional schreiben muss. Welchen Sinn hat es, den Code für Inhalt und Präsentation voneinander zu trennen, wenn das Markup ohne das Stylesheet sowieso keinen Sinn hat (sicherlich verändert ein Stylesheet auch immer den Inhalt, aber in der Regel nicht auf einer solchen fundamentalen Weise)? Wenn das Stylesheet sowieso unerlässlich ist, um den Inhalt auf oberflächlichster Ebene begreifen zu können, muss meines Erachtens etwas fälschlicherweise aus dem Markup ausgelagert worden sein.

Mathias

[Ingo Turski]

Hi Mathias,

da hast Du wirklich stimmige Beispiele gebracht und ich bin auch Deiner Meinung. Selbst wenn ich mal den krassen Fall von Sprachen, die kein ABC beinhalten und denen eine Ziffernnummerierung deutlicher wäre, nehme, ändert dies nichts an dem hier notwendigen Bezug zum Text.
Nur: kann man das W3C auch davon überzeugen?

freundliche Grüße
Ingo

[Uschi Renziehausen]

Hallo,

je länger ich darüber nachhirne, wie man Inhalte mit HTML vernünftig auszeichnet, desto mehr komme ich zu der Erkenntnis, daß es einfach keine wirklich befriedigende Lösung gibt. HTML ist eben vom Sprachumfang her ein etwas zu mickrig geratenes SGML-Derivat. Es sollte einfach sein, Informationen zu publizieren, und diese Einfachheit wurde auch erreicht. Aber in dem Moment, wo die Struktur komplizierter wird, ist sie eben mit HTML nicht wirklich abbildbar. Es kann also eh nur Kompromisse und Workarounds geben.
Listen zum Beispiel fehlt so etwas wie caption nach dem Motto: Was bin ich denn eigentlich für eine Liste. Ich empfinde die Entscheidung des W3C, das type-Attribut bei <ol> auf deprecated zu setzen, als contradictio in adiecto. ol steht schließlich für ORDERED list, und Ordnung herrscht nur dann, wenn das Ordnungsprinzip kenntlich gemacht wird. Wenn type deprecated ist, gehört in meinen Augen auch <ol> auf die schwarze Liste oder eine Alternative her.
Im übrigen kann im Rahmen einer Auflistung verschiedener Gruppen von Obstsorten durchaus ein d als Definition gelten, nämlich dann, wenn im vorausgehenden Text bereits davon gehandelt wurde, dass es verschiedene Gruppen gibt.
Beispiel:

<p>Obst lässt sich in die folgenden Gruppen aufteilen:</p>
<ol type="a">
  <li>Zitrusfrüchte</li>
  <li>Beerenobst</li>
  <li>Obst dass ich nicht ausstehen kann</li>
</ol>
<p>Im folgenden die Definitionen</p>
<dl>
 <dt>a (Zitrusfrüchte)</dt>
 <dd>Dieses saure Zeugs wie Zitronen, Orangen, Grapefruit</dd>
 usw.
</dl>

Ich bin mir im übrigen ziemlich sicher, dass bei der Entwicklung von HTML solche Überlegungen, wie Screenreader die Struktur erfassen sollen, zumindest im ersten Ritt nicht einmal in den Gedanken der Macher war.

Gruß, Uschi

[at]

Hallo.

je länger ich darüber nachhirne, wie man Inhalte mit HTML vernünftig auszeichnet, desto mehr komme ich zu der Erkenntnis, daß es einfach keine wirklich befriedigende Lösung gibt.

Seltsam, mir geht es umgekehrt :-)

HTML ist eben vom Sprachumfang her ein etwas zu mickrig geratenes SGML-Derivat. Es sollte einfach sein, Informationen zu publizieren, und diese Einfachheit wurde auch erreicht. Aber in dem Moment, wo die Struktur komplizierter wird, ist sie eben mit HTML nicht wirklich abbildbar. Es kann also eh nur Kompromisse und Workarounds geben.

Und es lassen sich komplexe Strukturen in kleinere, weniger komplexe Teilstrukturen zerlegen, die dann mit den gleichen simplen Werkzeugen zusammengefasst werden können.

Listen zum Beispiel fehlt so etwas wie caption nach dem Motto: Was bin ich denn eigentlich für eine Liste.

Eine Kombination aus "id" und "hx" finde ich zwar nicht eben luxeriös, aber für diesen Zweck durchaus hinreichend.

Ich empfinde die Entscheidung des W3C, das type-Attribut bei <ol> auf deprecated zu setzen, als contradictio in adiecto. ol steht schließlich für ORDERED list, und Ordnung herrscht nur dann, wenn das Ordnungsprinzip kenntlich gemacht wird. Wenn type deprecated ist, gehört in meinen Augen auch <ol> auf die schwarze Liste oder eine Alternative her.

Eine Ordnung ergibt sich aber doch bereits aus der Reihenfolge und gegebenenfalls aus Verschachtelungen. Wozu ist es wichtig, ob vor den Listenpunkten "1., 2., 3." oder "a., b., c." steht. Es ist doch ohnehin unsinnig, sich später auf Zhalen oder Buchstaben zu beziehen, wenn man auch auf deren Inhalte verweisen kann.

Im übrigen kann im Rahmen einer Auflistung verschiedener Gruppen von Obstsorten durchaus ein d als Definition gelten, nämlich dann, wenn im vorausgehenden Text bereits davon gehandelt wurde, dass es verschiedene Gruppen gibt.
Beispiel:

<p>Obst lässt sich in die folgenden Gruppen aufteilen:</p>
<ol type="a">
  <li>Zitrusfrüchte</li>
  <li>Beerenobst</li>
  <li>Obst dass ich nicht ausstehen kann</li>
</ol>
<p>Im folgenden die Definitionen</p>
<dl>
 <dt>a (Zitrusfrüchte)</dt>
 <dd>Dieses saure Zeugs wie Zitronen, Orangen, Grapefruit</dd>
 usw.
</dl>

Das ist ein gutes Beispiel für den Einsatz einer Definitionsliste, aber die (Alpha-)Numerierung erfüllt keinen Zweck, sollte also entfallen bzw. durch <ul> und <dt>Zitrusfrüchte</dt> ersetzt werden. Um Bezug auf bereits angeführte Inhalte nehmen zu können, empfiehlt sich im Übrigen <a>, welches ja speziel hierfür geschaffen wurde. Außerdem enthält obiges Beispiel noch eine versteckte <ul>.

Ich bin mir im übrigen ziemlich sicher, dass bei der Entwicklung von HTML solche Überlegungen, wie Screenreader die Struktur erfassen sollen, zumindest im ersten Ritt nicht einmal in den Gedanken der Macher war.

Das glaube ich gern, aber die grafischen Fähigkeiten der seinerzeitigen Browser waren ja auch beschränkt genug ;-)
MfG, at

[Ingo Turski]

Hi,

Eine Ordnung ergibt sich aber doch bereits aus der Reihenfolge und gegebenenfalls aus Verschachtelungen. Wozu ist es wichtig, ob vor den Listenpunkten "1., 2., 3." oder "a., b., c." steht. Es ist doch ohnehin unsinnig, sich später auf Zhalen oder Buchstaben zu beziehen, wenn man auch auf deren Inhalte verweisen kann.

das finde ich überhaupt nicht unsinnig; gerade Mathias Beispiel

Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus

ließe sich über die Inhalte nicht so prägnant formulieren - hierzu müßten entweder zusätzlich Oberbegriffe formuliert (an den Haaren herbeigezogen) werden oder die gesamten <li>-Inhalte wiederholt werden.

Warum sollte man bei der sprachlichen Textgestaltung eingeengt werden und sich aus Rücksicht auf nicht-CSS-fähige Browser auf Ziffernummerierung beschränken müssen, wenn man eben _nicht_ die Inhalte nochmals aufführen will?
Abgesehen davon wäre
"Wir schneiden 1. klein und würfeln 2., pürieren 3. und pressen 4. aus"
auch ziemlich unverständlich.

freundliche Grüße
Ingo

[at]

Hallo.

das finde ich überhaupt nicht unsinnig; gerade Mathias Beispiel

Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus
ließe sich über die Inhalte nicht so prägnant formulieren - hierzu müßten entweder zusätzlich Oberbegriffe formuliert (an den Haaren herbeigezogen) werden oder die gesamten <li>-Inhalte wiederholt werden.

Wenn du es so darstellen willst, kannst du dies mittels CSS ja tun -- auch wenn der IE Inline-Listen nicht vollständig beherrscht. Die Prägnanz ist jedoch ohnehin nur eine vorgetäuschte, da ich die Begriffe ja heraussuchen muss. Eine verschachtelte Liste wäre gleichermaßen prägnant (1. Ebene) wie vollständig (2. Ebene) und darüber hinaus auch ergonomischer.

Warum sollte man bei der sprachlichen Textgestaltung eingeengt werden und sich aus Rücksicht auf nicht-CSS-fähige Browser auf Ziffernummerierung beschränken müssen, wenn man eben _nicht_ die Inhalte nochmals aufführen will?

Um dem Leser einen Überblick zu verschaffen? Wenn man natürlich autistisch genug ist, eine Anleitung oder Aufzählung so zu verfassen, dass nur man selbst sie verstehen kann, stellt sich diese Frage zugegebenermaßen nicht.

Abgesehen davon wäre
"Wir schneiden 1. klein und würfeln 2., pürieren 3. und pressen 4. aus"
auch ziemlich unverständlich.

Schlimmer noch, denn es wäre _miss_verständlich, da hier eine zeitliche Abfolge nahegelegt wird. Daher habe ich ja im konkreten Fall für eine <ul> votiert.
MfG, at

[molily]

Wozu ist es wichtig, ob vor den Listenpunkten "1., 2., 3." oder "a., b., c." steht. Es ist doch ohnehin unsinnig, sich später auf Zhalen oder Buchstaben zu beziehen, wenn man auch auf deren Inhalte verweisen kann.

Wenn man sich auf die numerische oder alphabetische Nummer bezieht, bezieht man sich auf eine Abkürzung, welche gleichzeitig den Rang in der »geordneten« Liste angibt. Dies wäre bei einer inhaltlichen Bezugnahme in Form einer anderen Bezeichnung, die für den inhalt des referenzierten Listenelements steht, nicht möglich. Darüber hinaus besteht die Schwierigkeit, eine solche Abkürzung in Form einer natürlichsprachigen zusammenfassenden Benennung zu finden. Auf die Inhalte selbst zu verweisen, hieße, auf die gesamten Zusammenhänge zu verweisen, was nichts abkürzen, sondern wiederholen würde; das sollte ja vermieden werden. Daher ist das augenscheinlich willkürliche Obstbeispiel wie gesagt passend, weil keine Aufteilung in Zitrusfrüchte, Beerenobst usw. vorliegt und möglich ist, sondern die Gruppen derart heterogen sind, dass nur ein Zeichen ohne anhaftende Verbindung zum Bedeuteten wie »a«, »b«, »c« bzw. »Gruppe 1«, »Gruppe 2« usw. angebracht ist, womit wir wieder beim Anfang wären.

<dd>Dieses saure Zeugs wie Zitronen, Orangen, Grapefruit</dd>

Außerdem enthält obiges Beispiel noch eine versteckte <ul>.

Argh, du willst wirklich alles auszeichnen, was ausgezeichnet werden kann.

[at]

Hallo.

Darüber hinaus besteht die Schwierigkeit, eine solche Abkürzung in Form einer natürlichsprachigen zusammenfassenden Benennung zu finden.

Dies ist ein prinzipielles Problem von Autoren, dass sie aber auch in anderen Zusammenhängen meist lösen können.

Argh, du willst wirklich alles auszeichnen, was ausgezeichnet werden kann.

Fast ;-)
MfG, at

[molily]

Darüber hinaus besteht die Schwierigkeit, eine solche Abkürzung in Form einer natürlichsprachigen zusammenfassenden Benennung zu finden.

Dies ist ein prinzipielles Problem von Autoren, dass sie aber auch in anderen Zusammenhängen meist lösen können.

Ich würde eher sagen: Das ist ein prinzipielles Problem von Autoren, an dem sie auch in anderen Zusammenhängen vollends verzweifeln, nämlich an der Sprache als generell unzureichendes Mittel des Ausdrucks und der Wiedergabe.

[at]

Hallo.

Ich würde eher sagen: Das ist ein prinzipielles Problem von Autoren, an dem sie auch in anderen Zusammenhängen vollends verzweifeln, nämlich an der Sprache als generell unzureichendes Mittel des Ausdrucks und der Wiedergabe.

Und daher strukturiere ich meine Texte.
MfG, at

[KD-one]

Hallo molily,

Ich hab das bei mir  so gelöst, daß ich eine(zwei) Definitionsliste(n) mit geordneten Listen verschachtelt habe.
Angenehmer Nebeneffekt: Die Listen können aufgrund Ihrer Struktur so (8.1) interpretiert werden.
http://faq.united-web.at/_test/index.php?menu=1
Tatsächlich werden sie von Text- und Sprachbrowsern auch so interpretiert, da Bobby nichts daran auszusetzen hat.
Wenn du dir die Site mit dem NN4.* ansiehst, siehst du die Nummerierung, die allerdings nicht beeinflussbar ist.
Wie wäre es denn, wenn du  grundsätzlich die Nummerierung verwenden würdest, und im Falle eines  JS-fähigen Browsers diese Inhalte (span und Stichwort replaceChild) mit Javascript überschreibst? Textbrowser schalten ja nicht nur CSS, sondern auch JS ab....
Ist nur ein Denkansatz, muss noch lange nicht funktionieren...

Gruß

Kurt

[at]

Hallo.

<ol style="list-style-type:lower-latin;">
<li>Äpfel, Bananen, Orangen</li>
<li>Mandarinen, Zitronen, Grapefruits</li>
<li>Mangos, Birnen, Kiwis</li>
<li>Trauben, Melonen, Pfirsiche</li>
</ol>
<p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus. Fertig ist die Sauerei.</p>

Da du weder eine zeitliche Reihenfolge, noch eine Rangfolge festlegst, ist <ol> meiner Meinung nach nicht das semantisch korrekte Mittel der Wahl. Bei mir sähe die Anleitung unter Beibehaltung der von dir vorgenommen Bezüge zwischen den Tätigkeiten und deren Objekten sowie der willkürlichen Untergruppierungen folgendermaßen aus:

<h1><a id="ergebnis">Irgendwas</a> aus <a href="#zutaten">Obst</a></h1>
<h2><a id="zutaten">Zutaten</a></h2>
<ul id="obst">
 <li><ul>
   <li><a id="aepfel">&Auml;pfel</a></li>
   <li><a id="bananen">Bananen</a></li>
   <li><a id="orangen">Orangen</a></li>
  </ul>
 </li>
 <li>
  <ul>
   <li><a id="mandarinen">Mandarinen</a></li>
   <li><a id="zitronen">Zitronen</a></li>
   <li><a id="grapefruits">Grapefruits</a></li>
  </ul>
 </li>
 <li>
  <ul>
   <li><a id="mangos">Mangos</a></li>
   <li><a id="birnen">Birnen</a></li>
   <li><a id="kiwis">Kiwis</a></li>
  </ul>
 </li>
 <li>
  <ul>
   <li><a id="trauben">Trauben</a></li>
   <li><a id="melonen">Melonen</a></li>
   <li><a id="pfirsiche">Pfirsiche</a></li>
  </ul>
 </li>
</ul>
<div id="zubereitung">
<h2>Zubereitung</h2>
<p>Wir</p>
<ul>
 <li>schneiden<ul>
  <li><a href="#aepfel">&Auml;pfel</a></li>
  <li><a href="#bananen">Bananen</a></li>
  <li><a href="#orangen">Orangen</a></li>
 </ul>klein und</li>
 <li>würfeln<ul>
  <li><a href="#mandarinen">Mandarinen</a></li>
  <li><a href="#zitronen">Zitronen</a></li>
  <li><a href="#grapefruits">Grapefruits</a></li>
 </ul></li>
 <li>pürieren<ul>
  <li><a href="#mangos">Mangos</a></li>
  <li><a href="#birnen">Birnen</a></li>
  <li><a href="#kiwis">Kiwis</a></li>
 </ul>und</li>
 <li>pressen<ul>
  <li><a href="#trauben">Trauben</a></li>
  <li><a href="#melonen">Melonen</a></li>
  <li><a href="#pfirsiche">Pfirsiche</a></li>
 </ul>aus.</li>
</ul>
<p>Fertig ist die <a href="#ergebnis">Sauerei</a>.</p>
</div>

Alles andere ist eine Frage der Darstellung, für die aber bekanntermaßen nicht HTML zuständig ist.

Auf eine gewisse Weise geht dabei Inhalt verloren, denn Nummerierung ist nicht gleich Nummerierung und der Text verliert insgesamt seinen Sinn.

Dies rührt wohl aus dem aus meiner Sicht falschen Ansatz her.

Rein intuitiv würde ich sagen, dass die Nummerierung stark und untrennbar zum Inhalt und nicht zur Präsentation gehört bzw. selbst Inhalt ist. Wie seht ihr das?

Grundsätzlich anders.

CSS sieht eigentlich vor, die Nummerierungen über :before, display:marker, content:counter([bezeichner], [list-style-type]) usw. zu lösen. Immerhin wird dabei der Nummiererung bescheinigt, dass sie auch Inhalt sei und nicht willkürlich zu der Liste gehört wie eine für den Textinhalt selbst irrelevante Formateigenschaft.

Bezüge sind dennoch erstens mittels geeigneter HTML-Elemente, insbesondere wohl <a>, und zweitens zum Inhalt aus semantischer Sicht herzustellen.

Ich war bereits auf ein ähnliches Problem gestoßen, als ich das start-Attribut verwenden wollte, was meiner Meinung nach noch stärker zum Inhalt gehört: </archiv/2002/11/29991/#m162126>. Selbst hypothetisch angenommen, dass die dortgenannte CSS-Entsprechung einigermaßen brauchbar ist, würde der Sinn vollkommen verloren gehen, wenn der Browser das Autorenstylesheet nicht umsetzt.

<hX>Vorgehensweise:</hX>
<ol>
<li>[erster Schritt]</li>
<li>[zweiter Schritt]</li>
<li>[dritter Schritt]</li>
</ol>
<p>[Zusammenfassung/Ergebnis der ersten drei Schritte]</p>
<ol style="counter-reset:counter 3;">
<li>[vierter Schritt]</li>
<li>[fünfter Schritt]</li>
<li>[sechster Schritt]</li>
</ol>

Bei deaktiviertem/nicht verfügbaren CSS bekommt der vierte Schritt wieder die Nummer 1:

1. [erster Schritt]
2. [zweiter Schritt]
3. [dritter Schritt]
   [Zusammenfassung/Ergebnis der ersten drei Schritte]
4. [vierter Schritt]
5. [fünfter Schritt]
6. [sechster Schritt]

Das verändert den Sinn grundlegend und eine Bezugnahme über die Nummerierung wie in »der fünfte Schritt« (der diese Zahl nur über die Nummerierung erhält) wäre unmöglich.

Wenn du zwei getrennte Listen schreibst, ist dies eben etwas anderes als eine einzige.

Dasselbe Problem ergibt sich mit Überschriftennummerierungen. Wenn im Text auf das Kapitel 1.2.3 hingewiesen wird, die Nummerierung aber über CSS eingefügt wird, ist dieser Verweise, wenn er nicht durch einen Hyperlink begleitet ist, in manchen Fällen unbrauchbar.

Aber zum einen sind Verweise gerade hier "in ihrem Element", zum anderen stiftet eine bloße numerische Kapitelangabe ehr Verwirrung als Klarheit bezüglich des Inhalts.

Natürlich könnte man sich mehr oder weniger sinnige Alternativen überlegen, die die Nummerierung fest mit dem Text verweben:

<table>
<tr><th>a.</th><td>Äpfel, Bananen, Orangen</td></tr>
<tr><th>b.</th><td>Mandarinen, Zitronen, Grapefruits</td></tr>
<tr><th>c.</th><td>Mangos, Birnen, Kiwis</td></tr>
<tr><th>d.</th><td>Trauben, Melonen, Pfirsiche</td></tr>
</table>

Hier werden Äpfel und Birnen verglichen ;-)

<dl>
<dt>a.</dt><dd>Äpfel, Bananen, Orangen</dd>
<dt>b.</dt><dd>Mandarinen, Zitronen, Grapefruits</dd>
<dt>c.</dt><dd>Mangos, Birnen, Kiwis</dd>
<dt>d.</dt><dd>Trauben, Melonen, Pfirsiche</dd>
</dl>

Ein "d." steht also für "Melonen"? Das klingt nicht plausibel.

<ul>
<li>a) Äpfel, Bananen, Orangen</li>
<li>b) Mandarinen, Zitronen, Grapefruits</li>
<li>c) Mangos, Birnen, Kiwis</li>
<li>d) Trauben, Melonen, Pfirsiche</li>
</ul>

Abgesehen von wenig sinnstiftenden Beispiel wäre dies eine plausible Möglichkeit. Diese wurde hier aber auch bereits am Beispiel von http://www.heise.de/tp/deutsch/special/wtc/16322/1.html vorgestellt.

Und natürlich:

<p>a. Äpfel, Bananen, Orangen<br>
b. Mandarinen, Zitronen, Grapefruits<br>
c. Mangos, Birnen, Kiwis<br>
d. Trauben, Melonen, Pfirsiche</p>

Hier geht jede Semantik verloren.

Doch die gefallen mir alle nicht sonderlich.

Yep.

Wie sollte man nun solche Listen auszeichnen?

siehe oben ;-)
MfG, at

[Axel Richter]

Hallo at,

obwohl ich Dir fast zustimmen möchte, finde ich Deinen Vorschlag etwas überstrukturiert. Ich hab mal dazugeschrieben, wie man es lesen müsste:

<h1><a id="ergebnis">Irgendwas</a> aus <a href="#zutaten">Obst</a></h1>

Überschrift: Irgendwas aus Obst, Referenz zu Zutaten, folgen Ja/Nein? (Ja==Nein==Zutaten ;-))

<h2><a id="zutaten">Zutaten</a></h2>

Zutaten

<ul id="obst">

Liste, vorlesen Ja/Nein? (Nein->[1])

<li><ul>

Liste, vorlesen Ja/Nein? (Nein->[2])

<li><a id="aepfel">&Auml;pfel</a></li>
   <li><a id="bananen">Bananen</a></li>
   <li><a id="orangen">Orangen</a></li>

Äpfel, Bananen, Orangen

</ul>

[2]

</li>
 <li>
  <ul>

Liste, vorlesen Ja/Nein? (Nein->[3])

<li><a id="mandarinen">Mandarinen</a></li>
   <li><a id="zitronen">Zitronen</a></li>
   <li><a id="grapefruits">Grapefruits</a></li>

Mandarinen, Zitronen, Grapefruits

</ul>

[3]

</li>
 <li>
  <ul>

Liste, vorlesen Ja/Nein? (Nein->[4])

<li><a id="mangos">Mangos</a></li>
   <li><a id="birnen">Birnen</a></li>
   <li><a id="kiwis">Kiwis</a></li>

Mangos, Birnen, Kiwis

</ul>

[4]

</li>
 <li>
  <ul>

Liste, vorlesen Ja/Nein? (Nein->[5])

<li><a id="trauben">Trauben</a></li>
   <li><a id="melonen">Melonen</a></li>
   <li><a id="pfirsiche">Pfirsiche</a></li>

Trauben, Melonen, Pfirsiche

</ul>

[5]

</li>
</ul>

[1]

<div id="zubereitung">
<h2>Zubereitung</h2>

Zubereitung

<p>Wir</p>

Wir

<ul>

Liste, vorlesen Ja/Nein? (Nein->[6])

<li>schneiden<ul>

schneiden
Liste, vorlesen Ja/Nein? (Nein->[7])

<li><a href="#aepfel">&Auml;pfel</a></li>
  <li><a href="#bananen">Bananen</a></li>
  <li><a href="#orangen">Orangen</a></li>

Äpfel(Referenz zu Äpfel, folgen? Ja/Nein), Bananen(Referenz zu Bananen, folgen? Ja/Nein), Orangen(Referenz zu Orangen, folgen? Ja/Nein)

</ul>klein und</li>

[7]klein und

<li>würfeln<ul>

würfeln
Liste, vorlesen Ja/Nein? (Nein->[8])

<li><a href="#mandarinen">Mandarinen</a></li>
  <li><a href="#zitronen">Zitronen</a></li>
  <li><a href="#grapefruits">Grapefruits</a></li>
 </ul></li>

Mandarinen(Referenz zu Mandarinen, folgen? Ja/Nein), Zitronen(Referenz zu Zitronen, folgen? Ja/Nein), Grapefruits(Referenz zu Grapefruits, folgen? Ja/Nein)
[8]
||Anweisung des Hörers: Referenzen nicht mehr ansagen! ;-))

<li>pürieren<ul>

pürieren
Liste, vorlesen Ja/Nein? (Nein->[8])

<li><a href="#mangos">Mangos</a></li>
  <li><a href="#birnen">Birnen</a></li>
  <li><a href="#kiwis">Kiwis</a></li>
 </ul>und</li>

[8]und

<li>pressen<ul>

pressen
Liste, vorlesen Ja/Nein? (Nein->[9])

<li><a href="#trauben">Trauben</a></li>
  <li><a href="#melonen">Melonen</a></li>
  <li><a href="#pfirsiche">Pfirsiche</a></li>

Trauben, Melonen, Pirsiche

</ul>aus.</li>

[9]aus.

</ul>

[6]

<p>Fertig ist die <a href="#ergebnis">Sauerei</a>.</p>

Fertig ist die Sauerei.

</div>

Mein Vorschlag wäre dieser:

<h1><a id="ergebnis">Kleine Sauerei</a> aus unterschiedlichem Obst</h1>
<h2><a id="zutaten">Zutaten</a></h2>
<p>verschiedenes Obst:</p>
<ul id="obstsorten">
 <li><a id="oa">Obst a)</a><ul>
   <li>&Auml;pfel</li>
   <li>Bananen</li>
   <li>Orangen</li>
  </ul>
 </li>
 <li><a id="ob">Obst b)</a><ul>
   <li>Mandarinen</li>
   <li>Zitronen</li>
   <li>Grapefruits</li>
  </ul>
 </li>
 <li><a id="oc">Obst c)</a><ul>
   <li>Mangos</li>
   <li>Birnen</li>
   <li>Kiwis</li>
  </ul>
 </li>
 <li><a id="od">Obst d)</a><ul>
   <li>Trauben</li>
   <li>Melonen</li>
   <li>Pfirsiche</li>
  </ul>
 </li>
</ul>
<h2>Zubereitung</h2>
<p>Wir schneiden <a href="#oa">a)</a> klein und würfeln <a href="#ob">b)</a>, pürieren <a href="#oc">c)</a> und pressen <a href="#od">d)</a> aus. Fertig ist die <a href="#ergebnis">Sauerei</a>.</p>

Trotzdem bin ich, wie Mathias, der Meinung, dass die Attribute type, start und value in Listen-Elementen nicht depecated sein sollten. Man vergleiche z.B. die vielen anderen style-like Attribute, die noch erlaubt sind, weil sie unmittelbar zum entsprechenden Element gehören. Beispiele:
http://www.w3.org/TR/html4/struct/tables.html#borders
http://www.w3.org/TR/html4/struct/tables.html#margins
http://www.w3.org/TR/html4/interact/forms.html#adef-size-INPUT
http://www.w3.org/TR/html4/struct/objects.html#adef-width-IMG

Nach meinem Empfinden gehören type, start und value zu einer OL und type zu einer UL, wie rules und border zu einer Tabelle.

viele Grüße

Axel

[at]

Hallo.

obwohl ich Dir fast zustimmen möchte, finde ich Deinen Vorschlag etwas überstrukturiert.

Ich habe absichtlich alles in seine Bestandteile zerlegt, damit das Prinzip besser erkennbar wird.

<h1><a id="ergebnis">Kleine Sauerei</a> aus unterschiedlichem Obst</h1>
<h2><a id="zutaten">Zutaten</a></h2>
<p>verschiedenes Obst:</p>
<ul id="obstsorten">
 <li><a id="oa">Obst a)</a><ul>
   <li>&Auml;pfel</li>
   <li>Bananen</li>
   <li>Orangen</li>
  </ul>
 </li>
 <li><a id="ob">Obst b)</a><ul>
   <li>Mandarinen</li>
   <li>Zitronen</li>
   <li>Grapefruits</li>
  </ul>
 </li>
 <li><a id="oc">Obst c)</a><ul>
   <li>Mangos</li>
   <li>Birnen</li>
   <li>Kiwis</li>
  </ul>
 </li>
 <li><a id="od">Obst d)</a><ul>
   <li>Trauben</li>
   <li>Melonen</li>
   <li>Pfirsiche</li>
  </ul>
 </li>
</ul>
<h2>Zubereitung</h2>
<p>Wir schneiden <a href="#oa">a)</a> klein und würfeln <a href="#ob">b)</a>, pürieren <a href="#oc">c)</a> und pressen <a href="#od">d)</a> aus. Fertig ist die <a href="#ergebnis">Sauerei</a>.</p>

Ich arbeite lieber mit den Objekten als mit abstrakten Indizes. Dies hat den Vorteil, nicht auf die Referenz angewiesen zu sein und somit den Lesefluss zu fördern sowie gleichzeitig durch die Strukturierung die Prägnanz zu fördern.

Trotzdem bin ich, wie Mathias, der Meinung, dass die Attribute type, start und value in Listen-Elementen nicht depecated sein sollten. Man vergleiche z.B. die vielen anderen style-like Attribute, die noch erlaubt sind, weil sie unmittelbar zum entsprechenden Element gehören. Beispiele:

[...]

Nach meinem Empfinden gehören type, start und value zu einer OL und type zu einer UL, wie rules und border zu einer Tabelle.

Inkonsequenz in anderen Bereichen war für mich nie ein Grund, dies auch für mein Anliegen gelten zu lassen.
MfG, at

[molily]

<ol style="list-style-type:lower-latin;"> <li>Äpfel, Bananen, Orangen</li> <li>Mandarinen, Zitronen, Grapefruits</li> <li>Mangos, Birnen, Kiwis</li> <li>Trauben, Melonen, Pfirsiche</li> </ol> <p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus. Fertig ist die Sauerei.</p>

Da du weder eine zeitliche Reihenfolge, noch eine Rangfolge festlegst,

Ja gut, das lag am Beispiel. Nehmen wir also an, die Reihenfolge ist durchaus festgelegt und der wiederaufgreifende Text bezieht sich auf diese Reihenfolge.

ist <ol> meiner Meinung nach nicht das semantisch korrekte Mittel der Wahl.

Ja, in dem Fall vielleicht nicht, da gebe ich dir Recht.

Bei mir sähe die Anleitung unter Beibehaltung der von dir vorgenommen Bezüge zwischen den Tätigkeiten und deren Objekten sowie der willkürlichen Untergruppierungen folgendermaßen aus:

Die Gruppierungen sind nicht willkürlich. Im Beispiel vielleicht schon, außer im Hinblick auf die Verarbeitung bei der Zubereitung, aber verallgemeinert und abstrahiert gesehen ist der von mir gemeinte Listenelementinhalt in sich zusammengehörig. Natürlich kann dieser weitere komplexe Markupstrukturen erhalten, welche aber nicht aus ihrem Kontext herausgenommen erneut wiedergegeben werden können bzw. es hätte keinen Sinn, dasselbe gilt für deren Elemente/Inhaltseinheiten.

<h1><a id="ergebnis">Irgendwas</a> aus <a href="#zutaten">Obst</a></h1> <h2><a id="zutaten">Zutaten</a></h2> <ul id="obst">  <li><ul>    <li><a id="aepfel">&Auml;pfel</a></li>

Wenn schon, dann <li id="aepfel">.

<li><a id="bananen">Bananen</a></li>    <li><a id="orangen">Orangen</a></li>   </ul>  </li>

[...]

Diese Zutatenliste ist ziemlich überflüssig, da sie bei der Zubereitung vollinhaltlich wiederholt wird. Genau das wollte ich vermeiden und erst dadurch entsteht das Dilemma. Die Nummerierung soll sozusagen als Abkürzung bzw. Zeichen für einen längeren Inhalt bzw. Sachverhalt dienen, sodass man sich im Folgenden nur die Abkürzung nennen anstatt das Gemeinte/Bezeichnete wieder von Neuem zu umschreiben.

<div id="zubereitung"> <h2>Zubereitung</h2> <p>Wir</p> <ul>  <li>schneiden<ul>   <li><a href="#aepfel">&Auml;pfel</a></li>

Es bringt nichts, diesen Link zu folgen, der Verweis ist praktisch sinnlos.

<li><a href="#bananen">Bananen</a></li>   <li><a href="#orangen">Orangen</a></li>  </ul>klein und</li>

[...]

Ich dachte auch daran, den Verweise im Text an den wichtigsten Stellen mit einem Hyperlink zum jeweiligen Listenelement zu versehen, aber eher <a href="#fruechte2">b.</a> usw. wie Axel vorschlägt, aus den besagten Gründen.

Betrachte das Beispiel bitte nicht als das Kernproblem. Du hast die einzelnen »Klassen« der Liste getrennt, genau das ist ja verallgemeinernd nicht möglich bzw. es ist im Hinblick auf das Dilemma vollkommen irrelevant, ob und wie der Listenelementinhalt in sich ausgezeichnet wird. Dass im Beispiel die einzelnen Schritt der Zubereitung auch eine Listenstruktur ist, war mir durchaus bewusst. Die Liste mit der bestimmten Nummerierung wird deshalb eingefügt, damit der Inhalt später nicht wiederholt werden muss und schon gar nicht Einheit für Einheit mit zweckloser Referenz zum ersten Vorkommen. Anstatt den Fruchtnamen könnten die Elemente der geordneten Liste auch lange erklärende Texte enthalten oder irgendwie anders gearteten Inhalt, der aber in sich nicht trennbar ist und nur im Ganzen wiederholt werden könnte, wie gesagt.

Alles andere ist eine Frage der Darstellung, für die aber bekanntermaßen nicht HTML zuständig ist.

Ich bin der Meinung, dass die unformatierte Darstellung keinen durch Markup in atomische Einheiten gespaltenen Text enthalten soll. Mir ging es eher um fließenden Text. Der Text des Beispiels war natürlich zu simpel gewählt, da ist die Aussagestruktur wiederum linear und ohne Überkreuzungen:

a. -> kleinschneiden b. -> würfeln c. -> pürieren d. -> pressen

Eigentlich ging es mir um einen komplexen Text, der sich auf die Listeninhalte bezieht und sich nicht wieder selbst durch eine Liste mit Referenzen/»Zeigern« auf a. bis d. darstellen lässt. Ein anderes Beispiel: Die Listenelemente enthalten näher erläuterte durch verschiedene empirische Verfahren gewonnene, z.T. aufeinander aufbauende Werte, Unterwerte, Teilwerte usw. Im auf die Liste folgenden Fließtext wird nun erklärt, wie aus diesen in der Liste genannten Anfangswerten über verschiedene Umwege und vertrackte Kombinationen allgemeine Erkenntnisse synthetisiert werden. Dieser Text bezieht sich auf die Listenelemente über die Nummerierung. (Denkbar und naheliegender wären natürlich auch andere Benennungen, das gilt für alle obigen Aussagen ebenso, dann wären Tabelle und Definitionsliste angemessener, aber nehmen wir trotzdem des Gedankenexperiments halber die geordnete Liste mit lower-alpha.) Diese Sachverhalte und Zusammenhänge lassen sich keinesfalls in einer Markupstruktur abbilden, zumindest nicht mit HTML. Jeder Versuch, die sprachlichen Strukturen direkt in Markup zu überführen, wird scheitern.

Auf eine gewisse Weise geht dabei Inhalt verloren, denn Nummerierung ist nicht gleich Nummerierung und der Text verliert insgesamt seinen Sinn.

Dies rührt wohl aus dem aus meiner Sicht falschen Ansatz her.

Dieser Ansatz erfüllt aber meine Anforderungen (abgesehen vom beschriebene Problem).

Rein intuitiv würde ich sagen, dass die Nummerierung stark und untrennbar zum Inhalt und nicht zur Präsentation gehört bzw. selbst Inhalt ist. Wie seht ihr das?

Grundsätzlich anders.

Ich sehe nicht, dass du Alternativwege aufzeigst, außer, auf Nummerierung zu verzichten, weil es am Beispiel passte.

CSS sieht eigentlich vor, die Nummerierungen über :before, display:marker, content:counter([bezeichner], [list-style-type]) usw. zu lösen. Immerhin wird dabei der Nummiererung bescheinigt, dass sie auch Inhalt sei und nicht willkürlich zu der Liste gehört wie eine für den Textinhalt selbst irrelevante Formateigenschaft.

Bezüge sind dennoch erstens mittels geeigneter HTML-Elemente, insbesondere wohl <a>, und zweitens zum Inhalt aus semantischer Sicht herzustellen.

Ja. Doch das ist nicht die Frage. Die Frage ist, ob generell eine Bezugnahme über die Kapitelnummer möglich sein kann/darf, wenn die besagten CSS-Möglichkeiten wie vorgesehen verwendet werden.

Bei deaktiviertem/nicht verfügbaren CSS bekommt der vierte Schritt wieder die Nummer 1:

1. [erster Schritt]
2. [zweiter Schritt]
3. [dritter Schritt] [Zusammenfassung/Ergebnis der ersten drei Schritte]
4. [vierter Schritt]
5. [fünfter Schritt]
6. [sechster Schritt]

Das verändert den Sinn grundlegend und eine Bezugnahme über die Nummerierung wie in »der fünfte Schritt« (der diese Zahl nur über die Nummerierung erhält) wäre unmöglich.

Wenn du zwei getrennte Listen schreibst, ist dies eben etwas anderes als eine einzige.

Ah, ja, und? Hältst du also von derartig unterbrochenen Listen generell nichts und findest bereits das Anliegen unsinnig? Wie würdest du obige Inhaltsstruktur besser umsetzen (bitte nicht mit »ich käme erst gar nicht auf die Idee« u.ä. ausweichen, das brächte uns wenig weiter)?

Dasselbe Problem ergibt sich mit Überschriftennummerierungen. Wenn im Text auf das Kapitel 1.2.3 hingewiesen wird, die Nummerierung aber über CSS eingefügt wird, ist dieser Verweise, wenn er nicht durch einen Hyperlink begleitet ist, in manchen Fällen unbrauchbar.

Aber zum einen sind Verweise gerade hier "in ihrem Element", zum anderen stiftet eine bloße numerische Kapitelangabe ehr Verwirrung als Klarheit bezüglich des Inhalts.

Das ist mir klar, aber das Problem taucht bereits dann auf, wenn neben die Kapitelnummer zusätzlich zum Kapiteltitel bzw. der Umschreibungs des Inhalts, auf welchen verwiesen wird, angegeben wird, bspw.: <a href="#nagetiere">Weiterführendes zu Dornschwanzbilchen in Kapitel 6 über Nagetiere</a> Das ist in der Literatur durchaus so üblich und m.M.n. auch sinnvoll, prinzipiell gilt dies auch für Hypertext, daher müsste der Autor eine Sicherheit haben, dass diese Nummerierungen immer kommuniziert werden - da scheidet CSS aus -, sonst müsste sie konsequenterweise weggelassen werden, weil es eine Nullinformation wäre.

<dl> <dt>a.</dt><dd>Äpfel, Bananen, Orangen</dd> <dt>b.</dt><dd>Mandarinen, Zitronen, Grapefruits</dd> <dt>c.</dt><dd>Mangos, Birnen, Kiwis</dd> <dt>d.</dt><dd>Trauben, Melonen, Pfirsiche</dd> </dl>

Ein "d." steht also für "Melonen"? Das klingt nicht plausibel.

Das ist in sich durchaus schlüssig, siehe die Abkürzungsanalogie, das Zeichen »a.« steht sozusagen für »Äpfel, Bananen, Orangen«. Wie gesagt dienen die Bezeichner zunächst einmal als willkürliche Ausdrücke aus einem vorgegebenen Bezeichnungssystem. Das Beispiel war insofern passend, dass ich nicht auf Kategorien hinauswollte, für die sich ein bekannter Kategoriename anböte (bspw. »Steinobst«, »Kernobst« usw.), der für jede Bezugnahme besser geeignet wäre als die fortlaufende willkürliche Nummerierung, dann würde sich das Problem in Luft bzw- in <dt>Steinobst</dt><dd>...</dd> bzw. <th>Steinobst</th><td>...</td> auflösen.

<ul> <li>a) Äpfel, Bananen, Orangen</li> <li>b) Mandarinen, Zitronen, Grapefruits</li> <li>c) Mangos, Birnen, Kiwis</li> <li>d) Trauben, Melonen, Pfirsiche</li> </ul>

Abgesehen von wenig sinnstiftenden Beispiel

Ja, wie gesagt.

wäre dies eine plausible Möglichkeit. Diese wurde hier aber auch bereits am Beispiel von http://www.heise.de/tp/deutsch/special/wtc/16322/1.html vorgestellt.

Den Thread hatte ich entdeckt, kurz nachdem ich das Posting abschickte.

Und natürlich:

<p>a. Äpfel, Bananen, Orangen<br> b. Mandarinen, Zitronen, Grapefruits<br> c. Mangos, Birnen, Kiwis<br> d. Trauben, Melonen, Pfirsiche</p>

Hier geht jede Semantik verloren.

Darüber ließe sich streiten, denke dir einmal XHTML2-line-Elemente statt leere br-Elemente. Du vertrittst offenbar die Auffassung, Markustrukturen auch immer anzuwenden, wenn sie sich anbieten. So wichtig finde ich die Semantik in dem Falle nicht, da der Auszeichnungswahn nicht jede Aufzählung betreffen muss, so könnte man durchaus auch in einem Fließtext ohne besondere Auszeichnung sagen, dass a. Äpfelbananenorangen, b. Mandarinenzitronengrapefruits, c. Mangobirnenkiwis und d. Traubenmelonenpfirsiche gebraucht werden. Ich möchte nicht in einen Formalisierungseifer verfallen, der alle natürlichsprachlichen Texte in ihre Sprachmuster zerhackt und in Textknoten mit bestimmten, durch Markup herausgearbeiteten Beziehungen zerlegt, wie du es mit <p>Wir</p> <ul> <li>schneiden<ul> <li><a href="#aepfel">&Auml;pfel</a></li> <li><a href="#bananen">Bananen</a></li> <li><a href="#orangen">Orangen</a></li> </ul>klein und</li> ... gezeigt hast.

Sicherlich könnte man den Satz »Wir nehmen faule Eier oder matschige Tomaten und bewerfen damit Passanten und vorbeifahrende Autos.« auf Gedeih und Verderb in Markup überführen:

<div> <p>Wir nehmen </p> <ul class="oder"> <li>faule Eier</li> <li>matschige Tomaten</li> </ul> <p> und bewerfen damit </p> <ul class="und"> <li>Passanten</li> <li>vorbeifahrende Autos</li> <li> <p>.</p> </div>

Dann würde ein Stylesheet mit display:inline, :after, content und :nth-last-child() usw. ausgearbeitet, welches daraus wieder »Wir nehmen faule Eier oder matschige Tomaten und bewerfen damit Passanten und vorbeifahrende Autos.« macht. Davon da halte ich ehrlich gesagt absolut nichts.

[at]

Hallo.

Die Gruppierungen sind nicht willkürlich. Im Beispiel vielleicht schon, außer im Hinblick auf die Verarbeitung bei der Zubereitung, aber verallgemeinert und abstrahiert gesehen ist der von mir gemeinte Listenelementinhalt in sich zusammengehörig. Natürlich kann dieser weitere komplexe Markupstrukturen erhalten, welche aber nicht aus ihrem Kontext herausgenommen erneut wiedergegeben werden können bzw. es hätte keinen Sinn, dasselbe gilt für deren Elemente/Inhaltseinheiten.

Es ist insgesamt sehr unpraktisch, über abstrakte Sachverhalte, über die offenbar unterschiedliche Auffassungen bestehen, anhand problembehafteter Beispiel zu diskutieren, weshalb ich nur hoffen kann, dass ich dich im Einzelfall richtig verstehe.

<li><a id="aepfel">&Auml;pfel</a></li>

Wenn schon, dann <li id="aepfel">.

Nein, ich habe vor, einen Link zu setzen, und einen einzelnen Anker finde ich semantisch nicht korrekt. Aber du magst es gern anders handhaben.

<li><a id="bananen">Bananen</a></li>
   <li><a id="orangen">Orangen</a></li>
  </ul>
 </li>
[...]

Diese Zutatenliste ist ziemlich überflüssig, da sie bei der Zubereitung vollinhaltlich wiederholt wird. Genau das wollte ich vermeiden und erst dadurch entsteht das Dilemma. Die Nummerierung soll sozusagen als Abkürzung bzw. Zeichen für einen längeren Inhalt bzw. Sachverhalt dienen, sodass man sich im Folgenden nur die Abkürzung nennen anstatt das Gemeinte/Bezeichnete wieder von Neuem zu umschreiben.

Ja, du willst einen Index setzen. Aber ich habe bisher keinen Anhaltspunkt dafür gefunden, weshalb deine Methode diesem Zweck dienen könnte.

<div id="zubereitung">
<h2>Zubereitung</h2>
<p>Wir</p>
<ul>
 <li>schneiden<ul>
  <li><a href="#aepfel">&Auml;pfel</a></li>

Es bringt nichts, diesen Link zu folgen, der Verweis ist praktisch sinnlos.

In diesem Beispiel vielleicht, aber wenn in der Zutaten-Liste beispielweise Stückzahlen oder Gewichte mit angegeben wären, wäre der Sinn sofort ersichtlich -- das "Beispiel-Dilemma".

<li><a href="#bananen">Bananen</a></li>
  <li><a href="#orangen">Orangen</a></li>
 </ul>klein und</li>
[...]

Ich dachte auch daran, den Verweise im Text an den wichtigsten Stellen mit einem Hyperlink zum jeweiligen Listenelement zu versehen, aber eher <a href="#fruechte2">b.</a> usw. wie Axel vorschlägt, aus den besagten Gründen.

Das hätte ich auch getan, wenn ich damit nicht die Früchte zu einer Einheit hätte zusammenfassen müssen. Wenn die aber etwa die ID "kleinzuschneidendesobst" gewesen wäre, hätte dies natürlich funktioniert.

Betrachte das Beispiel bitte nicht als das Kernproblem. Du hast die einzelnen »Klassen« der Liste getrennt, genau das ist ja verallgemeinernd nicht möglich bzw. es ist im Hinblick auf das Dilemma vollkommen irrelevant, ob und wie der Listenelementinhalt in sich ausgezeichnet wird.

Listenelemente werden mittels <li> ausgezeichnet.

Dass im Beispiel die einzelnen Schritt der Zubereitung auch eine Listenstruktur ist, war mir durchaus bewusst. Die Liste mit der bestimmten Nummerierung wird deshalb eingefügt, damit der Inhalt später nicht wiederholt werden muss und schon gar nicht Einheit für Einheit mit zweckloser Referenz zum ersten Vorkommen.

Eine <ol> ist noch immer kein Index.

Anstatt den Fruchtnamen könnten die Elemente der geordneten Liste auch lange erklärende Texte enthalten oder irgendwie anders gearteten Inhalt, der aber in sich nicht trennbar ist und nur im Ganzen wiederholt werden könnte, wie gesagt.

Auch dann lässt sich der Inhalt leichter in Worten zusammenfassen als mittels einer nichtssagenden Zahl oder eines Buchstabens.

Ich bin der Meinung, dass die unformatierte Darstellung keinen durch Markup in atomische Einheiten gespaltenen Text enthalten soll.

Gut, das akzeptiere ich. Mein Ansatz ist aber ein anderer, indem ich die Listen mittels CSS linearisiere, wenn ich es für sinnvoll erachte.

Ein anderes Beispiel:
Die Listenelemente enthalten näher erläuterte durch verschiedene empirische Verfahren gewonnene, z.T. aufeinander aufbauende Werte, Unterwerte, Teilwerte usw. Im auf die Liste folgenden Fließtext wird nun erklärt, wie aus diesen in der Liste genannten Anfangswerten über verschiedene Umwege und vertrackte Kombinationen allgemeine Erkenntnisse synthetisiert werden. Dieser Text bezieht sich auf die Listenelemente über die Nummerierung. (Denkbar und naheliegender wären natürlich auch andere Benennungen, das gilt für alle obigen Aussagen ebenso, dann wären Tabelle und Definitionsliste angemessener, aber nehmen wir trotzdem des Gedankenexperiments halber die geordnete Liste mit lower-alpha.) Diese Sachverhalte und Zusammenhänge lassen sich keinesfalls in einer Markupstruktur abbilden, zumindest nicht mit HTML. Jeder Versuch, die sprachlichen Strukturen direkt in Markup zu überführen, wird scheitern.

Wieso soll ich nicht aufgelistete Sachverhalte an anderer Stelle beim Namen nennen können? Mir ist bisher kein Beispiel begegnet, bei dem dies nicht möglich gewesen wäre.

Ich sehe nicht, dass du Alternativwege aufzeigst, außer, auf Nummerierung zu verzichten, weil es am Beispiel passte.

Dann frage ich mich, worüber du dich überhaupt ereiferst. Viel konkreter als duch den abgeänderten Quelltext konnte ich nun wirklich nicht machen -- von den erklärenden Ergänzungen abgesehen. Außerdem habe ich im Verlauf dieses Threads sowie auch eines anderen mehrfach dazu geäußert.

Bezüge sind dennoch erstens mittels geeigneter HTML-Elemente, insbesondere wohl <a>, und zweitens zum Inhalt aus semantischer Sicht herzustellen.

Ja. Doch das ist nicht die Frage. Die Frage ist, ob generell eine Bezugnahme über die Kapitelnummer möglich sein kann/darf, wenn die besagten CSS-Möglichkeiten wie vorgesehen verwendet werden.

HTML bietet aber gerade die Möglichkeit, nicht mit Zahlen zu jonglieren, sondern die Referenz über textliche Inhalte herzustellen. Wenn du diese Möglichkeit natürlich nicht nutzen willst, musst du eben mit den daraus erwachsenden Problemen kämpfen.

Wenn du zwei getrennte Listen schreibst, ist dies eben etwas anderes als eine einzige.

» Ah, ja, und? Hältst du also von derartig unterbrochenen Listen generell nichts und findest bereits das Anliegen unsinnig? Wie würdest du obige Inhaltsstruktur besser umsetzen (bitte nicht mit »ich käme erst gar nicht auf die Idee« u.ä. ausweichen, das brächte uns wenig weiter)?

Ein Zwischenfazit würde ich als Definitionsliste in die vorhandene Liste verschachteln, da das Fazit sich ja auf einen konkreten Punkt -- sagen wir den dritten -- bezieht:
<ol>
<li>Erstens</li>
<li>Zweitens</li>
<li>Drittens<dl><dt>Zwischenfazit nach dem dritten Punkt</dt><dd>Bis zu diesem Punkt kann man festestellen, ...</dd></dl></li>
<li>Viertens</li>
</ol>
Ich hoffe, dies war dir nicht zu ausweichend ;-)

Aber zum einen sind Verweise gerade hier "in ihrem Element", zum anderen stiftet eine bloße numerische Kapitelangabe ehr Verwirrung als Klarheit bezüglich des Inhalts.

Das ist mir klar, aber das Problem taucht bereits dann auf, wenn neben die Kapitelnummer zusätzlich zum Kapiteltitel bzw. der Umschreibungs des Inhalts, auf welchen verwiesen wird, angegeben wird, bspw.:
<a href="#nagetiere">Weiterführendes zu Dornschwanzbilchen in Kapitel 6 über Nagetiere</a>
Das ist in der Literatur durchaus so üblich und m.M.n. auch sinnvoll, prinzipiell gilt dies auch für Hypertext, daher müsste der Autor eine Sicherheit haben, dass diese Nummerierungen immer kommuniziert werden - da scheidet CSS aus -, sonst müsste sie konsequenterweise weggelassen werden, weil es eine Nullinformation wäre.

Ich sehe noch immer nicht, wozu ein numerischer Index gut sein soll. Die Herkunft aus Zeiten, in denen (Papier-)Platz teuer war, lasse ich für mich jedenfalls nicht gelten.

Ein "d." steht also für "Melonen"? Das klingt nicht plausibel.

Das ist in sich durchaus schlüssig, siehe die Abkürzungsanalogie, das Zeichen »a.« steht sozusagen für »Äpfel, Bananen, Orangen«. Wie gesagt dienen die Bezeichner zunächst einmal als willkürliche Ausdrücke aus einem vorgegebenen Bezeichnungssystem.

Okay, ich erkenne die Lösung an, halte sie aber für vergleichsweise schlecht.

wäre dies eine plausible Möglichkeit. Diese wurde hier aber auch bereits am Beispiel von http://www.heise.de/tp/deutsch/special/wtc/16322/1.html vorgestellt.

Den Thread hatte ich entdeckt, kurz nachdem ich das Posting abschickte.

Dann wundert mich deine Bemerkung über meine vermeintliche Weigerung, Alternativen zu nennen um so mehr.

Und natürlich:

<p>a. Äpfel, Bananen, Orangen<br>
b. Mandarinen, Zitronen, Grapefruits<br>
c. Mangos, Birnen, Kiwis<br>
d. Trauben, Melonen, Pfirsiche</p>

Hier geht jede Semantik verloren.

Darüber ließe sich streiten, denke dir einmal XHTML2-line-Elemente statt leere br-Elemente.
Du vertrittst offenbar die Auffassung, Markustrukturen auch immer anzuwenden, wenn sie sich anbieten. So wichtig finde ich die Semantik in dem Falle nicht, da der Auszeichnungswahn nicht jede Aufzählung betreffen muss, so könnte man durchaus auch in einem Fließtext ohne besondere Auszeichnung sagen, dass a. Äpfelbananenorangen, b. Mandarinenzitronengrapefruits, c. Mangobirnenkiwis und d. Traubenmelonenpfirsiche gebraucht werden.

Ich erkenne deinen anderen Ansatz an, finde ihn jedoch in keinster Weise erstrebenswert.

Ich möchte nicht in einen Formalisierungseifer verfallen, der alle natürlichsprachlichen Texte in ihre Sprachmuster zerhackt und in Textknoten mit bestimmten, durch Markup herausgearbeiteten Beziehungen zerlegt, wie du es mit <p>Wir</p> <ul> <li>schneiden<ul> <li><a href="#aepfel">&Auml;pfel</a></li> <li><a href="#bananen">Bananen</a></li> <li><a href="#orangen">Orangen</a></li> </ul>klein und</li> ... gezeigt hast.

Wie die Struktur hinterher dargestellt wird, ist ja -- ich wiederhole mich -- keine Sache des HTML.

Sicherlich könnte man den Satz »Wir nehmen faule Eier oder matschige Tomaten und bewerfen damit Passanten und vorbeifahrende Autos.« auf Gedeih und Verderb in Markup überführen:

<div>
<p>Wir nehmen </p>
<ul class="oder">
<li>faule Eier</li>
<li>matschige Tomaten</li>
</ul>
<p> und bewerfen damit </p>
<ul class="und">
<li>Passanten</li>
<li>vorbeifahrende Autos</li>
<li>
<p>.</p>
</div>

Dann würde ein Stylesheet mit display:inline, :after, content und :nth-last-child() usw. ausgearbeitet, welches daraus wieder »Wir nehmen faule Eier oder matschige Tomaten und bewerfen damit Passanten und vorbeifahrende Autos.« macht. Davon da halte ich ehrlich gesagt absolut nichts.

Dein Beispiel ist zwar extrem, aber bei deinem ersten Beispiel bot sich dies meines Erachtens durchaus an.
MfG, at

[molily]

Betrachte das Beispiel bitte nicht als das Kernproblem. Du hast die einzelnen »Klassen« der Liste getrennt, genau das ist ja verallgemeinernd nicht möglich bzw. es ist im Hinblick auf das Dilemma vollkommen irrelevant, ob und wie der Listenelementinhalt in sich ausgezeichnet wird.

Listenelemente werden mittels <li> ausgezeichnet.

Falls wir von Demselben reden, nämlich der Auszeichnung fast jeder Aufzählung als ol/ul-Liste, hier konkret <ul><li>: Ich sehe Markup als Metasprache, mit der ich natürlichsprachige Texte anreichern und vorhandene Strukturen herausarbeiten kann, sofern es mir sinnvoll erscheint. Ich denke aber nicht in Markupstrukturen und schreibe auch nicht in Markupstrukturen. Ich will nicht jeden Gedanken in seiner innwohnenden Struktur in äquivalentes Markup überführen, nur weil diese Struktur existiert und HTML ein mehr oder minder passendes Mittel ist, diese gedanklichen bzw., wenn schon vorhandener Text ausgezeichnet wird, sprachlichen Muster wiederzugeben. Ich werde auch weiterhin Hypertextdokumente schreiben, in denen ich Sätze mit Konjunktionen verknüpfe anstatt die syntaktischen Spracheinheiten in HTML-Listen einzusortieren, nur weil ich die HTML-Liste idealisieren und ihre Bedeutung bis ins Allumfassende verallgemeinern und bis ins Ätherische abstrahieren kann.

Dass im Beispiel die einzelnen Schritt der Zubereitung auch eine Listenstruktur ist, war mir durchaus bewusst. Die Liste mit der bestimmten Nummerierung wird deshalb eingefügt, damit der Inhalt später nicht wiederholt werden muss und schon gar nicht Einheit für Einheit mit zweckloser Referenz zum ersten Vorkommen.

Eine <ol> ist noch immer kein Index.

Ich glaube, dann sind neunundneunzig Prozent aller im Web verwendeten ol-Elemente semantischer Unsinn, weil sie als Index benutzt werden.
Konsequenterweise könnte man auch ol {list-style-type:disc} mit dem Hinweis verwenden, dass die Liste geordnet ist, schließlich spielt die Nummerierung nur die Rolle, auf die Ordnung im Sinne einer bestimmten Abfolge hinzuweisen.

Anstatt den Fruchtnamen könnten die Elemente der geordneten Liste auch lange erklärende Texte enthalten oder irgendwie anders gearteten Inhalt, der aber in sich nicht trennbar ist und nur im Ganzen wiederholt werden könnte, wie gesagt.

Auch dann lässt sich der Inhalt leichter in Worten zusammenfassen als mittels einer nichtssagenden Zahl oder eines Buchstabens.

Wie gesagt, Alles-ist-möglich-Optimismus hilft letztlich wenig weiter, wenn es darum geht, den Inhalt treffend zusammenzufassen.

Ein anderes Beispiel:
Die Listenelemente enthalten näher erläuterte durch verschiedene empirische Verfahren gewonnene, z.T. aufeinander aufbauende Werte, Unterwerte, Teilwerte usw. Im auf die Liste folgenden Fließtext wird nun erklärt, wie aus diesen in der Liste genannten Anfangswerten über verschiedene Umwege und vertrackte Kombinationen allgemeine Erkenntnisse synthetisiert werden. Dieser Text bezieht sich auf die Listenelemente über die Nummerierung. (Denkbar und naheliegender wären natürlich auch andere Benennungen, das gilt für alle obigen Aussagen ebenso, dann wären Tabelle und Definitionsliste angemessener, aber nehmen wir trotzdem des Gedankenexperiments halber die geordnete Liste mit lower-alpha.) Diese Sachverhalte und Zusammenhänge lassen sich keinesfalls in einer Markupstruktur abbilden, zumindest nicht mit HTML. Jeder Versuch, die sprachlichen Strukturen direkt in Markup zu überführen, wird scheitern.

Wieso soll ich nicht aufgelistete Sachverhalte an anderer Stelle beim Namen nennen können?

Das hatten wir schon, etwa in [pref:t=66584&m=380173] und [pref:t=66584&m=380657]: Weil der Inhalt sehr viel länger und komplizierter ist als dieser Name und der Name an und für sich genommen genausowenig den Inhalt bedeutet wie »Spunk« und letztlich »a«.

Mir ist bisher kein Beispiel begegnet, bei dem dies nicht möglich gewesen wäre.

Ich glaube nicht, dass man unter diesen Umständen mit Bedacht handelt, wenn man das Naheliegende ergreift.

HTML bietet aber gerade die Möglichkeit, nicht mit Zahlen zu jonglieren, sondern die Referenz über textliche Inhalte herzustellen. Wenn du diese Möglichkeit natürlich nicht nutzen willst, musst du eben mit den daraus erwachsenden Problemen kämpfen.

Mir stellt sich nicht die Frage, ob ich diese Möglichkeit nutzen will oder nicht.

Wenn du zwei getrennte Listen schreibst, ist dies eben etwas anderes als eine einzige.

Ah, ja, und? Hältst du also von derartig unterbrochenen Listen generell nichts und findest bereits das Anliegen unsinnig? Wie würdest du obige Inhaltsstruktur besser umsetzen (bitte nicht mit »ich käme erst gar nicht auf die Idee« u.ä. ausweichen, das brächte uns wenig weiter)?

Ein Zwischenfazit würde ich als Definitionsliste in die vorhandene Liste verschachteln, da das Fazit sich ja auf einen konkreten Punkt -- sagen wir den dritten -- bezieht:

Das Fazit bezieht sich auf alle drei vorhergehenden Punkte, auf den ersten genauso viel und genauso wenig wie auf den dritten. Es kombiniert sie alle drei und zeigt wiederholend, nur diesmal konkreter, wie sich die drei Einzelteile zusammensetzen. Der dritte Punkt vollendet die drei ersten Punkte nicht, indem er die Synthese bildet und den fehlenden Gesamtrahmen zur Verfügung stellt. Er gleicht prinzipiell in seiner Wichtigkeit dem ersten und zweiten. Der Sinn entsteht durch die Wechselwirkung und das Eingebundensein in den Gesamtkontext, nicht durch einen besonderen Punkt, der Verbindungen zwischen vorher unvernetzten Informationen knüpft. Es steht keine abrundende Bedeutung vom dritten Element im Vordergrund. Punkt eins und zwei gipfeln nicht in Punkt drei. Daher kann ich nicht nachvollziehen, wie das Fazit dem letzten Teil zugehörig sein kann. In einem Schaubild würden drei Pfeile ausgehend von den Knoten der Listenelemente, die jeweils untereinander wieder verbunden sind, auf den Fazitknoten zeigen, nicht nur 1. -> 2 -> 3/Fazit.
Die Punkte bauen zwar hauptsächlich linear aufeinander auf, daher die geordnete Liste. Tatsächlich stehen die Punkte eins bis drei zueinander stärker im Kontext als zwei bis vier, daher setzt das Zwischenfazit genau dort an, um diesen Zusammenhalt auf niederer Ebene noch stärker zu betonen. Dieser Zusammenhalt ist aber nicht stark genug, um eine Listenverschachtelung wie etwa die folgende zu rechtfertigen:

• 1. Schritt
      - 1.1 ...
      - 1.2 ...
      - 1.3 ...
      fazit der ersten zusammenhängenden schritte: ...
• 2. Schritt
      - 2.1 ...
      - 2.2 ...
      - 2.3 ...
      fazit der zweiten zusammenhängenden schritte: ...

Hier würde ich die Fazits in p-Elementen unterbringen, sie sind m.E. weder Teil der Punkte 1.3 bzw. 2.3 noch sind sie ein weiterer Unterschritt 1.4 bzw. 2.4.

Ich sehe noch immer nicht, wozu ein numerischer Index gut sein soll. Die Herkunft aus Zeiten, in denen (Papier-)Platz teuer war, lasse ich für mich jedenfalls nicht gelten.

Der ermöglicht numerische Index ermöglicht dem Leser m.E. eine zusätzliche Orientierung in der Sequenz und fördert die Übersichtlichkeit.

[at]

Hallo.

Falls wir von Demselben reden, nämlich der Auszeichnung fast jeder Aufzählung als ol/ul-Liste, hier konkret <ul><li>: Ich sehe Markup als Metasprache, mit der ich natürlichsprachige Texte anreichern und vorhandene Strukturen herausarbeiten kann, sofern es mir sinnvoll erscheint. Ich denke aber nicht in Markupstrukturen und schreibe auch nicht in Markupstrukturen.

Okay, dann unterscheiden wir uns hier eben. Ich verwende Outliner, um Gedanken strukturiert zusammenzufassen, was die Überführung in verschachtelte Listen näher legt als die Integration in Fließtext.

Ich will nicht jeden Gedanken in seiner innwohnenden Struktur in äquivalentes Markup überführen, nur weil diese Struktur existiert und HTML ein mehr oder minder passendes Mittel ist, diese gedanklichen bzw., wenn schon vorhandener Text ausgezeichnet wird, sprachlichen Muster wiederzugeben.

Und ich möchte nicht einen Absatz immer wieder umformulieren, weil ein Element hinzugefügt oder entfernt wird. Ich käme niemals -- außer hier im direkten Dialog -- auf den Gedanken, nicht auf einer Struktur aufzubauen. Mir hilft HTML eher, meine Gedanken zu ordnen und miteinander in Bezug zu setzen. Daraus darf hinterher aber sicher auch gern ein zusammenhängender Text werden, so dies der besseren Vermittlung der Information dient.

Ich werde auch weiterhin Hypertextdokumente schreiben, in denen ich Sätze mit Konjunktionen verknüpfe anstatt die syntaktischen Spracheinheiten in HTML-Listen einzusortieren, nur weil ich die HTML-Liste idealisieren und ihre Bedeutung bis ins Allumfassende verallgemeinern und bis ins Ätherische abstrahieren kann.

Dein Denk- und Formulierungsprozess geht -- wenn ich dies richtig verstanden habe -- von der wörtlichen Sprache aus, in der ganze Sätze entstehen. Bei mir hingegen entstehen von vornherein Listen, so dass von Abstraktion keine Rede sein kann.

Eine <ol> ist noch immer kein Index.

Ich glaube, dann sind neunundneunzig Prozent aller im Web verwendeten ol-Elemente semantischer Unsinn, weil sie als Index benutzt werden.

Das mag sein, aber darüber habe ich ja auch gar nicht zu entscheiden. Interessiert dich das wirklich? Mich jedenfalls nicht.

Konsequenterweise könnte man auch ol {list-style-type:disc} mit dem Hinweis verwenden, dass die Liste geordnet ist, schließlich spielt die Nummerierung nur die Rolle, auf die Ordnung im Sinne einer bestimmten Abfolge hinzuweisen.

Wenn die Reihenfolge von Belang ist, ist <ol> anzuwenden. Die grafische Darstellung kann dann meinetwegen auch durch unterschiefliche Farbintensität ausgedrückt werden, wenn es denn der Verdeutlichung dient.

Wie gesagt, Alles-ist-möglich-Optimismus hilft letztlich wenig weiter, wenn es darum geht, den Inhalt treffend zusammenzufassen.

Okay, ich harre des von dir angekündigten problembehafteten Beispiels. Vielleicht hast du ja recht, und ich kann dir leider nicht helfen.

Das hatten wir schon, etwa in [pref:t=66584&m=380173] und [pref:t=66584&m=380657]: Weil der Inhalt sehr viel länger und komplizierter ist als dieser Name und der Name an und für sich genommen genausowenig den Inhalt bedeutet wie »Spunk« und letztlich »a«.

In der Mathematik werden doch auch komplexe Sachverhalte mittels einfacher Zeichen dargestellt, die aber durch keine geordnete Liste hergeleitet werden können. -- Aber du hast Recht: Das Thema hatten wir tatsächlich schon.

Mir ist bisher kein Beispiel begegnet, bei dem dies nicht möglich gewesen wäre.

Ich glaube nicht, dass man unter diesen Umständen mit Bedacht handelt, wenn man das Naheliegende ergreift.

Ein schöner Satz, dessen Inhalt sicher mir jedoch nicht zu erschließen vermag.

Das Fazit bezieht sich auf alle drei vorhergehenden Punkte, auf den ersten genauso viel und genauso wenig wie auf den dritten.

Und? Dies ist bei einer definierten Reihenfolge prinzipimmanent. Wäre dem nicht so, könnte man die ersten beiden Punkte ja auch ersatzlos streichen.

Es kombiniert sie alle drei und zeigt wiederholend, nur diesmal konkreter, wie sich die drei Einzelteile zusammensetzen.

Nein, "zusammensetzen" würden sie sich bei einer <ul>. In einer <ol> bauen sie jedoch aufeinander auf.

Der dritte Punkt vollendet die drei ersten Punkte nicht, indem er die Synthese bildet und den fehlenden Gesamtrahmen zur Verfügung stellt.

Stimt, vielmehr stellt der dritte Punkt den Schritt dar, der zwischen dem zweiten und dem vierten unbedingt zu erfolgen hat.

Er gleicht prinzipiell in seiner Wichtigkeit dem ersten und zweiten.

Eine Gewichtung kann nur im konkreten Beispiel vorgenommen werden. Beispielsweise kann ich in einer Bauanleitung anfangs jeden Schritt sehr fein auflösen und auch eigentlich überflüssige oder selbstverständliche Anweisungen geben, um zum Schluss zu sagen: "n. Setzen sie jetzt alle derart vorbereiteten Teile zusammen"

Der Sinn entsteht durch die Wechselwirkung und das Eingebundensein in den Gesamtkontext, nicht durch einen besonderen Punkt, der Verbindungen zwischen vorher unvernetzten Informationen knüpft.

Eine Vernetzung ist schon durch <ol> gegeben, da die Reihenfolge ja offenbar von Belang ist.

Es steht keine abrundende Bedeutung vom dritten Element im Vordergrund. Punkt eins und zwei gipfeln nicht in Punkt drei. Daher kann ich nicht nachvollziehen, wie das Fazit dem letzten Teil zugehörig sein kann.

Aus dem zeitlichen Ablauf, den die Reihenfolge vorgibt.
Eine "abgerundete Bedeutung" ist im Übrigen auch gar nicht nötig: "1. Lackieren Sie das Dreieck mit der langsam trocknenden Farbe Rot. 2. Lackieren Sie das Quadrat mit der mittelschenll trocknenden Farbe Blau. 3. Lackieren Sie den Kreis mit der schnell trocknenden Farbe Gelb. Fazit: Jetzt sind alle Teile lackiert und auf Grund der Trocknungsdauer etwa gleich schnell bereit für die nächsten Schritte." Mit Abschluss des dritten Punktes lässt sich hier ein Fazit ziehen, obwohl es ein Punkt ist wie die vorangegangenen auch.

In einem Schaubild würden drei Pfeile ausgehend von den Knoten der Listenelemente, die jeweils untereinander wieder verbunden sind, auf den Fazitknoten zeigen, nicht nur 1. -> 2 -> 3/Fazit.

Das ist natürlich schon deswegen falsch, weil dann jeweils ein Pfeil von "1." und "2." auf "Fazit" zeigte, obwohl sich "1." vielleicht gar nicht in "Fazit" niederschlagen kann, da es bereits durch "2." zunichte gemacht und nur von "3." in anderer Form wiederhergestellt wurde. Somit hätte auch "2." nichts zu "Fazit" beigetragen, da "Fazit" ja ohnehin durch "3." eingetreten wäre.

Die Punkte bauen zwar hauptsächlich linear aufeinander auf, daher die geordnete Liste. Tatsächlich stehen die Punkte eins bis drei zueinander stärker im Kontext als zwei bis vier, daher setzt das Zwischenfazit genau dort an, um diesen Zusammenhalt auf niederer Ebene noch stärker zu betonen.

"1. Am ersten Tag schien die Sonne. 2. Am zweiten Tag regnete es. 3. Am dritten Tag schneite es. Zwischenfazit: Das Wetter wurde immer unangenehmer. 4. Am vierten Tag schneite es. 5. Auch am fünften Tag schneite es. n. Am n. Tag schneite es. Fazit: "Es hat fast nur geschneit." zeigt dir, dass man fast immer ein Zwischenfazit ziehen kann, und zwar allein aus der Tatsache des Linearität der Ereignisse, denn die Gewichtung eines jeden Punktes ist ja die gleiche.

Dieser Zusammenhalt ist aber nicht stark genug, um eine Listenverschachtelung wie etwa die folgende zu rechtfertigen:

• 1. Schritt
      - 1.1 ...
      - 1.2 ...
      - 1.3 ...
      fazit der ersten zusammenhängenden schritte: ...
• 2. Schritt
      - 2.1 ...
      - 2.2 ...
      - 2.3 ...
      fazit der zweiten zusammenhängenden schritte: ...

Da kommen wir der Sache aber schon einen Schritt näher: Wenn du gewichten willst, sind Verschachtelungen das Mittel der Wahl. Das ist ja bei <ul> nicht anders.

Hier würde ich die Fazits in p-Elementen unterbringen, sie sind m.E. weder Teil der Punkte 1.3 bzw. 2.3 noch sind sie ein weiterer Unterschritt 1.4 bzw. 2.4.

Das würde ich wiederum anders handhaben. Das Wie und Weshalb habe ich ja schon erläutert.

Der ermöglicht numerische Index ermöglicht dem Leser m.E. eine zusätzliche Orientierung in der Sequenz und fördert die Übersichtlichkeit.

Weshalb dies numerisch geschehen soll, erschließt sich mir aber noch immer nicht. Wenn ich die zugehörigen Textstellen wenigstens gleichäßig über den Text verteilt hätte, könnte ich anhand des Index ablesen, wieviel ich noch lesen muss. Aber dies ist ja nicht zu gewährleisten und wohl auch nur in den seltensten Fällen sinnvoll.
MfG, at

[molily]

Eine <ol> ist noch immer kein Index.

Ich glaube, dann sind neunundneunzig Prozent aller im Web verwendeten ol-Elemente semantischer Unsinn, weil sie als Index benutzt werden.

Das mag sein, aber darüber habe ich ja auch gar nicht zu entscheiden.

Wir entscheiden aber die ganze Zeit darüber, indem wir darüber diskutieren, was eine Liste im Web grundlegend sein kann, welche Inhalte damit ausgezeichnet werden können, wann und unter welchen Bedingungen sie verwendet werden kann, wie semantische Stimmigkeit und Kommunikationssicherheit erreicht werden kann und so weiter. Indem oben genannter Sachverhalt festgestellt wird, wird zwangsläufig gesagt, dass Listen nicht in dieser Form verwendet werden können, was nunmal wie gesagt der gegenwärtigen verbreiteten Auffassung radikal widerspricht, das ist ein Widerspruch, den es früher oder später zu abzuklären gilt, es muss eine Auseinandersetzung darüber geben.

Interessiert dich das wirklich? Mich jedenfalls nicht.

Natürlich interessiert es mich, solche Erkenntnisse verändern das Schreiben von Hypertext grundlegend. Mich interessiert ja nicht nur, wie ich für mich alleine subjektiv überragenden Hypertext schreiben kann, mit dem ich der Welt voraus bin.

Mir ist bisher kein Beispiel begegnet, bei dem dies nicht möglich gewesen wäre.

Ich glaube nicht, dass man unter diesen Umständen mit Bedacht handelt, wenn man das Naheliegende ergreift.

Ein schöner Satz, dessen Inhalt sicher mir jedoch nicht zu erschließen vermag.

Es ging mir darum, dass ich nicht glauben kann, dass sich solche Probleme dadurch lösen lassen, dass man sie als trivial auffasst und auf der Suche nach einer angemessenen Benennung den erstbesten Namen verwendet, der einem einfällt oder auf einen oberflächlichen Blick stimmig scheint.

Das Fazit bezieht sich auf alle drei vorhergehenden Punkte, auf den ersten genauso viel und genauso wenig wie auf den dritten.

Und? Dies ist bei einer definierten Reihenfolge prinzipimmanent.

Nein, es ist eine Pyramide, in der der Stein des Fazits auf dem Fundament der drei Steine der Listenpunkte ruht. Dieser Stein ist nicht mit dem dritten identisch und in seiner Art nicht mit den Steinen der Punkte vergleichbar, nicht der dritte Schritt leitet die Metaebene ein.

Wäre dem nicht so, könnte man die ersten beiden Punkte ja auch ersatzlos streichen.

Diese Argumentation zeigt mir nicht, wieso die Beschreibung des Zusammenspiels der Schritte Teil eines dieser Schrittes ist, wo sie doch eigentlich allen Schritten zugehört und die Schritte umgekehrt ihr angehören.

Es kombiniert sie alle drei und zeigt wiederholend, nur diesmal konkreter, wie sich die drei Einzelteile zusammensetzen.

Nein, "zusammensetzen" würden sie sich bei einer <ul>. In einer <ol> bauen sie jedoch aufeinander auf.

Wie der Verweis zum Ursprungsproblem dieser Listenteilung im ersten Posting dieses Threads zeigt (</archiv/2002/11/29991/#m162126>), ging es um die Beschreibung von CSS-Regeln. Der erste Schritt nennt ein Teilziel benennt alle HTML-Elemente, die von der Formatierung betroffen sind. Schritt zwei und drei beschreiben miteinander interagierende CSS-Deklarationen, die für die angesprochenen Elemente gelten sollen. Das Zwischenfazit setzt den Selektor aus Schritt eins und die Deklarationen aus zwei und drei zu einer CSS-Regel in Form eines konkreten Codes anstatt einer natürlichsprachigen Beschreibung zusammen.
Die Schritte bauen aufeinander auf bzw. bedingen einander *und* setzen sich zu einer größeren Einheit zusammen. Und wie gesagt, mir geht es nicht um logisch korrekte Auszeichnung, dann könnte ich natürlich schön jeden noch so kleinen Zusammenhang einzeln auszeichnen und mir würden alleine beim obigen simplen Zusammenhang ein halbes dutzend Listenebenen einfallen, wo dann vielleicht sogar zwischen zusammensetzenden und aufeinander aufbauenden Teilen unterschieden werden könnte, auch wenn ich das nicht glaube. Ich will die gedanklichen Schritte herausstellen, da würde schon eine zweite Ebene die Verständlichkeit negativ beeinflussen.

[...]

Eine Gewichtung kann nur im konkreten Beispiel vorgenommen werden.

Es ging ja im Prinzip die ganze Zeit um konkrete Beispiel, siehe oben.

Beispielsweise kann ich in einer Bauanleitung anfangs jeden Schritt sehr fein auflösen und auch eigentlich überflüssige oder selbstverständliche Anweisungen geben, um zum Schluss zu sagen: "n. Setzen sie jetzt alle derart vorbereiteten Teile zusammen"

Der für mich entscheidende Punkt ist, dass es eine Ebene gibt, auf der ich nur die Einheit der Teile als solche beschreibe und eine darunterliegende Ebene, auf der sich die Teile überhaupt erst als atomare Einzelteile der CSS-Syntax feststellen lassen. Die zweite Ebene ist für mein Anliegen relativ uninteressant, so der Code nur der Ausdruck des Sachverhalts, nicht der Sachverhalt selbst ist.
In den Schritten vor dem Fazit werden die Teile also nicht in ihrer Funktion als zusammenpassende Teile vorbereitet. Ich könnte gar nicht schreiben, dass sich ja alles aufgrund des Beschriebenen schon von selbst zusammenfügt, das Zusammensetzen wäre selbst in der Bauanleitung keine Selbstverständlichkeit.

Der Sinn entsteht durch die Wechselwirkung und das Eingebundensein in den Gesamtkontext, nicht durch einen besonderen Punkt, der Verbindungen zwischen vorher unvernetzten Informationen knüpft.

Eine Vernetzung ist schon durch <ol> gegeben, da die Reihenfolge ja offenbar von Belang ist.

Wenn ich nun diese Vernetzung zur Verdeutlichung im Fazit beschreiben will, wie kann das Fazit selbst Teil der Vernetzung sein?

Es steht keine abrundende Bedeutung vom dritten Element im Vordergrund. Punkt eins und zwei gipfeln nicht in Punkt drei. Daher kann ich nicht nachvollziehen, wie das Fazit dem letzten Teil zugehörig sein kann.

Aus dem zeitlichen Ablauf, den die Reihenfolge vorgibt.

Das bezweifle ich ja nicht. Allerdings hat man es verallgemeinernt mit strukturierten Herangehensweisen zu tun.

Eine "abgerundete Bedeutung" ist im Übrigen auch gar nicht nötig: "1. Lackieren Sie das Dreieck mit der langsam trocknenden Farbe Rot. 2. Lackieren Sie das Quadrat mit der mittelschenll trocknenden Farbe Blau. 3. Lackieren Sie den Kreis mit der schnell trocknenden Farbe Gelb. Fazit: Jetzt sind alle Teile lackiert und auf Grund der Trocknungsdauer etwa gleich schnell bereit für die nächsten Schritte." Mit Abschluss des dritten Punktes lässt sich hier ein Fazit ziehen,

Wenn sich das Fazit nach Abschluss des dritten Punktes ziehen lässt, kann es nicht selbst dem dritten Punkt angehören, da dieser abgeschlossen sein muss. »Jetzt« bedeutet nicht anderes als das: Nachdem alle drei Punkte in sich abgeschlossen sind und nun insgesamt einen Sinn ergeben. Der dritte Punkt stiftet an und für sich nicht weniger Sinn als die anderen Puzzleteile.

obwohl es ein Punkt ist wie die vorangegangenen auch.

In einem Schaubild würden drei Pfeile ausgehend von den Knoten der Listenelemente, die jeweils untereinander wieder verbunden sind, auf den Fazitknoten zeigen, nicht nur 1. -> 2 -> 3/Fazit.

Das ist natürlich schon deswegen falsch, weil dann jeweils ein Pfeil von "1." und "2." auf "Fazit" zeigte, obwohl sich "1." vielleicht gar nicht in "Fazit" niederschlagen kann, da es bereits durch "2." zunichte gemacht und nur von "3." in anderer Form wiederhergestellt wurde.

»1.« schlägt sich so oder so im Fazit nieder, selbst wenn es zunichte gemacht wurde, denn das Fazit bezieht sich ja auf dieses Ausschalten und hat nicht nur das letztlich übrig bleibende im Fokus, sonst wäre es meinem Verständnis nach kein Fazit, sondern der vollendende Schritt. Das von mir gemeinte Fazit drückt nicht nur die Konsequenzen des Prozesses an einer bestimmten Stelle desselben aus. Das wäre dann die Beschreibung der Abhängigkeiten und Herleitungsbeziehungen von »3.«, aber kein Fazit aus den ersten drei Schritten, deren Koexistenz ich als Prämisse annahm. Logisch Schließen will ich, wenn überhaupt, nur in dem Fazit selbst, die Teilschritte bezweifeln und negieren sich nicht gegenseitig. (Nun könntest du sagen, dass sie dann ul-Schritte sein müssen, weil sie nicht so stark aufeinander aufbauen.)

Somit hätte auch "2." nichts zu "Fazit" beigetragen, da "Fazit" ja ohnehin durch "3." eingetreten wäre.

Wenn das Fazit durch einen Schritt eintritt, dann ist jeder Schritt für sich gesehen ein Fazit aller vorhergegangenen Punkte und das Fazit nach dem dritten Punkt wäre identisch mit dem dritten Punkt. Das trifft auf manche Abfolgen zu, welche sich entsprechend in einer ol-Liste darstellen lassen, um solche Abfolgen ging es mir gar nicht.

Tatsächlich stehen die Punkte eins bis drei zueinander stärker im Kontext als zwei bis vier, daher setzt das Zwischenfazit genau dort an, um diesen Zusammenhalt auf niederer Ebene noch stärker zu betonen.

man [kann] fast immer ein Zwischenfazit ziehen kann, und zwar allein aus der Tatsache des Linearität der Ereignisse

Es ging mir um die Absicht meines Fazits; dass in anderen Zusammenhängen anderes möglich ist, wollte ich nicht bezweifeln.

denn die Gewichtung eines jeden Punktes ist ja die gleiche.

Nach bestimmten Schrittabfolgen existieren nennenswertere Ergebnisse als nach anderen Abfolgen, daher könnte ich zwar überall Zwischenfazits einfügen, sie würden aber in den bestimmten Fällen sinnhafter sein.

Der ermöglicht numerische Index ermöglicht dem Leser m.E. eine zusätzliche Orientierung in der Sequenz und fördert die Übersichtlichkeit.

Weshalb dies numerisch geschehen soll, erschließt sich mir aber noch immer nicht. Wenn ich die zugehörigen Textstellen wenigstens gleichäßig über den Text verteilt hätte, könnte ich anhand des Index ablesen, wieviel ich noch lesen muss. Aber dies ist ja nicht zu gewährleisten und wohl auch nur in den seltensten Fällen sinnvoll.

Das meinte ich unter anderem, nur ist der gegenwärtige Standpunkt nicht nur durch diese Art von Hilfestellung definiert. Es geht ja nicht um quantitative Textmenge, sondern darum, dass sich der Leser an der Inhaltsstruktur besser entlanghangeln kann. Kapitelnummerierungen sind ein Mittel, um die Überschriftenhierarchie deutlicher herauszuarbeiten, da die Zahlen sehr schnell ins Auge springen, etwa bei der Suche eines Kapitels.

[at]

Hallo.

Eine <ol> ist noch immer kein Index.

Ich glaube, dann sind neunundneunzig Prozent aller im Web verwendeten ol-Elemente semantischer Unsinn, weil sie als Index benutzt werden.

Das mag sein, aber darüber habe ich ja auch gar nicht zu entscheiden.

Wir entscheiden aber die ganze Zeit darüber, indem wir darüber diskutieren, was eine Liste im Web grundlegend sein kann, welche Inhalte damit ausgezeichnet werden können, wann und unter welchen Bedingungen sie verwendet werden kann, wie semantische Stimmigkeit und Kommunikationssicherheit erreicht werden kann und so weiter. Indem oben genannter Sachverhalt festgestellt wird, wird zwangsläufig gesagt, dass Listen nicht in dieser Form verwendet werden können, was nunmal wie gesagt der gegenwärtigen verbreiteten Auffassung radikal widerspricht, das ist ein Widerspruch, den es früher oder später zu abzuklären gilt, es muss eine Auseinandersetzung darüber geben.

Wäre dem so, dürfte ich also Tabellen ausschließlich für mein Layout verwenden, da dies die bei weitem häufigste Anwendung ist. Und sie semantisch korrekt zu verwenden, müsste ich mir so lange verkneifen, bis ich genügend andere davon überzeugt hätte, Tabellen ebenfalls vernünftig einzusetzen. Dann müssten wir eigentlich nur noch alle von einem Tag auf den nächsten all unsere Seiten umstellen, und schon wäre das Problem gelöst.

Natürlich interessiert es mich, solche Erkenntnisse verändern das Schreiben von Hypertext grundlegend. Mich interessiert ja nicht nur, wie ich für mich alleine subjektiv überragenden Hypertext schreiben kann, mit dem ich der Welt voraus bin.

Der Anspruch sei dir gegönnt. Ich teile ihn jedoch nicht.

Es ging mir darum, dass ich nicht glauben kann, dass sich solche Probleme dadurch lösen lassen, dass man sie als trivial auffasst und auf der Suche nach einer angemessenen Benennung den erstbesten Namen verwendet, der einem einfällt oder auf einen oberflächlichen Blick stimmig scheint.

Danke für die Erläuterung. Für mich sind "1." oder "a)" genau diese Punkte. Daher suche ich immer nach sinnstiftenden Formulierungen. Dies mag mir weniger schwer fallen als anderen, aber dafür kann ich ja nichts.

Nein, es ist eine Pyramide, in der der Stein des Fazits auf dem Fundament der drei Steine der Listenpunkte ruht. Dieser Stein ist nicht mit dem dritten identisch und in seiner Art nicht mit den Steinen der Punkte vergleichbar, nicht der dritte Schritt leitet die Metaebene ein.

Natürlich leitet der dritte Stein die Metaebene ein, oder eben er zweite oder vierte, jedenfalls der, auf dessen Stein er pyramidentypisch liegt. Wenn er auf mehreren Steinen läge, würde die darunter liegende Reihenfolge nicht stimmen. Sie entspräche dann einer <ul>, keiner <ol>.

Wäre dem nicht so, könnte man die ersten beiden Punkte ja auch ersatzlos streichen.

Diese Argumentation zeigt mir nicht, wieso die Beschreibung des Zusammenspiels der Schritte Teil eines dieser Schrittes ist, wo sie doch eigentlich allen Schritten zugehört und die Schritte umgekehrt ihr angehören.

Bei einer <ul>, also einer Ansammlung von Punkten gäbe ich dir darin Recht, aber bei einer <ol> ist der Zusammenhang der Schritte elmentimmmanent. Ihn anderweitig herauszustellen, ist also überflüssig, weswegen ein Fazit sich auch auf einen einzelnen Punkt beziehen kann.

Wie der Verweis zum Ursprungsproblem dieser Listenteilung im ersten Posting dieses Threads zeigt (</archiv/2002/11/29991/#m162126>), ging es um die Beschreibung von CSS-Regeln. Der erste Schritt nennt ein Teilziel benennt alle HTML-Elemente, die von der Formatierung betroffen sind. Schritt zwei und drei beschreiben miteinander interagierende CSS-Deklarationen, die für die angesprochenen Elemente gelten sollen. Das Zwischenfazit setzt den Selektor aus Schritt eins und die Deklarationen aus zwei und drei zu einer CSS-Regel in Form eines konkreten Codes anstatt einer natürlichsprachigen Beschreibung zusammen.

Wenn ich natürlich "Schritt 3" als Fazit bezeichne, habe ich ein Problem, da gebe ich dir Recht.

Die Schritte bauen aufeinander auf bzw. bedingen einander *und* setzen sich zu einer größeren Einheit zusammen. Und wie gesagt, mir geht es nicht um logisch korrekte Auszeichnung, dann könnte ich natürlich schön jeden noch so kleinen Zusammenhang einzeln auszeichnen und mir würden alleine beim obigen simplen Zusammenhang ein halbes dutzend Listenebenen einfallen, wo dann vielleicht sogar zwischen zusammensetzenden und aufeinander aufbauenden Teilen unterschieden werden könnte, auch wenn ich das nicht glaube. Ich will die gedanklichen Schritte herausstellen, da würde schon eine zweite Ebene die Verständlichkeit negativ beeinflussen.

Wenn es dir "nicht um logisch korrekte Auszeichnung" geht, erübrigt sich natürlich die Diskussion, da es mir genau darum ging.

Der für mich entscheidende Punkt ist, dass es eine Ebene gibt, auf der ich nur die Einheit der Teile als solche beschreibe und eine darunterliegende Ebene, auf der sich die Teile überhaupt erst als atomare Einzelteile der CSS-Syntax feststellen lassen. Die zweite Ebene ist für mein Anliegen relativ uninteressant, so der Code nur der Ausdruck des Sachverhalts, nicht der Sachverhalt selbst ist.

Dann sieht die Liste aber auch anders aus: Du hast lauter Zwei-Schritt-<ol> innerhalb einer <ul> und kannst daher natürlich kein Fazit über den Verlauf des ganzen ziehen, sondern entweder mehrere innerhalb des jeweils letzten Punktes der <ol> oder belibig viele innerhalb der <ul>, gegebenenfalls selbst ebenfalls geordnet.

In den Schritten vor dem Fazit werden die Teile also nicht in ihrer Funktion als zusammenpassende Teile vorbereitet. Ich könnte gar nicht schreiben, dass sich ja alles aufgrund des Beschriebenen schon von selbst zusammenfügt, das Zusammensetzen wäre selbst in der Bauanleitung keine Selbstverständlichkeit.

Nein, es wäre vielmehr ein Schritt, also kein Fazit.

Eine Vernetzung ist schon durch <ol> gegeben, da die Reihenfolge ja offenbar von Belang ist.

Wenn ich nun diese Vernetzung zur Verdeutlichung im Fazit beschreiben will, wie kann das Fazit selbst Teil der Vernetzung sein?

Diese Vernetzung muss nicht beschrieben werden, da sie -- wie gesagt -- elementimmanent ist. Wenn du es dennoch _zusätzlich_ machen möchtest, entzieht sich das der Logik der zur Verfügung stehenden Elemente, weswegen du dann natürlich ein Problem hast. Dieses ist aber hausgemacht, da du hier eine Notwendigkeit siehst, die zumindest ich nicht nachvollziehen kann.

Eine "abgerundete Bedeutung" ist im Übrigen auch gar nicht nötig: "1. Lackieren Sie das Dreieck mit der langsam trocknenden Farbe Rot. 2. Lackieren Sie das Quadrat mit der mittelschenll trocknenden Farbe Blau. 3. Lackieren Sie den Kreis mit der schnell trocknenden Farbe Gelb. Fazit: Jetzt sind alle Teile lackiert und auf Grund der Trocknungsdauer etwa gleich schnell bereit für die nächsten Schritte." Mit Abschluss des dritten Punktes lässt sich hier ein Fazit ziehen,

Wenn sich das Fazit nach Abschluss des dritten Punktes ziehen lässt, kann es nicht selbst dem dritten Punkt angehören, da dieser abgeschlossen sein muss. »Jetzt« bedeutet nicht anderes als das: Nachdem alle drei Punkte in sich abgeschlossen sind und nun insgesamt einen Sinn ergeben. Der dritte Punkt stiftet an und für sich nicht weniger Sinn als die anderen Puzzleteile.

Bei einem "echten" Fazit gäbe ich dir da sogar Recht, aber bei einem Zwischenfazit sehe ich die herausragende Bedeutung nicht gegeben, da es ja nur das Ergebnis bisheriger Teilschritte in ihrer Konsequenz nach einem bestimmten Schritt an passender Stelle erläutert. Als letztendliches Fazit nähme ich wieder ein <li> innerhalb des <ol>.

obwohl es ein Punkt ist wie die vorangegangenen auch.

In einem Schaubild würden drei Pfeile ausgehend von den Knoten der Listenelemente, die jeweils untereinander wieder verbunden sind, auf den Fazitknoten zeigen, nicht nur 1. -> 2 -> 3/Fazit.

Das ist natürlich schon deswegen falsch, weil dann jeweils ein Pfeil von "1." und "2." auf "Fazit" zeigte, obwohl sich "1." vielleicht gar nicht in "Fazit" niederschlagen kann, da es bereits durch "2." zunichte gemacht und nur von "3." in anderer Form wiederhergestellt wurde.

»1.« schlägt sich so oder so im Fazit nieder, selbst wenn es zunichte gemacht wurde, denn das Fazit bezieht sich ja auf dieses Ausschalten und hat nicht nur das letztlich übrig bleibende im Fokus, sonst wäre es meinem Verständnis nach kein Fazit, sondern der vollendende Schritt. Das von mir gemeinte Fazit drückt nicht nur die Konsequenzen des Prozesses an einer bestimmten Stelle desselben aus. Das wäre dann die Beschreibung der Abhängigkeiten und Herleitungsbeziehungen von »3.«, aber kein Fazit aus den ersten drei Schritten, deren Koexistenz ich als Prämisse annahm. Logisch Schließen will ich, wenn überhaupt, nur in dem Fazit selbst, die Teilschritte bezweifeln und negieren sich nicht gegenseitig. (Nun könntest du sagen, dass sie dann ul-Schritte sein müssen, weil sie nicht so stark aufeinander aufbauen.)

Somit hätte auch "2." nichts zu "Fazit" beigetragen, da "Fazit" ja ohnehin durch "3." eingetreten wäre.

Wenn das Fazit durch einen Schritt eintritt, dann ist jeder Schritt für sich gesehen ein Fazit aller vorhergegangenen Punkte und das Fazit nach dem dritten Punkt wäre identisch mit dem dritten Punkt.

Diesen -- aus meinem Verständis heraus -- Fehler hast du bereits einmal erläutert. So wie du Fazit verwendest, verwendete ich "4.".

Das trifft auf manche Abfolgen zu, welche sich entsprechend in einer ol-Liste darstellen lassen, um solche Abfolgen ging es mir gar nicht.

Nach meinem Verständnis sollte dies auf überhaupt keine <ol> in der geschilderten Weise zutreffen, aber es ist gut, dass du dich ja ohnehin nicht darauf beziehst.

Nach bestimmten Schrittabfolgen existieren nennenswertere Ergebnisse als nach anderen Abfolgen, daher könnte ich zwar überall Zwischenfazits einfügen, sie würden aber in den bestimmten Fällen sinnhafter sein.

Dann könnte eine weitere Verschachtelung angebracht sein, aber dies wäre dir wahrscheinlich zu sehr logisch ausgezeichnet.

Der ermöglicht numerische Index ermöglicht dem Leser m.E. eine zusätzliche Orientierung in der Sequenz und fördert die Übersichtlichkeit.

Weshalb dies numerisch geschehen soll, erschließt sich mir aber noch immer nicht. Wenn ich die zugehörigen Textstellen wenigstens gleichäßig über den Text verteilt hätte, könnte ich anhand des Index ablesen, wieviel ich noch lesen muss. Aber dies ist ja nicht zu gewährleisten und wohl auch nur in den seltensten Fällen sinnvoll.

Das meinte ich unter anderem, nur ist der gegenwärtige Standpunkt nicht nur durch diese Art von Hilfestellung definiert. Es geht ja nicht um quantitative Textmenge, sondern darum, dass sich der Leser an der Inhaltsstruktur besser entlanghangeln kann. Kapitelnummerierungen sind ein Mittel, um die Überschriftenhierarchie deutlicher herauszuarbeiten, da die Zahlen sehr schnell ins Auge springen, etwa bei der Suche eines Kapitels.

Wenn du mit "sehr schnell ins Auge springen" das gleiche meinst, wie ich unter "den Lesefluss stören" verstehst, sind wir uns einig ;-)
Nein, im Ernst: Bei einem Buch gäbe ich dir völlig Recht, aber wenn man es mit einem Hypertext-Medium zu tun hat, ist ein "Entlanghangeln" durch einfache Klartext-Referenzierung (<a>) einfacher zu erreichen. Wofür benötige ich den Kapitelnummern bei Rückgriffen auf bereits gesagtes, wenn ich es auch ohne, sondern nur mittels eines Verweises finden kann?
MfG, at

[Tim Tepaße]

Hallo at,

Ich sehe noch immer nicht, wozu ein numerischer Index gut sein soll. Die
Herkunft aus Zeiten, in denen (Papier-)Platz teuer war, lasse ich für mich
jedenfalls nicht gelten.

Ich gebe mal zwei Beispiele, in denen ein numerischer Index sehr praktisch
ist. Papier-Platz ist immer noch teuer. Der wesentliche Ort der Anwendung
von HTML ist zwar immer noch das Web, allerdings ist HTML meines Erachtens
ein Universalformat zur Strukturierung, also nicht nur auf einen elektronischen
Einsatz begrenzt. In einem Ausdruck nützen Querverweise innerhalb des
Dokumentes nicht wirklich was, allein die Kommunikation der tatsächlichen
Adresse eines externen Links (z.B. als Fußnote) ist schon schwierig genug.

Kurznamen können da Abhilfe schaffen, aber es gibt genug Inhalte, die
nicht einfach _und_ eindeutig mit so etwas bezeichnet werden können. Ein
Beispiel ist Mathias' aktuelles Problem. Ein anderes ist mir heute passiert.
Wir saßen zusammen um einen Tisch und lösten ein Übungsblatt. Unter anderem
hatte jeder bestimmte Unterlagen mit vielen verschiedenen Formeln vor sich,
auf die wir uns bezogen. Ein Highlight darunter war diese Formel, die ich
dann mal in ausgesprochener also textueller Form aufgeschrieben habe:

»Der Vertrauenswert der Disjunktion über Phi k für k von eins bis n
  ist größer gleich der Summe für jede Menge K, die Teilmenge einer
  Aufzählung von 1 bis n und nicht leer ist, über minus 1 hoch der
  Kardinalität von K minus 1 multipliziert mit dem Vertrauenswert der
  Konjunktion über Phi k für jedes Element k in der Menge K.«

Nein, es gibt keinen griffigen Begriff für dieses Schlachtschiff von
Formel. Und ständig auf einen bestimmten Abschnitt zu zeigen (»... und
dank dieser Formel ... *zeig* ...) ist auch nicht wirklich praktikabel.
Ich war sehr froh über das flotte »Definition 4.4.4« und mußte an Dich
denken. ;-)

Tim

[at]

Hallo.

»Der Vertrauenswert der Disjunktion über Phi k für k von eins bis n
  ist größer gleich der Summe für jede Menge K, die Teilmenge einer
  Aufzählung von 1 bis n und nicht leer ist, über minus 1 hoch der
  Kardinalität von K minus 1 multipliziert mit dem Vertrauenswert der
  Konjunktion über Phi k für jedes Element k in der Menge K.«

Nein, es gibt keinen griffigen Begriff für dieses Schlachtschiff von
Formel.

Aber diese Formel _ist_ doch verhältnismaßig griffig. So jedenfalls hatte ich mir eine Lösung vorgestellt, wenn die Alternative folgendermaßen aussieht -- und damit dem Ausgangsbeispiel gleicht:
"
a) Verttrauenswert
b) Disjunktion
c) ...
Der a) der b) über c) d) für d) von e) bis f) ist größer gleich g) für jede h) i), die j) einer k) von l) bis m) und nicht n) ist, über o) hoch p) von i) minus e) multipliziert mit q) der r) über c) d) für jedes Element d) in der Menge h).
"
MfG, at

[molily]

»Der Vertrauenswert der Disjunktion über Phi k für k von eins bis n
  ist größer gleich der Summe für jede Menge K, die Teilmenge einer
  Aufzählung von 1 bis n und nicht leer ist, über minus 1 hoch der
  Kardinalität von K minus 1 multipliziert mit dem Vertrauenswert der
  Konjunktion über Phi k für jedes Element k in der Menge K.«

Nein, es gibt keinen griffigen Begriff für dieses Schlachtschiff von Formel.

Aber diese Formel _ist_ doch verhältnismaßig griffig.

Jetzt leugnest du, dass überhaupt eine Bezeichnung gefunden werden muss und den Umgang mit der Formel erleichtert.
In jedem Satz, in dem Aussagen über diese Formel gemacht werden (zum Beispiel in diesem Satz, den ich gerade schreibe), sie mit anderen Formeln verglichen wird usw., müsste jedes Mal der komplette Inhalt der Formel wiederholt werden. Wenn es mehrere Formeln gibt, ist es nicht möglich, mit abkürzenden sprachlichen Mitteln auf sie zu zeigen, wie mit »diese/jene Formel«. Daher gibt man der Formel einen an sich bedeutungsleeren Namen, weil sich kein sprechender Begriff finden lässt, um sie eindeutig zu kennzeichnen. Das hat Tim treffend dargelegt.

So jedenfalls hatte ich mir eine Lösung vorgestellt, wenn die Alternative folgendermaßen aussieht -- und damit dem Ausgangsbeispiel gleicht:

Neinnein, ich meinte, wie ich mittlerweile an einem weiteren Beispiel und dem geschilderten Ursprungsproblem deutlich gemacht habe, dass die Listenelemente bzw. das, auf was sich später bezogen wird, solche komplexen Definitionen enthalten bzw. enthält wie etwa Tims Formel.

a) Verttrauenswert
b) Disjunktion
c) ...
Der a) der b) über c) d) für d) von e) bis f) ist größer gleich g) für jede h) i), die j) einer k) von l) bis m) und nicht n) ist, über o) hoch p) von i) minus e) multipliziert mit q) der r) über c) d) für jedes Element d) in der Menge h).

Das gleich nicht dem Ausgangsbeispiel. So schlecht dies auch war, es bestand eben nicht aus Listenelementen mit einzelnen, griffigen Wörtern/Begriffen, die eins zu eins auf Aliase abgebildet werden und jedes Vorkommen des Begriffs durch den Alias ersetzt werden kann und umgekehrt. Ein Listenelement ist nicht nur ein einzelnes Substantiv, sondern ein gedanklicher Komplex, und dessen sprachliche Beschreibung kann nicht überall dort äquivalent eingesetzt werden, wo der Name dafür eingesetzt wird.

Dein Beispiel hat aber durchaus Verwendung, wenn es umgedeutet wird: Stelle dir vor, in den Listenpunkten a bis q hochkomplexe Formeln abgelegt sind und der nachfolgende Text, welche wiederum selbst eine hochkomplexe Form wie die genannte hat, eine Aussage über diese vielen Formeln macht in Form einer weiteren Formel:

»Der a) der b) über c) d) für d) von e) bis f) ist größer gleich g) für jede h) i), die j) einer k) von l) bis m) und nicht n) ist, über o) hoch p) von i) minus e) multipliziert mit q) der r) über c) d) für jedes Element d) in der Menge h).«

Für jede Bezeichner a) bis q) könnte man nun wieder die Formeln einsetzen, die jeweils so komplex sind wie »Der Vertrauenswert der Disjunktion über Phi k für k von eins bis n ist größer gleich der Summe für jede Menge K, die Teilmenge einer Aufzählung von 1 bis n und nicht leer ist, über minus 1 hoch der Kardinalität von K minus 1 multipliziert mit dem Vertrauenswert der Konjunktion über Phi k für jedes Element k in der Menge K.«. Daher die Notwendigkeit, einen Bezeichner zu finden.

[at]

Hallo.

Jetzt leugnest du, dass überhaupt eine Bezeichnung gefunden werden muss und den Umgang mit der Formel erleichtert.

Ja, die Form entspricht dem, was ich als gut betrachte.

In jedem Satz, in dem Aussagen über diese Formel gemacht werden (zum Beispiel in diesem Satz, den ich gerade schreibe), sie mit anderen Formeln verglichen wird usw., müsste jedes Mal der komplette Inhalt der Formel wiederholt werden.

Die Tatsache, dass ich weiß, von welcher Formel du sprichst, beweist das Gegenteil.

Wenn es mehrere Formeln gibt, ist es nicht möglich, mit abkürzenden sprachlichen Mitteln auf sie zu zeigen, wie mit »diese/jene Formel«.

Es genügt meist, die Unterschiede zwischen den Formeln herauszustellen, so dass man "die Formel, die den Vertrauenswert der Disjunktion über Phi k für k von eins bis n festlegt" doch ganz gut von "der Formel, die den Vertrauenswert der Disjunktion über Phi k für k von eins bis n minus eins festlegt" unterscheiden kann.

Daher gibt man der Formel einen an sich bedeutungsleeren Namen, weil sich kein sprechender Begriff finden lässt, um sie eindeutig zu kennzeichnen.

Stimmt, stattdessen erfindet man eine pq-Formel, die für die Hälfte aller Abiturienten nicht mehr lösbar ist, wenn man p und q gegen x und y austauscht ;-)

Das gleich nicht dem Ausgangsbeispiel. So schlecht dies auch war, es bestand eben nicht aus Listenelementen mit einzelnen, griffigen Wörtern/Begriffen, die eins zu eins auf Aliase abgebildet werden und jedes Vorkommen des Begriffs durch den Alias ersetzt werden kann und umgekehrt. Ein Listenelement ist nicht nur ein einzelnes Substantiv, sondern ein gedanklicher Komplex, und dessen sprachliche Beschreibung kann nicht überall dort äquivalent eingesetzt werden, wo der Name dafür eingesetzt wird.

Dein Beispiel hat aber durchaus Verwendung, wenn es umgedeutet wird: Stelle dir vor, in den Listenpunkten a bis q hochkomplexe Formeln abgelegt sind und der nachfolgende Text, welche wiederum selbst eine hochkomplexe Form wie die genannte hat, eine Aussage über diese vielen Formeln macht in Form einer weiteren Formel:

»Der a) der b) über c) d) für d) von e) bis f) ist größer gleich g) für jede h) i), die j) einer k) von l) bis m) und nicht n) ist, über o) hoch p) von i) minus e) multipliziert mit q) der r) über c) d) für jedes Element d) in der Menge h).«

Für jede Bezeichner a) bis q) könnte man nun wieder die Formeln einsetzen, die jeweils so komplex sind wie »Der Vertrauenswert der Disjunktion über Phi k für k von eins bis n ist größer gleich der Summe für jede Menge K, die Teilmenge einer Aufzählung von 1 bis n und nicht leer ist, über minus 1 hoch der Kardinalität von K minus 1 multipliziert mit dem Vertrauenswert der Konjunktion über Phi k für jedes Element k in der Menge K.«. Daher die Notwendigkeit, einen Bezeichner zu finden.

Einen Ansatz habe ich ja oben aufgeführt, aber der wesentlich einfachere Weg ist sicher, eine mathematische Formel gar nicht auszuschreiben oder falls doch, dann eine Ablaufform in Form einer <ol> zu definieren. Dann entspricht jeder Punkt nicht einem Begriff -- dies wäre ohnehin eher <ul>-typisch --, sondern einem Vorgang: "1. Man nehme dies und das. 2. Man bilde den bla-Wert daraus und multipliziere mit mit blubb, um sülz zu erhalten. 3. Man stelle sülz in den Nenner und die Ableitung von bla in den Zähler. [...] Ergebnis: Die eine Zahl ist meist größer oder kleiner als die andere." In einer Erläuterung mehrerer dieser mathematischen Gebrauchsanweisungen könnte dann heißen: "Statt dies und das nehmen wir heute einmal welches und solches. Daraus ergibt sich, dass der bla-Wert negativ sein muss, da das Ergebnis ansonsten signifikant zu häufig gleich null ist, was der ursprünglichen Formel zuwider liefe."
Du musst es natürlich nicht so schreiben, aber dann sage nicht wieder, ich hätte keinen Lösungsvorschlag unterbreitet.
MfG, at

[Tim Tepaße]

Hallo Mathias,

entschuldige bitte den etwas wirren Betreff (Gut, inzwischen nicht mehr
ganz so wirr, nachdem mit CKs Software genötigt hat, den eigentlich
exakteren Betreff zu kürzen).

ich zweifle an der Vereinbarung, dass der Nummerierungstyp von geordneten
Listen (ol) zur Präsentation gehört und deshalb ins Stylesheet und nicht
ins Markup gehört.

Ich auch. Nachdem ich mich jetzt durch mehrere CSS3-Module, durch XHTML2
und archivierte Maildebatten auf www-style gewühlt und trotzdem nichts
gefunden habe, kam ich nicht drumherum, mir auch dazu eine Meinung zu
bilden. Und zwar ist das Grundproblem dieses: Wie referenziert man bereits
genanntes im späteren Verlauf des Dokumentes nochmal? Ich denke, daß macht
man am besten automatisch, nicht in textueller Form wie Du vorgeschlagen
hast.

Ich gebe mal ein ähnliches Beispiel aus Latex. Dort kann man auch
automatisch vergebene Kapitelnummern später wieder referenzieren:

...
  \section{Blablablabla} \label{bla}
  ...
  ...
  \section{Heiße Luft}
  ...
  Ähnliche Argumentationsstrategien finden Sie auch im Kapitel~\ref{bla}.
  ...

Wenn jetzt das Latex-Dokument kompiliert wird, kann zum Beispiel so etwas
dabei herauskommen (natürlich auf diktengleichen Text umgesetzt):

2.1.3 Blablablabla
   ...
   ...
  4.3.2.1 Heiße Luft
   ...
   Ähnliche Argumentationsstrategien finden Sie auch im Kapitel 2.1.3.

Man sieht: Hierbei wird die Nummerierung übernommen und eingesetzt. (Wobei,
bei dem sehr nacheinander ablaufenden Tex wird hierbei die Nummer der
vorhergehenden Kompilation genommen. Sehr nervig, sowas)

Welche Möglichkeiten gibt es denn in HTML, um solche dokumenteninternen
Referenzierungen auszuführen? Die ID eines Elementes und die href-Verweise
mit Ankern. Allerdings wird hierbei nur die Information gegeben, daß
zwischen diesen beiden Stellen ein Verweis existiert, nicht den Inhalt
der referenzierten Stelle.

Hier zeigt sich eine Schwäche von CSS, auch anscheinend von CSS 3. Ich
zeige das mal mit einem Beispiel wie bei at auf:

<li id="apfel">Apfel</li>
  ...
  <p>Wir nehmen <a href="#apfel" class="intern-ref"></a>
  und tun dies und das</p>

Das Ziel ist es jetzt, in CSS eine Regel zu definieren, die die (als
gegeben angenommene) Nummerierung von li#apfel einfügt. Dieses geht,
so meine ich, mit bestehender und zukünftiger Syntax von CSS nicht.
Man müßte ungefähr eine Regel samt Selektor bastelt, die ungefähr
folgendes leistet:

Für jedes a mit der Klasse intern-ref definiere mit content einen
  Inhalt, der gleich dem Inhalt vom berechneten :before-Pseudoelement
  des Elementes ist, dessen ID im href-Attribut angesprochen ist.

(Für CSS 3 denke man sich das entsprechend mit ::marker. Außerdem
  wäre auch ein Einsatz des cite-Attributes denkbar.)

Ich sehe nicht, daß dieses mit der Syntax von CSS geht. Auch CSS 3 wird
dieses nicht erlauben, meine ich verstanden zu haben. Zwar gibt es
Funktionen, die es erlauben Elementinhalt woanders im Dokument wieder
anzeigen zu lassen (::alternate und move-to), allerdings scheint es mir,
das dieses auf einen einmaligen Einsatz beschränkt ist, so zum Beispiel
für Fußnoten.

Warum schreibe ich nun all dieses von automatischer Referenzierung? Weil
dieses meiner Meinung nach aus der Trennung von Struktur und Präsentation
folgt. Du schriebst dieses:

Es kann doch nicht sein, dass man für alle Zeiten auf die
Standard-Dezimalnummerierung festgelegt ist (..)

Das ist man sowieso. Durch die Struktur der einzelnen Elemente im
Dokument kann man jedes Element durch eine Nummer identifizieren.
Wie dann diese Nummer dargestellt wird, bleibt der Präsentation
überlassen, ob binär, dezimal, hexadezimal, latein-alphabetisch,
armenisch. Das heißt die Nummer ist von ihrer Präsentation getrennt.
Und schließlich kann man auch ganz andere Nummerierungen nutzen:

li:nth-child(1):before {content:'Kawummmm!';}
  li:nth-child(2):before {content:'Raabömms!';}
  li:nth-child(3):before {content:'Dingding!';}

Das heißt man hat eine unendliche Menge von möglichen Darstellungen einer
Nummerierung zur Verfügung.

Man könnte sagen, daß Du, als Du dieses geschrieben hast ...

<p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d)
  aus. Fertig ist die Sauerei.</p>

... die Trennung von Struktur und Präsentation unterlaufen hast. Du hast
nämlich ein Merkmal der Präsentation benutzt ("d)"), das nur ein Platzhalter
für ein Element ist, dieses also referenziert (Element 4 der Liste bla).

CSS, als Mittel für die Präsentation gibt jedoch kein Mittel für die
automatische Darstellung eines Identifizikator des referenzierten
Elementes zur Verfügung. Nein, ich kann diese Bezeichnung wirklich
nicht verkürzen ohne einen entscheidenen Verlust auf Exaktheit.
Deswegen leider auch das Theater mit dem Titel.

Weswegen ich sagen würde, dieses ist eher eine Schwäche von CSS als
Mittel der angestrebten Trennung von Inhalt und Präsentation, weniger
eine Fehleinschätzung, ob die Darstellung der Ordinalzahl einer
Reihenfolge von Elementen doch zur Struktur gehöre. Allerdings: ich
kann mir auch die entgegengesetzte Meinung als vorstellbare Argumentation
vorstellen. Irgendwie ein Graubereich, in dem man eine Entscheidung
zu treffen hat. Latex ist da offensichtlich im Vorteil, weil es nur
eine Ausgabemöglichkeit hat.

Lösungsvorschläge? Naja. Nur die von Dir vorgeschlagene Festverdrahtung,
eventuell angereichert durch die von HTML (und at) vorgeschlagene
Verweise auf Anker, um eine Referenzierung aufzuzeigen.

Oder aber der Verzicht auf solche Referenznummern. Wie oft braucht man
dieses denn in der Wirklichkeit? Wohl eher nur in mathematisch-technischen
Dokumenten (»Vergleiche Theorem 4.23.5.1a«). Und streng genommen, wenn
man das weiterdenkt: Es wären dann auch theoretisch CSS-Regeln möglich,
die, wenn man einen Link auf eine andere Ressource setzt, den Titel
dieses Dokumentes übernehmen. Und so verweist man normalerweise nicht,
man setzt etwas eigenes als Inhalt des Linkes.

Ja, alles sehr unbefriedigend.

Tim

[at]

Hallo.

Welche Möglichkeiten gibt es denn in HTML, um solche dokumenteninternen
Referenzierungen auszuführen? Die ID eines Elementes und die href-Verweise
mit Ankern. Allerdings wird hierbei nur die Information gegeben, daß
zwischen diesen beiden Stellen ein Verweis existiert, nicht den Inhalt
der referenzierten Stelle.

Dies findet bei einm "a." oder "1." aber auch nicht statt, da dies semantisch kein Inhalt ist.

Hier zeigt sich eine Schwäche von CSS, auch anscheinend von CSS 3. Ich
zeige das mal mit einem Beispiel wie bei at auf:

<li id="apfel">Apfel</li>
  ...
  <p>Wir nehmen <a href="#apfel" class="intern-ref"></a>
  und tun dies und das</p>

Am besten nehmen wir "Äpfel" ;-)

Das Ziel ist es jetzt, in CSS eine Regel zu definieren, die die (als
gegeben angenommene) Nummerierung von li#apfel einfügt.

Warum willst du mit viel Aufwand auf eine Zahl verweisen, wenn du den Inhalt bereits benannt hast. Das ist ja javaesk ;-)

(Für CSS 3 denke man sich das entsprechend mit ::marker. Außerdem
  wäre auch ein Einsatz des cite-Attributes denkbar.)

Und <cite>?

Lösungsvorschläge? Naja. Nur die von Dir vorgeschlagene Festverdrahtung,
eventuell angereichert durch die von HTML (und at) vorgeschlagene
Verweise auf Anker, um eine Referenzierung aufzuzeigen.

Jetzt habe ich es geschafft: Du nennst HTML und mich in einem Atemzug ;-)

Oder aber der Verzicht auf solche Referenznummern. Wie oft braucht man
dieses denn in der Wirklichkeit? Wohl eher nur in mathematisch-technischen
Dokumenten (»Vergleiche Theorem 4.23.5.1a«).

Eben, nicht der Standard ist unzureichend, sondern die eigene Vorgehensweise ist zu stark auf Strukturen fixiert, die alles andere als aufnahmefreundlich sind.

Ja, alles sehr unbefriedigend.

Komisch, das finde ich gar nicht.
MfG, at

[Tim Tepaße]

Hallo at,

Am besten nehmen wir "Äpfel" ;-)

Natürlich. Aber trotzdem kann ich mir gut Situationen vorstellen, in denen
man kurze Prägnante Bezeichner für längere Teilstücke im Dokument braucht.
Man kann so etwas nicht immer mit einem Verweis regeln, ein Beispiel wären
Druckstylesheets.

Warum willst du mit viel Aufwand auf eine Zahl verweisen, wenn du den Inhalt
bereits benannt hast. Das ist ja javaesk ;-)

Und der der Inhalt sehr viel länger und komplizierter ist als »Äpfel«?

Eben, nicht der Standard ist unzureichend, sondern die eigene Vorgehensweise
ist zu stark auf Strukturen fixiert, die alles andere als aufnahmefreundlich
sind.

Das bezweifele ich. Manchmal braucht man solche Bezeichner und da ist eine
konsequente Nummerierung oft besser als Äquivalente. Nicht jeder Satz heißt
»Satz des Pythagoras«.

Tim

[at]

Hallo.

Natürlich. Aber trotzdem kann ich mir gut Situationen vorstellen, in denen
man kurze Prägnante Bezeichner für längere Teilstücke im Dokument braucht.
Man kann so etwas nicht immer mit einem Verweis regeln, ein Beispiel wären
Druckstylesheets.

Ob Druck-Stylesheets oder nicht, zwischen <a> und </a> muss etwas sinnvolles stehen.

Warum willst du mit viel Aufwand auf eine Zahl verweisen, wenn du den Inhalt
bereits benannt hast. Das ist ja javaesk ;-)

Und der der Inhalt sehr viel länger und komplizierter ist als »Äpfel«?

So lässt ersich mit "1." oder "a." vermutlich auch nicht hinreichend beschreiben.

Eben, nicht der Standard ist unzureichend, sondern die eigene Vorgehensweise
ist zu stark auf Strukturen fixiert, die alles andere als aufnahmefreundlich
sind.

Das bezweifele ich. Manchmal braucht man solche Bezeichner und da ist eine
konsequente Nummerierung oft besser als Äquivalente. Nicht jeder Satz heißt
»Satz des Pythagoras«.

Dass man beispielsweise auf bestimmte juristische Paragraphen verweisen muss, bezweifle ich sicher nicht, auch in diesem Fall eigentlich keine echte Numerierung vorliegt, sondern eher eine Art "zahlenförmige Nomenklatur". Aber prinzipiell machen es sich sehr viele -- meines Erachtens die meisten -- Autoren selbst zu leicht und ihren Lesern zu schwer.
Mir sind jedenfalls bisher keine passenden Beispiele eingefallen, anhand derer ich die Schwierigkeiten hätte nachvollziehen können, da ohnehin oft <ol> verwendet wird, wenn meines Erachtens eigentlich <ul> angebracht wäre.
MfG, at

[Tim Tepaße]

Hallo at,

So lässt ersich mit "1." oder "a." vermutlich auch nicht hinreichend
beschreiben.

Das soll ja auch nicht geschehen, es soll ein Verweis darauf gesetzt
werden.

(..) da ohnehin oft <ol> verwendet wird, wenn meines Erachtens eigentlich
<ul> angebracht wäre.

Ich erkenne sowieso wegen der Zähler-Möglichkeit von CSS, auch wenn diese
nur in Opera funktioniert, keinerlei semantische Unterschiede zwischen ol
und ul.

Tim

[at]

Hallo.

Ich erkenne sowieso wegen der Zähler-Möglichkeit von CSS, auch wenn diese
nur in Opera funktioniert, keinerlei semantische Unterschiede zwischen ol
und ul.

Diesmal verwechselst du etwas:
Die Semantik wird ja nicht mittels CSS definiert, sondern sollte strukturell vorhanden, also im HTML festgelegt sein. Und dort ergibt sich ja ein deutlicher Unterschied zwischen <ol> und <ul>. So verwende ich <ol> nur dann, wenn ich eine Rang- oder Reihenfolge festlegen möchte, etwa in einem Kochrezept, einer Bauanleitung oder einem Hierarchie-Schema. Eine Ausnahme bilden numerierte Systeme wie beispielsweise eine Mannschaftsaufstellung im Sport, die ja keine Rangfolge abbilden. Bei einem alphabetisch sortierten Telefonverzeichnis hingegen würde ich eine <dl>/<ul>-Verschachtelung vorziehen.
MfG, at

[Tim Tepaße]

Hallo at,

Die Semantik wird ja nicht mittels CSS definiert, sondern sollte strukturell
vorhanden, also im HTML festgelegt sein. Und dort ergibt sich ja ein
deutlicher Unterschied zwischen <ol> und <ul>.

Ich persönlich halte diesen Unterschied für sehr gering bis vernachlässigbar.
Beide Elemente haben eine strikte Reihenfolge, egal, ob man sie geordnet
oder ungeordnet nennt. Und in der Theorie lassen sich beide mit den
generierten CSS-Zählern beliebig nummerieren oder auch nicht nummerieren.

Tim

[at]

Hallo.

Ich persönlich halte diesen Unterschied für sehr gering bis vernachlässigbar.
Beide Elemente haben eine strikte Reihenfolge, egal, ob man sie geordnet
oder ungeordnet nennt.

Nimm das Forum zum Vergleich: Die einzelnen Threads haben eine strikte Reihenfolge, die aber beliebig ist, weshalb hier <ul> angemessen wäre. Spätestens beim Verschwinden alter Threads oder im Archiv funktioniert die alte Reihenfolge ja ohnehin nicht mehr. Die einzelnen Beiträge innerhalb eines Thread hingegen sind zeitlich sortiert, was für deren Verständnis mitunter unabdingbar sein kann.
Ich kann und will dir natürlich nicht vorschreiben, wie _du_ dies handhabst, aber ich hoffe, du kannst meinen Ansatz nachvollziehen.
MfG, at

[Tim Tepaße]

Hallo at,

Nimm das Forum zum Vergleich: Die einzelnen Threads haben eine strikte
Reihenfolge, die aber beliebig ist, weshalb hier <ul> angemessen wäre.
Spätestens beim Verschwinden alter Threads oder im Archiv funktioniert die
alte Reihenfolge ja ohnehin nicht mehr.

Oh doch. Auch beim Archivieren von Threads zwischen anderen Threads bleibt
eine Reihenfolge vorhanden. Die Threads sind zeitlich nach dem Posting des
Threadinitiators geordnet. ;)

Ich kann und will dir natürlich nicht vorschreiben, wie _du_ dies handhabst,
aber ich hoffe, du kannst meinen Ansatz nachvollziehen.

Natürlich. Solange man mir <ol> zur Verfügung stellt nutze ich es ja auch.
Nur mit dem Beginn der Einführung automatischer Zähler habe ich nun mal
Zweifel am semantischen Mehrwert gegenüber <ul> entwickelt. Und der darf
durchaus erlaubt sein, ich erinnere nur an so etwas wie <pre>. ;-)

Tim

[at]

Hallo.

Oh doch. Auch beim Archivieren von Threads zwischen anderen Threads bleibt
eine Reihenfolge vorhanden. Die Threads sind zeitlich nach dem Posting des
Threadinitiators geordnet. ;)

Mir ist völlig unverständlich, wie ich das bisher habe übersehen können ;-)

Natürlich. Solange man mir <ol> zur Verfügung stellt nutze ich es ja auch.
Nur mit dem Beginn der Einführung automatischer Zähler habe ich nun mal
Zweifel am semantischen Mehrwert gegenüber <ul> entwickelt. Und der darf
durchaus erlaubt sein, ich erinnere nur an so etwas wie <pre>. ;-)

Nein, wir müssen sicher nicht um den Sinn oder Unsinn einzelner Tags "streiten" ;-)
MfG, at

[molily]

(...) Das heißt die Nummer ist von ihrer Präsentation getrennt.

Ja...

Und schließlich kann man auch ganz andere Nummerierungen nutzen:

li:nth-child(1):before {content:'Kawummmm!';}
  li:nth-child(2):before {content:'Raabömms!';}
  li:nth-child(3):before {content:'Dingding!';}

Das heißt man hat eine unendliche Menge von möglichen Darstellungen einer
Nummerierung zur Verfügung.

...die an sich nicht inhaltbildend wirken dürfen, das ist ziemlich absurd.

Man könnte sagen, daß Du, als Du dieses geschrieben hast ...

<p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d)
  aus. Fertig ist die Sauerei.</p>

... die Trennung von Struktur und Präsentation unterlaufen hast. Du hast nämlich ein Merkmal der Präsentation benutzt ("d)"), das nur ein Platzhalter für ein Element ist, dieses also referenziert (Element 4 der Liste bla).

Exakt.

Oder aber der Verzicht auf solche Referenznummern. Wie oft braucht man dieses denn in der Wirklichkeit? Wohl eher nur in mathematisch-technischen Dokumenten (»Vergleiche Theorem 4.23.5.1a«).

Das mag sein, sprechen wir lieber von Texten einer bestimmten Inhaltsstruktur, das gilt ja auch für wissenschaftliche nichttechnische Abhandlungen.
Ich bin auf das Problem konkret dadurch gestoßen, dass ich Code dokumentieren wollte. Für die »Berechnung« bzw. den Programmablauf gibt es mehrere Parameter, die teilweise in ihrer Art voneinander abhängen und zusammenhängen, daher die geordnete Liste. (Vielleicht wären sogar a1, a2, ..., b1, b2 usw. angebrachter.) Diese nötigen Parameter, die letztlich zur Ergebnisfindung miteinander abgeglichen werden, stehen dem Programm selbst nicht direkt zur Verfügung, sondern es bekommt andere Parameter, die das Programm erst einmal durch Fummelei in Form einer Kaskade von bedingten Anweisungen und Fallunterscheidungen bereinigen, vereinheitlichen und somit in die benötigten Parameter überführen muss (ich arbeite seit Tagen daran, diesen Algorithmus auf ein paar Fallunterscheidungen zu verkürzen). Der Hintergrund ist, dass verschiedene Hostsysteme unter ein und derselben Objekteigenschaft (letztlich ist es trivial, es geht um JavaScript und einen großen Haufen unlogischer Browserbugs und anderer Inkonsistenzen) verschiedene Parameter zur Verfügung stellen. In dem erklärenden Text will ich die Vorgehensweise des Programms beschreiben und beziehe mich logischerweise andauernd auf die einen und die anderen Parameter. Deren Erklärung und Bedeutung will ich nicht ständig wiederholen, beziehungsweise deren ausgeschriebene Namen, die eine Bedeutungsdifferenzierung erlauben, sind sind extrem lang wie etwa »Der A-B des C im Form von D unter der Bedingung E ohne F, aber mit G und optional mit H«. Daher kam ich auf die Liste mit a, b, c, sodass ich im Text nur diese nennen muss.

[at]

Hallo.

Ich bin auf das Problem konkret dadurch gestoßen, dass ich Code dokumentieren wollte. Für die »Berechnung« bzw. den Programmablauf gibt es mehrere Parameter, die teilweise in ihrer Art voneinander abhängen und zusammenhängen, daher die geordnete Liste. (Vielleicht wären sogar a1, a2, ..., b1, b2 usw. angebrachter.) Diese nötigen Parameter, die letztlich zur Ergebnisfindung miteinander abgeglichen werden, stehen dem Programm selbst nicht direkt zur Verfügung, sondern es bekommt andere Parameter, die das Programm erst einmal durch Fummelei in Form einer Kaskade von bedingten Anweisungen und Fallunterscheidungen bereinigen, vereinheitlichen und somit in die benötigten Parameter überführen muss (ich arbeite seit Tagen daran, diesen Algorithmus auf ein paar Fallunterscheidungen zu verkürzen). Der Hintergrund ist, dass verschiedene Hostsysteme unter ein und derselben Objekteigenschaft (letztlich ist es trivial, es geht um JavaScript und einen großen Haufen unlogischer Browserbugs und anderer Inkonsistenzen) verschiedene Parameter zur Verfügung stellen. In dem erklärenden Text will ich die Vorgehensweise des Programms beschreiben und beziehe mich logischerweise andauernd auf die einen und die anderen Parameter. Deren Erklärung und Bedeutung will ich nicht ständig wiederholen, beziehungsweise deren ausgeschriebene Namen, die eine Bedeutungsdifferenzierung erlauben, sind sind extrem lang wie etwa »Der A-B des C im Form von D unter der Bedingung E ohne F, aber mit G und optional mit H«. Daher kam ich auf die Liste mit a, b, c, sodass ich im Text nur diese nennen muss.

Und bei jeder Änderung müsste alles über den Haufen geworfen werden? Wenn es sich um Variablen handelt, würde ich mich ohnehin nicht an eine Automatik binden, um die Flexibilität zu wahren.
MfG, at

[molily]

Und bei jeder Änderung müsste alles über den Haufen geworfen werden?

Mir fällt kein Weg ein, wie ich das verhindern könnte. Den Algorithmus habe ich tatsächlich mehrmals verändert, sodass ich auch die Dokumentation anpassen musste, ich sehe nicht, wie die Lösung der Frage der angemessenen und stringenten Verweise und dafür genutzte Bezeichnungen darauf Einfluss hat.

Wenn es sich um Variablen handelt, würde ich mich ohnehin nicht an eine Automatik binden, um die Flexibilität zu wahren.

Was bedeutet dieser Satz? Falls ich dich richtig verstehe: Nach dem Vereinheitlichungsprozess sind die letztlich benötigten Parameter nicht mehr beliebige, typ- und schemalose Variable. Sie können unabhängig vom konkreten Inhalt weiterverarbeitet werden und es sind nur noch kleinere Anpassungen in Form von Fallunterscheidungen nötig. Die direkt abfragbaren Parameter (es sind Objekteigenschaften) sind zumindest in ihren Namen gleich (daher ist es einfacher, sich auf diese zu beziehen, auch wenn die Namen nicht unbedingt »sprechen«), nur die Inhalte sind zum Teil grundverschieden.
Abgesehen davon berücksichtigt der Algorithmus prinzipiell, dass gewisse Objekteigenschaften nicht zur Verfügung stehen, dabei geht es allerdings nur um das Ausschließen bestimmter Browser, nicht um das Anbieten von Alternativwegen. Das letztliche Programmziel selbst funktioniert sowieso nur ab Netscape 4 und MSIE 4, so beinhaltet der Weg dorthin gleiche Anforderungen, aussortiert wird aber schon am Anfang.

[at]

Hallo.

Den Algorithmus habe ich tatsächlich mehrmals verändert, sodass ich auch die Dokumentation anpassen musste, ich sehe nicht, wie die Lösung der Frage der angemessenen und stringenten Verweise und dafür genutzte Bezeichnungen darauf Einfluss hat.

Bei einer automatischen Numerierung wie bei <ol> kann ich nicht einfach einen Eintrag entfernen, ohne die gesamte Struktur überarbeiten zu müssen. Wenn ich hingegen einen sprechenden Namen entferne, habe ich dieses Problem nicht.

Wenn es sich um Variablen handelt, würde ich mich ohnehin nicht an eine Automatik binden, um die Flexibilität zu wahren.

Was bedeutet dieser Satz?

Siehe oben. -- Ein genau so unsinniger Verweis ;-)
Daher: Ich nähme sprechende Namen.

Falls ich dich richtig verstehe: Nach dem Vereinheitlichungsprozess sind die letztlich benötigten Parameter nicht mehr beliebige, typ- und schemalose Variable. Sie können unabhängig vom konkreten Inhalt weiterverarbeitet werden und es sind nur noch kleinere Anpassungen in Form von Fallunterscheidungen nötig. Die direkt abfragbaren Parameter (es sind Objekteigenschaften) sind zumindest in ihren Namen gleich (daher ist es einfacher, sich auf diese zu beziehen, auch wenn die Namen nicht unbedingt »sprechen«), nur die Inhalte sind zum Teil grundverschieden.
Abgesehen davon berücksichtigt der Algorithmus prinzipiell, dass gewisse Objekteigenschaften nicht zur Verfügung stehen, dabei geht es allerdings nur um das Ausschließen bestimmter Browser, nicht um das Anbieten von Alternativwegen. Das letztliche Programmziel selbst funktioniert sowieso nur ab Netscape 4 und MSIE 4, so beinhaltet der Weg dorthin gleiche Anforderungen, aussortiert wird aber schon am Anfang.

Ich befürchte, dies wird zu speziell -- und dies in einem Bereich, in dem ich nicht sattelfest bin. Daher habe ich größere Schwierigkeiten, deinen Ausführungen zu folgen. Mit "Obst" ging das ja noch ganz gut ;-)
Du kannst auch gern versuchen, es mir noch banaler zu erklären, oder schlicht ein aussagekräftiges Beispiel geben. Und ich glaube dir auch, dass es schwierig ist, eine Lösung für dein Problem zu finden, aber letztlich sehe ich dieses Problem eher auf sprachlicher Ebene ("Wie formuliere ich meine Aussage unmissverständlich unter Rückbeziehung auf bereits aufgezähltes?") als auf technischer ("Welche HTML-Elemente muss ich wie nutzen, damit jeder Browser das darstellt, was ich mir denke?").
MfG, at

[molily]

Den Algorithmus habe ich tatsächlich mehrmals verändert, sodass ich auch die Dokumentation anpassen musste, ich sehe nicht, wie die Lösung der Frage der angemessenen und stringenten Verweise und dafür genutzte Bezeichnungen darauf Einfluss hat.

Bei einer automatischen Numerierung wie bei <ol> kann ich nicht einfach einen Eintrag entfernen, ohne die gesamte Struktur überarbeiten zu müssen. Wenn ich hingegen einen sprechenden Namen entferne, habe ich dieses Problem nicht.

Das stimmt im Allgemeinen, nur sind solche groben und allumfassenden Änderung im Konzept zumindest beim genannten JavaScript noch nicht vorgekommen.

Wenn es sich um Variablen handelt, würde ich mich ohnehin nicht an eine Automatik binden, um die Flexibilität zu wahren.

Was bedeutet dieser Satz?

Siehe oben. -- Ein genau so unsinniger Verweis ;-)
Daher: Ich nähme sprechende Namen.

Ich *nähme* auch sprechende Namen, wenn ich *könnte*! Ich sträube mich keinesfalls dagegen. Dieser Thread dreht sich doch, was mein Anliegen angeht, darum, dass sich keine sprechenden Namen finden lassen, entweder aufgrund des Exaktheitsmangel der zu Verfügung stehenden sprachlichen Ausdrücke oder weil sich der Sachverhalt nicht auf ein bis zwei Kernmerkmale begrenzen lässt, welche dann vom gewählten mglw. zusammengesetzten Begriff mit viel Metaphorik bedeutet werden.

Um mich zu zitieren: »Namen, die eine Bedeutungsdifferenzierung erlauben, sind extrem lang wie etwa 'Der A-B des C im Form von D unter der Bedingung E ohne F, aber mit G und optional mit H'«. Deine Argumentationslinie, dass es sprechende Namen gebe, die im Prinzip leicht zu finden seien, hilft mir nicht weiter.

Du kannst auch gern versuchen, es mir noch banaler zu erklären, oder schlicht ein aussagekräftiges Beispiel geben.

Ja, das habe ich sowieso vor, wenn ich Code und Codeerklärung halbwegs fertig habe.

Und ich glaube dir auch, dass es schwierig ist, eine Lösung für dein Problem zu finden, aber letztlich sehe ich dieses Problem eher auf sprachlicher Ebene ("Wie formuliere ich meine Aussage unmissverständlich unter Rückbeziehung auf bereits aufgezähltes?") als auf technischer ("Welche HTML-Elemente muss ich wie nutzen, damit jeder Browser das darstellt, was ich mir denke?").

Ja, wobei sich das m.E. nicht wirklich voneinander entkoppeln lässt.

[at]

Hallo.

Ich *nähme* auch sprechende Namen, wenn ich *könnte*! Ich sträube mich keinesfalls dagegen. Dieser Thread dreht sich doch, was mein Anliegen angeht, darum, dass sich keine sprechenden Namen finden lassen, entweder aufgrund des Exaktheitsmangel der zu Verfügung stehenden sprachlichen Ausdrücke oder weil sich der Sachverhalt nicht auf ein bis zwei Kernmerkmale begrenzen lässt, welche dann vom gewählten mglw. zusammengesetzten Begriff mit viel Metaphorik bedeutet werden.

Um mich zu zitieren: »Namen, die eine Bedeutungsdifferenzierung erlauben, sind extrem lang wie etwa 'Der A-B des C im Form von D unter der Bedingung E ohne F, aber mit G und optional mit H'«. Deine Argumentationslinie, dass es sprechende Namen gebe, die im Prinzip leicht zu finden seien, hilft mir nicht weiter.

Dennoch erfüllen diese Variablen/Konstanten etweder einen Zweck oder können von irgendwo hergeleitet werden. Ich will dich im speziellen Fall ja auch gar nicht dazu verleiten, "C" durch "negierter Maximalwert des Arrays der Postleitzahlen" zu ersetzen, sondern vielleicht durch "-maxPLZ", sowie ich ich "pi" oder "sin(x)" ja auch nicht ausschreibe. Vor allem würde ich mich damit von der alphabetischen Reihenfolge lösen, die es mir nahelegt, mich auf die von dir ja als problematisch erkannten Listen zu verlassen.

Ja, das habe ich sowieso vor, wenn ich Code und Codeerklärung halbwegs fertig habe.

Prima. -- Noch freue ich mich. Aber wer weiß? Vielleicht stoße ich bei deinem Problem tatsächlich an die Grenzen "meines" Konzeptes.

Und ich glaube dir auch, dass es schwierig ist, eine Lösung für dein Problem zu finden, aber letztlich sehe ich dieses Problem eher auf sprachlicher Ebene ("Wie formuliere ich meine Aussage unmissverständlich unter Rückbeziehung auf bereits aufgezähltes?") als auf technischer ("Welche HTML-Elemente muss ich wie nutzen, damit jeder Browser das darstellt, was ich mir denke?").

Ja, wobei sich das m.E. nicht wirklich voneinander entkoppeln lässt.

In diese Enkoppelung investiere ich sehr viel Zeit und Energie, denn getrennt voneinander sind die einzelnen Schwierigkeiten kleiner und damit besser lösbar. Kurzfristig zahle ich dabei drauf, langfristig erhoffe ich mir aber eine deutliche Ersparnis. -- Nein, von Selbstzweck keine Spur.
MfG, at

[Ingo Turski]

Hi Mathias,

Ich *nähme* auch sprechende Namen, wenn ich *könnte*!

wenn das tatsächlich nicht sinnvoll geht - wie wäre es mit einer "Notlösung" in der Art:
<ul><li><em>a)</em>... ?

Natürlich nicht so sauber wie eine sortierte Liste, wenn man in dieser das type-attribut verwenden könnte.

freundliche Grüße
Ingo

[at]

Hallo.

wenn das tatsächlich nicht sinnvoll geht - wie wäre es mit einer "Notlösung" in der Art:
<ul><li><em>a)</em>... ?

Weshalb <em>? Ein <span> wäre wenigstens "geschmacksneutral". -- Das heißt natürlcih nicht, dass es nicht vielleicht auch eine besser passendes Element gibt. Ich fände etwa auch eine <dl> nicht Fehl am Platz.
MfG, at

[Ingo Turski]

Hi,

Weshalb <em>? Ein <span> wäre wenigstens "geschmacksneutral".

sollte es aber in diesem Beispiel nicht sein, da der "Listenpunkt" hervorgehoben werden sollte, damit der Leser ihn sich einprägt; quasi als 'Vorwarnung' künftiger Bezugnahme.

freundliche Grüße
Ingo

[at]

Hallo.

sollte es aber in diesem Beispiel nicht sein, da der "Listenpunkt" hervorgehoben werden sollte, damit der Leser ihn sich einprägt; quasi als 'Vorwarnung' künftiger Bezugnahme.

Ich verstehe, aber wäre nicht sinnvoll, ihn auch als Listenpunkt kenntlich zu machen, etwa in Form eines <dt>?
MfG, at

[Ingo Turski]

Hi,

Ich verstehe, aber wäre nicht sinnvoll, ihn auch als Listenpunkt kenntlich zu machen, etwa in Form eines <dt>?

sicherlich würde das hier passen. Nur wäre das m.E. doch eher ein Overkill, der sich vermeiden ließe, wenn entweder das type-Attribut im HTML die Nummerierungsart vorgibt oder man in Ermangelung dessen auf eine stimmige Ausgabe bei nur-HTML verzichtet.

freundliche Grüße
Ingo

[Ingo Turski]

Hi,

gerade als ich diersen Text abgeschickt hatte, fiel mir noch ein prakischer Ersatz für das m.E. fehlende type-Attribut ein:
<ol><li title="a)">...

freundliche Grüße
Ingo

[at]

Hallo.

gerade als ich diersen Text abgeschickt hatte, fiel mir noch ein prakischer Ersatz für das m.E. fehlende type-Attribut ein:
<ol><li title="a)">...

Ich bin mir zwar nicht sicher, wie dies zu funktionieren hat, aber du bist herzlich eingelanden, es mir zu erläutern -- Vielleicht sehe ich auch nur einfach den Wald vor lauter Bäumen nicht ;-)
MfG, at

[Ingo Turski]

Hi,

<ol><li title="a)">...

Ich bin mir zwar nicht sicher, wie dies zu funktionieren hat, aber du bist herzlich eingelanden, es mir zu erläutern

einfach so, daß bei reiner Text-Darstellung zwar "1. Text..." angezeigt wird, dieser Text jedoch über das Title-Attribut mit "a)" benannt ist und diese Information auch ohne CSS im Text verfügbar ist. Opera zeigt es z.B. bei mouseover normal an, Screenreader vermute ich mal davor in der art "a) 1. Text...". Nicht schön, aber eingeschränkt brauchbar.

Und zu Deinen vorigen Posting: Ja, ich lese die Beiträge hier, wenngleich ich zugebe, daß ich einiges manchmal überfliege. Und noch habe ich keine Argumente gelesen, die für mein Emfinden Mathias' Aussage widerlegen. Mal ehrlich: gerade _daß_ das Thema so kontrovers diskutiert werden kann, spricht doch eigentlich dafür, das Type-Attribut weiterhin zuzulassen, oder? Zumal wenn Elemente wie <b> erlaubt sind.

freundliche Grüße
Ingo

[at]

Hallo.

<ol><li title="a)">...

Ich bin mir zwar nicht sicher, wie dies zu funktionieren hat, aber du bist herzlich eingelanden, es mir zu erläutern

einfach so, daß bei reiner Text-Darstellung zwar "1. Text..." angezeigt wird, dieser Text jedoch über das Title-Attribut mit "a)" benannt ist und diese Information auch ohne CSS im Text verfügbar ist. Opera zeigt es z.B. bei mouseover normal an, Screenreader vermute ich mal davor in der art "a) 1. Text...". Nicht schön, aber eingeschränkt brauchbar.

So war das also gemeint, danke. Dann handelte es sich also um eine Art Meta-Angabe im <body>? Das finde ich okay.

Und zu Deinen vorigen Posting: Ja, ich lese die Beiträge hier, wenngleich ich zugebe, daß ich einiges manchmal überfliege. Und noch habe ich keine Argumente gelesen, die für mein Emfinden Mathias' Aussage widerlegen.

Mir ging es nicht darum, wen auch immer zu widerlegen, sondern nur darum, aufzuzeigen, welche Lösung ich für meine Projekte gefunden habe. Dies mag kein Allheilmittel sein, aber für meine Zwecke ist es sehr brauchbar, obwohl diese Zwecke durchaus variieren. Meine Einschätzung, daraus eine Ableitung auf beliebige Einsatzgebiete formulieren zu können, lasse ich mir hingegen wiederum gern widerlegen, wenn ich die Argumente auch in ihrer Gewichtung nachvollziehen kann.

Mal ehrlich: gerade _daß_ das Thema so kontrovers diskutiert werden kann, spricht doch eigentlich dafür, das Type-Attribut weiterhin zuzulassen, oder?

Es mag Gründe dafür oder dagegen geben, aber die bloße Tatsache, dass man darüber kontrovers diskutieren kann, sollte kein solcher sein. Wäre dem so, lönnte es auch keine politischen Reformen geben, und wenn es auch nur Kompromisse wären.

Zumal wenn Elemente wie <b> erlaubt sind.

Schuldig im Sinne der Anklage ;-)
MfG, at

[Cyx23]

Hallo,

Mir ging es nicht darum, wen auch immer zu widerlegen, sondern nur darum, aufzuzeigen, welche Lösung ich für meine Projekte gefunden habe. Dies mag kein Allheilmittel sein, aber für meine Zwecke ist es sehr brauchbar, obwohl diese Zwecke durchaus variieren. Meine Einschätzung, daraus eine Ableitung auf beliebige Einsatzgebiete formulieren zu können, lasse ich mir hingegen wiederum gern widerlegen, wenn ich die Argumente auch in ihrer Gewichtung nachvollziehen kann.

ich vermute mal dass die Grundthematik immer noch die Frage möglicher Interferenzen von Form und Inhalt ist, wobei ich sowieso diese Trennbarkeit grundsätzlich in Frage stelle, sie aber als Hilfsmittel oder Arbeitstheorie doch für sinnvoll erachte. Wenn nun hier der "Inhalt" möglichst vollständig, eindeutig usw. ins HTML soll, ergibt sich doch zunächst die Frage nach der Stimmigkeit in dem Informationscharakter von Klassen und IDs, denn da dürften die Interferenzen wieder auftauchen, und schließlich gibt es ja noch die im HTML möglichen Kommentare. Soll, kann da nun unterschieden werden zwischen inhaltlichen und technischen Kommentaren, wo kann der Autor, wo der Webmaster mal was reinschreiben?

Grüsse

Cyx23

[at]

Hallo.

Soll, kann da nun unterschieden werden zwischen inhaltlichen und technischen Kommentaren, wo kann der Autor, wo der Webmaster mal was reinschreiben?

Dazu müsste es zumindest entsprechend kenntlich gemacht werden. Aber dieses Dilemma ist der Grund für meine Abneigeung gegen "conditional comments", da dort Kommentare ohne hinreichend charakteristische Merkmale maschinell interpretiert werden. Eine Integration der Informationen in Attribute scheint mir daher sinnvoller.
MfG, at

[Cyx23]

Hallo,

Soll, kann da nun unterschieden werden zwischen inhaltlichen und technischen Kommentaren, wo kann der Autor, wo der Webmaster mal was reinschreiben?

Dazu müsste es zumindest entsprechend kenntlich gemacht werden.

<del> und <ins> sind ja wohl auch nicht ganz frei verwendbar...

Aber dieses Dilemma ist der Grund für meine Abneigeung gegen "conditional comments", da dort Kommentare ohne hinreichend charakteristische Merkmale maschinell interpretiert werden.

Bislang bin ich mit "conditional comments" in <head> zur Einbindung von Stylesheets recht zufrieden, auch wenn ich ausgefeilte CSS-Weichen einsetzen kann sind zunächst "conditional comments" vom Prinzip her schon zuverlässiger. Allerdings beruht die Funktion beim IE und zumindest Win9x offenbar auf der Abfage der Registry, und ist nur durch die schwierige Deinstallation von neueren IEs halbwegs sicher. Und die []-Klammern sind natürlich durch die IEs in Kommentaren weniger verfügbar, aber das Problem besteht ja sowieso.

Grundsätzlich sehe ich da einen Zusammenhang zur Frage ob ein minimales reduziertes HTNML wünschenswert ist, oder ob zusätzliche Hilfselemente, Container und Dummies ein kleineres Übel als CSS-Weichen sind.
Das ergibt dann womöglich '<div id="mitte"><div class="innenDiv">' statt nur '<div id="Inhalt">. Und welche Bedeutung hat ein <br style="clear both">, oder muss es besser ein <span title="Layout" style="display:block;clear:both"> </span> sein?

Eine Integration der Informationen in Attribute scheint mir daher sinnvoller.

Trotzdem dürfte ein weiterer Bedarf an Orten für zusätzliche Informationen bestehen, gerade wenn das Layout keine Informationen enthalten soll ;-) und je nach anderen Aspekten wie Barrierefreiheit gibt es vmtl. wieder Einschränkungen.

Grüsse

Cyx23

[at]

Hallo.

<del> und <ins> sind ja wohl auch nicht ganz frei verwendbar...

Das mag sein. Eine Versionskontrolle nehme ich mittels anderer Mechanismen ausserhalb des Dokumentes vor, weswegen diese Tags in meiner Schublade verstauben.

Bislang bin ich mit "conditional comments" in <head> zur Einbindung von Stylesheets recht zufrieden, auch wenn ich ausgefeilte CSS-Weichen einsetzen kann sind zunächst "conditional comments" vom Prinzip her schon zuverlässiger.

Mir stellen sich dabei eher grundsätzliche Fragen wie etwa die danach, was die Browser noch alles in Kommentaren interpretieren -- undokumentiert und heimlich.

Grundsätzlich sehe ich da einen Zusammenhang zur Frage ob ein minimales reduziertes HTNML wünschenswert ist, oder ob zusätzliche Hilfselemente, Container und Dummies ein kleineres Übel als CSS-Weichen sind.

Diesen Zusammenhang sehe ich auch, ja. Das gleiche gilt ja eigentlich für alle browser-spezifischen Angaben, etwa für die Meta-Angabe zum Abschalten der "Bilderverwertungs-Icons" im IE.

Das ergibt dann womöglich '<div id="mitte"><div class="innenDiv">' statt nur '<div id="Inhalt">. Und welche Bedeutung hat ein <br style="clear both">, oder muss es besser ein <span title="Layout" style="display:block;clear:both"> </span> sein?

Nun sind diese gewählten Elemente ja ohnehin als semantisch bedeutungsarm bis bedeutungslos einzustufen, wenn sie keine zusätzlichen Informationen innerhalb ihres Start-Tags zur Verfügung stellen, aber ein " " reichert über die Struktur hinaus auch den Inhalt mit einer Null-Information an.

Eine Integration der Informationen in Attribute scheint mir daher sinnvoller.

Trotzdem dürfte ein weiterer Bedarf an Orten für zusätzliche Informationen bestehen, gerade wenn das Layout keine Informationen enthalten soll ;-) und je nach anderen Aspekten wie Barrierefreiheit gibt es vmtl. wieder Einschränkungen.

Das ist prinzipiell sehr wahrscheinlich, unabhängig davon, dass ich nicht weiß, ob du "Layout" auf die Struktur oder die Darstellung beziehst.
Ich würde niemals behaupten wollen, die aktuellen Standards seien zufriedenstellend und vollständig schlüssig. Ich denke, darin besteht ein breiter Konsens, auch wenn man über die Details schon unter Berufung auf unterschiedliche Einsatzgebiete, Herangehens- und Denkweisen unterschiedlicher Meinung sein kann -- und fast sein muss.
MfG, at

[at]

Hallo.

sicherlich würde das hier passen. Nur wäre das m.E. doch eher ein Overkill, der sich vermeiden ließe, wenn entweder das type-Attribut im HTML die Nummerierungsart vorgibt oder man in Ermangelung dessen auf eine stimmige Ausgabe bei nur-HTML verzichtet.

Ich weiß nicht, ob du die gesamte DIskussion verfolgst, aber vielleicht hast du ja schon festgestellt, dass ich "Overkill" nicht als gültiges Gegenargument gelten lasse ;-)
MfG, at

[Orlando]

Hi Tim,

<li id="apfel">Apfel</li>
  ...
  <p>Wir nehmen <a href="#apfel" class="intern-ref"></a>
  und tun dies und das</p>

Das Ziel ist es jetzt, in CSS eine Regel zu definieren, die die (als
gegeben angenommene) Nummerierung von li#apfel einfügt. Dieses geht,
so meine ich, mit bestehender und zukünftiger Syntax von CSS nicht.

ich frage mich, ob das mit einer Kombination von nth-child() und string-set möglich wäre.

http://www.w3.org/TR/css3-selectors/#nth-child-pseudo
 http://www.w3.org/TR/css3-content/#strings

Lest ihr heraus, dass man mit string-set auch die "Variable" counter zuweisen kann?

Andererseits wäre auch folgendes vorstellbar:

p>span:after {
 content: " "counter(listenpunkt)" ";
 counter-increment: listenpunkt;
}

<p>bla... <span>Punkt</span>, danach <span>Punkt</span>, usw.</p>

Voraussetzung ist dabei natürlich, dass die Listenpunkte im erklärenden Text die gleiche Reihenfolge wie in der Liste selbst haben. Fallback ausgeschlossen...

Grüße,
 Roland

[Tim Tepaße]

Hallo Roland,

ich frage mich, ob das mit einer Kombination von nth-child() und string-set
möglich wäre.
(..)
Lest ihr heraus, dass man mit string-set auch die "Variable" counter
zuweisen kann?

Nicht unbedingt. Allerdings verstehe ich auch nicht gerade, was das bei
einer Inhaltsübernahme in die referenzierende Stelle helfen könnte.
Müßte man dann die Referenzierungen wieder als Liste aufbauen, wie in
Deinem zweiten Beispiel? Das fände ich sehr unpraktikabel.

Allerdings ist mir beim Verfolgen Deiner Links etwas aufgefallen. Ein
möglicher Wert für content() wäre dieses hier:

<target>
    Using the target expressions, authors can write cross-references.

Wenn das das ist, was ich vermute, wäre das doll. Dummerweise:

Need to write this up.

Kommt die in Puschen Jungs!

Und auch, daß string() noch nicht wirklich definiert wurde, d.h. eventuell
nicht auf benannte Namen begrenzt ist, klingt interessant.

Tim

[Thomas J.S.]

Hallo,

ich zweifle an der Vereinbarung, dass der Nummerierungstyp von geordneten Listen (ol) zur Präsentation gehört und deshalb ins Stylesheet und nicht ins Markup gehört.

Dagegen steht, dass das type-Attribut gemäß der W3C-Linie »deprecated« ist und nur Teil der Transitional-Variante ist. Stattdessen soll die CSS-Eigenschaft list-style-type, hier etwa mit dem Wert lower-latin, benutzt werden:

Rein intuitiv würde ich sagen, dass die Nummerierung stark und untrennbar zum Inhalt und nicht zur Präsentation gehört bzw. selbst Inhalt ist.

Du muss hier doch zwei dinge Trennen, einerseits gehört die Nummerierung zum inhalt, anderseits gehört die Präsentation derselben zum Stylesheet.
Es steht nirgendwo geschrieben wie ein Useragent eine nummerierte Liste darstellen soll, das W3C sagt folgendes zu ol, ul und dl: "The exact presentation of the three list types depends on the user agent."
Wir in der "westlichen" Hemisphäre fallen immer wieder gerne in die Falle, dass unsere Art zu Nummerieren oder Schreiben das einzige sei.
Dass dem nicht so ist, zeigt mittlerweile das sehr starke Interesse an  I18n (Internationalisierung). Das dürfte auch eine der Gründe sein, warum das type-Attribut depricated wurde, denn es wird so dem Useragent überlassen welche Art der Nummerirung dieser darstellt. Und ein User verwendet den wohl für ihm am besten geigneten Useragent.
Damit wäre also die rein inhaltliche Zugehörigkeit der Nummerirung zum Listeninhalt abgedeckt.
Was darüber hinausgeht, kann und sollte man mit CSS formatieren, so können Useragents, die die CSS-Angaben verstehen diese wie gewünscht Darstellen und die die diese Angaben nicht verstehen auf die Buil-in-Darstellung zurückgreifen.

Ich verstehe sehr wohl deine Dilemma in der Frage der Referenzierung von bestimmten Teilen eines Dokuments. HTML mag hier einige Lücken aufweisen, deshalb gibt es wohl solche Ideen wie H-Link oder C-Link und auch verschiedene CSS-Angaben.
Aber ich denke auch, dass solche Referenzierungen durchaus mit dem a-Element gelöst werden können (und Links sollten einen "sprechenden" Charakter haben, also nicht nur die übliche fußnotenartige Nummerierung).

Wenn ich dein Überschriftbeispiel aufgreife, sehe ich eine Grundlegende andere Fragestellung, nämlich ob du einen linearen Text wie aus Bücher gewohnt ins Internet stellen möchtest, oder einen stark vernetzen Hypertext.

Es gibt auch ältere und andere Varianten für hypertextuelle Darstellungen als HTML, wo auch solche Referenzierungen möglich sind. Ich denke Dabei an HyTime oder Xanadu.

Grüße
Thomas

[Axel Richter]

Hallo,

Es steht nirgendwo geschrieben wie ein Useragent eine nummerierte Liste darstellen soll, das W3C sagt folgendes zu ol, ul und dl: "The exact presentation of the three list types depends on the user agent."
Wir in der "westlichen" Hemisphäre fallen immer wieder gerne in die Falle, dass unsere Art zu Nummerieren oder Schreiben das einzige sei.
Dass dem nicht so ist, zeigt mittlerweile das sehr starke Interesse an  I18n (Internationalisierung). Das dürfte auch eine der Gründe sein, warum das type-Attribut depricated wurde, denn es wird so dem Useragent überlassen welche Art der Nummerirung dieser darstellt. Und ein User verwendet den wohl für ihm am besten geigneten Useragent.

Dieses Argument zieht nur, wenn Du mir zeigst, wie Kommunikation ohne Spache möglich ist. Man kann nicht _ein_ Dokument mehrsprachig anbieten, jedenfalls mit Sicherheit nicht via CSS. Man kann _mehrere_ inhaltlich ähnliche[1] Dokumente in unterschiedlichen Sprachen anbieten. Die Sprache ist kein style. Die Sprache ist Inhalt. Es reicht nicht einfach alle Wörter zu übersetzen. Genauso, wie sich der Satzbau, die Schreibrichtung, teilweise sogar die inhaltliche Aussage dem jeweiligen Sprachraum anpassen muss, muss sich eben auch das Listenformat anpassen. Ich behaupte mal, Internationalisierung in der Form: Inhaltsbeschreibung in einer Sprache -> Darstellung _dieses_ Inhalts in beliebigen anderen Sprachen, setzt eine künstliche Intelligenz voraus, die weit über die Möglichkeiten von HTML und CSS hinausgeht. Die Internationalisierung ist also eher ein Argument _für_ die Auffassung, dass der Listenstil zum Inhalt gehört.

[1]Inhaltlich gleiche Dokumente in unterschiedlichen Sprachen scheitern an unterschiedlichen semantischen Möglichkeiten und unterschiedlichen Mentalitäten in den verschiedenen Sprachräumen. Übersetze mal einen Text über Winter Schnee und Eis aus Innuit ins Deutsche ;-)). *g* Während ich das schreibe fällt mir eine sehr interessante Liste ein, die sich da ergeben könnte:

• Schnee
• Schnee
• Schnee
• Schnee

viele Grüße

Axel

[Armin G.]

Tach auch,

[1]Inhaltlich gleiche Dokumente in unterschiedlichen Sprachen scheitern an unterschiedlichen semantischen Möglichkeiten und unterschiedlichen Mentalitäten in den verschiedenen Sprachräumen. Übersetze mal einen Text über Winter Schnee und Eis aus Innuit ins Deutsche ;-)). *g* Während ich das schreibe fällt mir eine sehr interessante Liste ein, die sich da ergeben könnte:

• Schnee
• Schnee
• Schnee
• Schnee

Das sehe ich anders.

Zum ersten ist die alte Inuit/Schnee Geschichte eine "urban legend": http://www.zeit.de/stimmts/1999/199922_stimmts

Zum zweiten muesste Deine Liste irgendwie so aussehen:

• fester Schnee
• weicher Schnee
• feuchter Schnee
• verharschter Schnee
• usw usf...

Die verschiedenen Woerter (so es sie denn gibt) bezeichnen ja nicht den einen Ueberbegriff (Schnee) sondern die verschiedenen Arten.

Genau das gleiche koennte man mit ein bisschen Mutwillen ja auch fuer's Deutsche behaupten:

Die Deutschen haben massenhaft Worte fuer Brot: Butterbrot, Schwarzbrot, Mettwurstbrot, Graubrot, Toastbrot, Weissbrot, ....

Gruss,
Armin

[Axel Richter]

Hallo,

es sollte auch nur etwas auflockern ;-)). Was ich meinte hast Du aber verstanden? Es war die Rede davon, dass man die Art der Listendarstellung möglichst dem User Agenten des Nutzers überlassen sollte, weil der dem Nutzer die in seinem Sprachraum übliche Darstellung anbietet. Das hieße aber entweder, dass auch der Inhalt des Dokuments in seine Sprache übersetzt werden müsste oder, dass er meinen deutschen Inhalt mit seinen Listendarstellungen sieht. Meine Meinung ist: Wenn der Inhalt übersetzt wird, kann auch die Art der Listendarstellung mit übersetzt werden. Wenn der Nutzer aber meine deutschen Inhalte sehen will, will er unter Umständen auch meine deutsche Listendarstellung sehen. In beiden Fällen gehört der List-style zum Inhalt.

Genau das gleiche koennte man mit ein bisschen Mutwillen ja auch fuer's Deutsche behaupten:
Die Deutschen haben massenhaft Worte fuer Brot: Butterbrot,

Schwarzbrot, Mettwurstbrot, Graubrot, Toastbrot, Weissbrot, ....
             ^^^^genau!
Selbst der deutsche Sprachraum ist nicht 100%ig kompatibel.

In einem Bäckerladen:
Kunde: 5 Schrippen bitte!
Verkäuferin: Was sind Schrippen?
Kunde: Na das, was da liegt.
Verkäuferin: Das ist Weck.
Kunde: Warum? Das liegt doch da. Na egal, dann geben Sie mir 2 von den Käsebrötchen mit Gurke.
Verkäuferin: Die Halve Hahn?
Kunde: ...geht ;-))

viele Grüße ;-))

Axel

[Thomas J.S.]

Hallo Axel,

Dass dem nicht so ist, zeigt mittlerweile das sehr starke Interesse an  I18n (Internationalisierung). Das dürfte auch eine der Gründe sein, warum das type-Attribut depricated wurde, denn es wird so dem Useragent überlassen welche Art der Nummerirung dieser darstellt. Und ein User verwendet den wohl für ihm am besten geigneten Useragent.

Dieses Argument zieht nur, wenn Du mir zeigst, wie Kommunikation ohne Spache möglich ist.

Eigentlich ist deine Aussage im Bezug auf meine irrelavant, denn ich sehe nicht wo ich gesagt hätte, es wäre Kommunikation ohne Sprache möglich. Ganz im Gegenteil.

teilweise sogar die inhaltliche Aussage dem jeweiligen Sprachraum anpassen muss, muss sich eben auch das Listenformat anpassen.

Das sehe ich genau so. Und wer weiss deiner Meinung nach besser welche Nummerierung er für eine Liste sehen möchte: der, der eine Seite in seinem Useragent sieht oder der, der diese Seite ins Internet stellt und nicht weiss, wer alle und mit welchen Useragent seine Seite besucht?

Die Internationalisierung ist also eher ein Argument _für_ die Auffassung, dass der Listenstil zum Inhalt gehört.

Nur begrenzt.
Wieviele Listenstile gibt es? Und wie viele Sprachen, die nicht nach diesen Listenstilen nummerieren?

Übersetze mal einen Text über Winter Schnee und Eis aus Innuit ins Deutsche ;-)). *g* Während ich das schreibe fällt mir eine sehr interessante Liste ein, die sich da ergeben könnte:

• Schnee
• Schnee
• Schnee
• Schnee

Gutes Beispiel, auch wenn es vollkommen das von mir gesagte ignoriert.
Nehmen wir also dein Bespiel: nummeriere diese Liste mit CSS oder mit HTML nun so, dass die Nummerierung sowohl für jemanden der nur hebräisch, als auch für jemanden der nur chinesisch (mandarin), als auch für jemanden der nur deutsch spricht klar erkennbar als eine nummerierte Liste erscheint.

Grüße
Thomas

[Axel Richter]

Hallo Thomas,

teilweise sogar die inhaltliche Aussage dem jeweiligen Sprachraum anpassen muss, muss sich eben auch das Listenformat anpassen.

Das sehe ich genau so. Und wer weiss deiner Meinung nach besser welche Nummerierung er für eine Liste sehen möchte: der, der eine Seite in seinem Useragent sieht oder der, der diese Seite ins Internet stellt und nicht weiss, wer alle und mit welchen Useragent seine Seite besucht?

Wenn jemand meine deutschsprachigen Inhalte sehen will, will er wahrscheinlich auch meinen deutschen Listenstil sehen. Es würde ihn eventuell sogar stören, wenn meine deutschsprachige Liste plötzlich mit hebräischen Buchstaben versehen ist, oder gar in Textrichtung rtl verläuft, weil sein Nutzerstylesheet mein CSS überschreibt. Wenn ich Informationen in anderen Sprachen anbieten möchte, muss ich natürlich auch deren Lesebesonderheiten berücksichtigen. Allerdings sind auch hier solche inhaltlichen Besonderheiten wie Aufzählungstyp und Startwert eine Liste im Dokumentinhalt besser aufgehoben als im CSS.

Die Internationalisierung ist also eher ein Argument _für_ die Auffassung, dass der Listenstil zum Inhalt gehört.

Nur begrenzt.
Wieviele Listenstile gibt es? Und wie viele Sprachen, die nicht nach diesen Listenstilen nummerieren?

Dann gibt es zu wenige im OL bzw. UL-Element definierte Listenstile. Was könnte CSS daran ändern?

Nehmen wir also dein Bespiel: nummeriere diese Liste mit CSS oder mit HTML nun so, dass die Nummerierung sowohl für jemanden der nur hebräisch, als auch für jemanden der nur chinesisch (mandarin), als auch für jemanden der nur deutsch spricht klar erkennbar als eine nummerierte Liste erscheint.

Das HTML und CSS zur Zeit dazu nicht fähig sind, ändert nichts daran, dass eine deutschsprachige Liste mit chinesischem Listenformat auch nicht das gelbe vom Ei wäre.

viele Grüße

[Thomas J.S.]

Hallo Axel,

Wenn jemand meine deutschsprachigen Inhalte sehen will, will er wahrscheinlich auch meinen deutschen Listenstil sehen. Es würde ihn eventuell sogar stören, wenn meine deutschsprachige Liste plötzlich mit hebräischen Buchstaben versehen ist, oder gar in Textrichtung rtl verläuft, weil sein Nutzerstylesheet mein CSS überschreibt. Wenn ich Informationen in anderen Sprachen anbieten möchte, muss ich natürlich auch deren Lesebesonderheiten berücksichtigen. »»

Das ist nur bedingt richtig. Ich habe z.B. schon gerne wenn ich weiss, dass ich eine nummerierte Liste vor mir sehe. Egal ob die Sprache Deutsch oder Chinesisch ist ;-)
Das läßt schon mal einige Deutung der Textes zu, auch wenn ich die Sprache wenig oder vielleicht gar nicht beherrsche.
Wenn du dem Useragent die Listerdarstellung überläßt, stellt es die Listennummer so dar, dass der User dieser versteht und wenn sein Useragent CSS unterstüzt und es einen entsprechenden Listenstil gibt, kann man ja die Liste durchaus entsprechend formatieren.

Wieviele Listenstile gibt es? Und wie viele Sprachen, die nicht nach diesen Listenstilen nummerieren?
Dann gibt es zu wenige im OL bzw. UL-Element definierte Listenstile. Was könnte CSS daran ändern?

Wenig, deshalb sollte man das eher dem Useragent überlassen. Wir reden ja hier über die "depricating" des type-Attributes.

Das HTML und CSS zur Zeit dazu nicht fähig sind, ändert nichts daran, dass eine deutschsprachige Liste mit chinesischem Listenformat auch nicht das gelbe vom Ei wäre.

Das ist ansichtsache und sicherlich von User zu User unterschiedlich ;-)

Grüße
Thomas

[Tim Tepaße]

Hallo Axel,

Das HTML und CSS zur Zeit dazu nicht fähig sind, (...)

Mh? Mal so aus dem Ärmer geschüttelt:

*[lang|=de] li {list-style-type:lower-latin;}
*[lang|=he] li {list-style-type:hebrew;}
*[lang|=zh] li {list-style-type:cjk-ideographic;}

Tim

[at]

Hallo.

*[lang|=de] li {list-style-type:lower-latin;}
*[lang|=he] li {list-style-type:hebrew;}
*[lang|=zh] li {list-style-type:cjk-ideographic;}

Interessant.
MfG, at

[Axel Richter]

Hallo Axel,

Das HTML und CSS zur Zeit dazu nicht fähig sind, (...)

Mh? Mal so aus dem Ärmer geschüttelt:

*[lang|=de] li {list-style-type:lower-latin;}
*[lang|=he] li {list-style-type:hebrew;}
*[lang|=zh] li {list-style-type:cjk-ideographic;}

Danke für den Hinweis. Soweit hatte ich gar nicht überlegt. Trotzdem, was ist der Vorteil davon, das zum Stil zu erkären und ins CSS auszulagern, statt das type-Attribut bei OL weiterzuentwickeln? Das schon gebrachte Argument, der Nutzer möchte vielleicht eine englischsprachige Liste in Hiragana oder Katakana-Aufzählung sehen und ggf. hören, überzeugt mich nicht so ganz. Ich bin weiterhin der Meinung, der Listentyp gehört unmittelbar zur Spache und somit zum Inhalt des Dokuments. Sonst kann wirklich Sinngehalt des Inhalts verloren gehen, wenn im der Liste folgenden englischsprachigen Text z.B. auf den Punkt d Bezug genommen wird, der Nutzer aber nur die Punkte a, i, u, e, o, ka, ki sieht bw. gehört hat. Gut, auch das könnte man mit CSS-generated-content eventuell lösen, aber welchen Sinn hat das?

viele Grüße

Axel

[at]

Hallo.

Ich bin weiterhin der Meinung, der Listentyp gehört unmittelbar zur Spache und somit zum Inhalt des Dokuments. Sonst kann wirklich Sinngehalt des Inhalts verloren gehen, wenn im der Liste folgenden englischsprachigen Text z.B. auf den Punkt d Bezug genommen wird, der Nutzer aber nur die Punkte a, i, u, e, o, ka, ki sieht bw. gehört hat. Gut, auch das könnte man mit CSS-generated-content eventuell lösen, aber welchen Sinn hat das?

Und welchen Sinn hat es, sich auf Aufzählungszeichen, die sich mitunter im Verlauf eines Projektes mehrfach ändern können, zu beziehen, statt auf die beschriebenen Inhalte?
MfG, at

[Thomas J.S.]

Hallo Axel,

*[lang|=de] li {list-style-type:lower-latin;}
*[lang|=he] li {list-style-type:hebrew;}
*[lang|=zh] li {list-style-type:cjk-ideographic;}

Danke für den Hinweis. Soweit hatte ich gar nicht überlegt. Trotzdem, was ist der Vorteil davon, das zum Stil zu erkären und ins CSS auszulagern, statt das type-Attribut bei OL weiterzuentwickeln?

<ol type="lower-latin" type="hebrew" lang="de" lang="he">??
 oder wie. Verstehst du es jetzt, was auch ich meinte?

»»Ich bin weiterhin der Meinung, der Listentyp gehört unmittelbar zur Spache und somit zum Inhalt des Dokuments. Sonst kann wirklich Sinngehalt des Inhalts verloren gehen, wenn im der Liste folgenden englischsprachigen Text z.B. auf den Punkt d Bezug genommen wird,

Das ist der Fehler: du solltest nicht auf Punkt "d" Bezug nehmen, sonder auf den eigentlichen Inhalt, der sich unter Punkt d befindet.
Das sit das was ich vorher in diesem Thread mit "Link mit sprechenden Charakter" bezeichnet habe.
Ich weisst, dass es einfacher ist ein "wie unter Punk 'd' erwähnt ..." zu schreiben, als "wie unter dem Punk 'Käsekuchen' erwähnt ..."

Aber Punkt "d" bleibt nicht zwangsläufig immer Punkt "d"! Wenn du aber den Text als solches referenzierst hast du kein Problem damit den Text wo anders hinzustellen.

(gut, natürlich kann man hier einwenden, dass ein Käsekuchen auch bald vergammelt, aber ... ;-) )

Grüße
Thomas

[Axel Richter]

Hallo Thomas,

Danke für den Hinweis. Soweit hatte ich gar nicht überlegt. Trotzdem, was ist der Vorteil davon, das zum Stil zu erkären und ins CSS auszulagern, statt das type-Attribut bei OL weiterzuentwickeln?

<ol type="lower-latin" type="hebrew" lang="de" lang="he">??
 oder wie. Verstehst du es jetzt, was auch ich meinte?

Eben _so_ nicht. In welcher Sprache willst Du die Inhalt der LI-Elemente formulieren? Davon würde das type-Attribut abhängen, also _entweder_ _oder_. Meine Frage wa ja gerade: Was sollen hebräische Auflistungsnummerierungen in einer deutschsprachigen Liste ür enen Sinn haben?

<ol type="lower-alpha" lang="de">
 <li>hier deutsche Listenpunkte</li>
 <li>hier deutsche Listenpunkte</li>
 <li>hier deutsche Listenpunkte</li>
<ol>

<ol type="hebrew" lang="he">
 <li>hier hebräische Listenpunkte</li>
 <li>hier hebräische Listenpunkte</li>
 <li>hier hebräische Listenpunkte</li>
<ol>

Ich weisst, dass es einfacher ist ein "wie unter Punk 'd' erwähnt ..." zu schreiben, als "wie unter dem Punk 'Käsekuchen' erwähnt ..."

Ja, aber wie sehen dann Bezugnahmen auf Listen mit mehreren Ebenen aus? "Wie in der Auflistung <Kuchen>Kuchen[link] bei <Kuchen_ohne_Sahne>Kuchen ohne Sahne[link] unter <Käsekuchen>Käsekuchen[link] erwähnt ..."

Aber Punkt "d" bleibt nicht zwangsläufig immer Punkt "d"!

Doch. Solange sich der Dokumentinhalt nicht ändert, gibt es eben keinen Grund, warum aus Punkt d etwas anderes werden sollte. Wenn sich der Dokumentinhalt ändert, muss man ohnehin auch die Bezugnahmen überprüfen.

viele Grüße

Axel

[Thomas J.S.]

Hallo Axel,

Meine Frage wa ja gerade: Was sollen hebräische Auflistungsnummerierungen in einer deutschsprachigen Liste ür enen Sinn haben?

Z.B. Zitate. (das habe ich auch schon selbst gemacht) Es gibt viele Möglichkeiten.

Ja, aber wie sehen dann Bezugnahmen auf Listen mit mehreren Ebenen aus? "Wie in der Auflistung <Kuchen>Kuchen[link] bei <Kuchen_ohne_Sahne>Kuchen ohne Sahne[link] unter <Käsekuchen>Käsekuchen[link] erwähnt ..."

Das war jetzt aber absichtlich, oder?

Aber Punkt "d" bleibt nicht zwangsläufig immer Punkt "d"!
Doch.

Ist mir auch recht, ich sehe ein hier kommen wir nicht mehr weiter.

nicht desto trotz
Viele Grüße
Thomas

[at]

Hallo.

Ja, aber wie sehen dann Bezugnahmen auf Listen mit mehreren Ebenen aus? "Wie in der Auflistung <Kuchen>Kuchen[link] bei <Kuchen_ohne_Sahne>Kuchen ohne Sahne[link] unter <Käsekuchen>Käsekuchen[link] erwähnt ..."

Das Problem an deinem Beispiel ist, dass die Sprache missverständlich ist, indem man die Verschachtelung genau umgekehrt auffassen kann. Außerdem ist es unzureichend, da ich problemlos formulieren kann: "Wie beim <Käsekuchen>Käsekuchen[link] erwähnt, ..." Denn ein Käsekuchen gehört eben immer in nur diese eine Kategorie/Unterkategorie. Und selbst wenn ich argumentiere, es könne auch Käsekuchen _mit_ Sahne geben, der dann natürlich in der entsprechenden Liste auftauchen müsste, ziehe ich die beiden Kategorien eben zu "Wie beim <Käsekuchen>Käsekuchen[link] <Kuchen_ohne_Sahne>ohne Sahne[link] erwähnt, ..." zusammen. Wenn ich unbedingt noch "<Kuchen>" unterbringen will, kann ich dies bewerkstelligen, indem ich formuliere: "Wie beim <Kuchen>Kuchen[link] '<Käsekuchen>Käsekuchen[link] <Kuchen_ohne_Sahne>ohne Sahne[link]' erwähnt, ..." Dies ist zwar im konkreten Beispiel eine seltsame Formulierung, aber dieser Eindruck entsteht ja nur aus der bekannten Tatsache, dass "Käsekuchen ohne Sahne" ja immer und ausschließlich ein Kuchen ist. In einem anderen Beispiel sähe dies gegebenfalls anders aus.
Anders sieht es aus, wenn es bunter mischbar wird: Angenommen ich habe Dreiecke, Quadrate und Kreise, jeweils in rot, blau und gelb, und diese dann in klein und groß (also insgesamt 3 x 3 x 2 = 18 unterschiedliche Elemente), so kann ich mich doch problemlos auf "kleine rote Dreiecke" beziehen und diese ensprechend referenzieren: "<kleine_rote_Dreicke>kleine[link] <rote_Dreiecke>rote[link] <Dreiecke>Dreiecke[link]"
Vielleicht ist Sprache mächtiger als du denkst ;-)

Doch. Solange sich der Dokumentinhalt nicht ändert, gibt es eben keinen Grund, warum aus Punkt d etwas anderes werden sollte. Wenn sich der Dokumentinhalt ändert, muss man ohnehin auch die Bezugnahmen überprüfen.

Aber es bleibt dabei, dass du damit im Änderungsfall ein Problem hast, welches von vornherein vermeidbar und gleichzeitig besser semantisch strukturiert wäre. "Mach doch mal aus Punkt 'b)' Punkt 'c)' und aus Punkt 'c)' -- dem alten natürlich, also dem, welcher vor der letzten Änderung noch 'b)' hieß, -- Punkt 'd)'." ist eben komplizierter als "Mach doch mal eine 'Gebäck'-Liste und stelle die ganzen 'Kuchen' dort hinein -- aber nix aufessen ;-)".
MfG, at

[at]

Hallo.

Wenn ich dein Überschriftbeispiel aufgreife, sehe ich eine Grundlegende andere Fragestellung, nämlich ob du einen linearen Text wie aus Bücher gewohnt ins Internet stellen möchtest, oder einen stark vernetzen Hypertext.

Ich bin inzwischen dazu übergangen, stark strukturiert und unter fast ausuferndem Einsatz von Verweisen zu schreiben, diese aber aus Gründen der Gewöhnung teilweise mittels CSS zu enschärfen, indem etwa Listen linearisiert oder gar Links nicht gekennzeichnet werden.
MfG, at

[molily]

Ich bin inzwischen dazu übergangen, stark strukturiert und unter fast ausuferndem Einsatz von Verweisen zu schreiben, diese aber aus Gründen der Gewöhnung teilweise mittels CSS zu enschärfen, indem etwa Listen linearisiert oder gar Links nicht gekennzeichnet werden.

Für wen zeichnest du dann aus? Für die Screenreaderbenutzer, damit sie die Listenpunkte einzeln durchspringen können (das können sie in fließendem Text im Prinzip auch) und darauf hingewiesen werden, dass es sich um eine Aufzählung handelt? Oder nur für dich, um die gedanklichen Bezüge festzuhalten? Und wem soll der Link dienen, wenn er nicht als solcher gekennzeichnet ist und folglich seine Aufgabe nie erfüllen wird?

Das erscheint mir ungefähr so praktisch relevant wie das Einfügen von Metadaten, cite-, datetime- und bspw. hreflang-Attributen. Es mag einen gewissen Sinn haben, aber in der Regel profitiert der Leser kein bisschen davon. Und wenn der im Code vorhandene semantische Mehrwert nicht nur nicht kommuniziert wird, weil der Browser diese Inhalte nicht oder nicht angemessen zugänglich macht, sondern weil der Autor dies aktiv verhindert, kann nicht mehr von Mehrwert gesprochen werden. Ich sehe nicht, wie der Autor seinerseits von der Auszeichnung jeder Aufzählung als ul-Liste profitiert, bei Metadaten, cite und datetime sehe ich zumindest Vorteile für den Autor, selbst wenn das alleine nicht befriedigt. Von der Schwierigkeit, eine Liste interoperabel zu linearisieren, mal ganz abgesehen.

[at]

Hallo.

Für wen zeichnest du dann aus? Für die Screenreaderbenutzer, damit sie die Listenpunkte einzeln durchspringen können (das können sie in fließendem Text im Prinzip auch) und darauf hingewiesen werden, dass es sich um eine Aufzählung handelt? Oder nur für dich, um die gedanklichen Bezüge festzuhalten?

Eher letzteres, aber ich füge dem Leser damit ja auch keinen Schaden zu.

Und wem soll der Link dienen, wenn er nicht als solcher gekennzeichnet ist und folglich seine Aufgabe nie erfüllen wird?

Ich verwende beispielsweise <abbr> zur Kennzeichnung des Sachverhaltes, dass es sich um eine Abkürzung handelt. Aber ich mich bei "USt.-ID" oder "MDStV." auch zu einer visuellen Kennzeichnung hinreißen lassen, da ich dem Leser so eine unter Umständigen wichtige Information darbiete, verzichte ich bei "PLZ" und "ISDN" darauf. Dieser Verzicht ändert aber nichts daran, dass es sich ebenfalls um Abkürzungen handelt, die ich prinzipiell mit <abbr> auszeichne.

Das erscheint mir ungefähr so praktisch relevant wie das Einfügen von Metadaten, cite-, datetime- und bspw. hreflang-Attributen.

Dann lasse es sein. Mich stört das sicher nicht.

Es mag einen gewissen Sinn haben, aber in der Regel profitiert der Leser kein bisschen davon.

Wenn ich wüsste, dass du mein einziger Leser wärst, würde ich es wahrscheinlich auch lassen.

Und wenn der im Code vorhandene semantische Mehrwert nicht nur nicht kommuniziert wird, weil der Browser diese Inhalte nicht oder nicht angemessen zugänglich macht, sondern weil der Autor dies aktiv verhindert, kann nicht mehr von Mehrwert gesprochen werden.

Im Gegenteil: Indem ich nicht irgendwelche nichtssagenden Indizes ("a)", "[7]") und ellenlange komma-getrennte Wortreihen fabriziere, sondern Informationen strukturiere und zueinander in Bezug setze, wird die Zugänglichkeit meines Erachtens erhöht. Wer einmal komma-separierte Listen auf einem Handy-Display durchsuchen musste, wird dies vielleicht ebenfalls so sehen. Und auch die nichtssagenden Indizes funktionieren nur dann, wenn man die Begriffe noch im Augenwinkel sehen kann -- "Was war nochmal 'a)'?" *scroll* *scroll* *scroll* "ah, ja: 'Äpfel, Bananen, Orangen' ;-)

Ich sehe nicht, wie der Autor seinerseits von der Auszeichnung jeder Aufzählung als ul-Liste profitiert, bei Metadaten, cite und datetime sehe ich zumindest Vorteile für den Autor, selbst wenn das alleine nicht befriedigt. Von der Schwierigkeit, eine Liste interoperabel zu linearisieren, mal ganz abgesehen.

Die Linearisierung entspricht nur einem Zugeständnis an die alten Konventionen des Papier-Zeitalters und ist daher verzichtbar.
Mit Metadaten kann ich übrigens sehr sparsam sein, da ich diese Informationen ja zum großen Teil innerhalb der inhaltlichen Struktur unterbringen kann. <cite> verwende ich selten und "datetime" ist mir kein Begriff.
MfG, at

[molily]

Für wen zeichnest du dann aus? Für die Screenreaderbenutzer, damit sie die Listenpunkte einzeln durchspringen können (das können sie in fließendem Text im Prinzip auch) und darauf hingewiesen werden, dass es sich um eine Aufzählung handelt? Oder nur für dich, um die gedanklichen Bezüge festzuhalten?

Eher letzteres, aber ich füge dem Leser damit ja auch keinen Schaden zu.

Ich denke doch, ich halte Fließtext, wie er aus linearen Texten bekannt ist, in solchen Fällen für intuitiver als überall, wo möglich, Listen einzufügen und bei jedem Bezug Querverweise zu setzen. Mit der technischen Machbarkeit ist es wie gesagt auch nicht weit her, aber dir geht es ja nicht um Zuverlässigkeit.

Und wem soll der Link dienen, wenn er nicht als solcher gekennzeichnet ist und folglich seine Aufgabe nie erfüllen wird?

Ich verwende beispielsweise <abbr> zur Kennzeichnung des Sachverhaltes, dass es sich um eine Abkürzung handelt. Aber ich mich bei "USt.-ID" oder "MDStV." auch zu einer visuellen Kennzeichnung hinreißen lassen, da ich dem Leser so eine unter Umständigen wichtige Information darbiete, verzichte ich bei "PLZ" und "ISDN" darauf.

Das verstehe ich, doch muss man dann strenggenommen feststellen, dass diese Auszeichnung keinen mehr Zweck verfolgt, außer sich selbst zu genügen, davon abgesehen, dass sowohl der mit CSS unkenntlich gemachte Querverweise als auch die nicht gekennzeichnete Abkürzung etwa für Screenreaderbenutzer nützlich sein können.

Dieser Verzicht ändert aber nichts daran, dass es sich ebenfalls um Abkürzungen handelt, die ich prinzipiell mit <abbr> auszeichne.

Schade, dass du nicht davon überzeugt werden kannst, dir Gedanken über die praktische Nützlichkeit zu machen und anscheinend nur aus rein logisch-semantischen Gründen auszeichnest, ohne dass sich Wirkungen oder gar positive Wirkungen feststellen lassen.

Das erscheint mir ungefähr so praktisch relevant wie das Einfügen von Metadaten, cite-, datetime- und bspw. hreflang-Attributen.

Dann lasse es sein. Mich stört das sicher nicht.

Es ging nicht darum, was irgendjemand persönlich für vorteilhaft hält, sondern ob und wie sich dieser Vorteil auf die Gesamtheit übertragen lässt. Wie ich es selbst handhabe, stand nicht zur Debatte und war nicht Teil meiner Aussage.

Es mag einen gewissen Sinn haben, aber in der Regel profitiert der Leser kein bisschen davon.

Wenn ich wüsste, dass du mein einziger Leser wärst, würde ich es wahrscheinlich auch lassen.

Dann müssten nichtsdestoweniger andere Leser existieren, die profitieren, und das stellte ich in Zweifel bzw. bezeichne sie als einer winzigen Gruppe angehörig, was m.M.n. nicht zufriedenstellen kann.

Und wenn der im Code vorhandene semantische Mehrwert nicht nur nicht kommuniziert wird, weil der Browser diese Inhalte nicht oder nicht angemessen zugänglich macht, sondern weil der Autor dies aktiv verhindert, kann nicht mehr von Mehrwert gesprochen werden.

Im Gegenteil: Indem ich nicht irgendwelche nichtssagenden Indizes ("a)", "[7]") und ellenlange komma-getrennte Wortreihen fabriziere,

Niemand hat von »ellenlangen« Aufzählungen gesprochen und warum überhaupt nichtssagende Indizes ins Spiel gekommen sind, habe ich bereits dargelegt.

sondern Informationen strukturiere und zueinander in Bezug setze, wird die Zugänglichkeit meines Erachtens erhöht.

Mein Posting bezog sich (nur) darauf, dass du Markup einsetzt und dann alles darab setzt, zu verhindern, dass die Auszeichnung auch in der gewohnten Form bzw. überhaupt in einer die Bedeutung wiedergebenden Form beim Leser ankommt.

HTML ist meinem Verständnis nach zu einem großen Teil nicht so abstrakt-theoretisch, wie wir hier damit umgehen, und orientiert sich an konkreten bekannten Textstrukturen. Das ist sicher das pragmatische Extrem, auf der anderen Seite steht das auf ebenso extreme Weise von jeglichen »natürlichen« Strukturdarstellungen entkoppelte Ansicht, dass HTML in erster Linie als formale Logiksprache einzusetzen sei und das vertraute Erscheinungsbild erst durch CSS hinzuzufügen sei.

Wer einmal komma-separierte Listen auf einem Handy-Display durchsuchen musste, wird dies vielleicht ebenfalls so sehen. Und auch die nichtssagenden Indizes funktionieren nur dann, wenn man die Begriffe noch im Augenwinkel sehen kann -- "Was war nochmal 'a)'?" *scroll* *scroll* *scroll* "ah, ja: 'Äpfel, Bananen, Orangen' ;-)

Ich hatte nie vor, das Querverlinken an sich anzuzweifeln. Im Gegenteil, ich fragte mich, wieso du solche m.E. wertvollen Informationen in Form von Querverweisen einfügst, diese dann aber unkenntlich machst, sodass letztlich die meisten Benutzer nichts davon mitbekommen - von dem die Wirklichkeitsverhältnisse verzerrenden Beispiel des Handys abgesehen, schließlich »optimiert« man das Markup nicht hauptsächlich für eine diese Promillegruppe.

Ich sehe nicht, wie der Autor seinerseits von der Auszeichnung jeder Aufzählung als ul-Liste profitiert, bei Metadaten, cite und datetime sehe ich zumindest Vorteile für den Autor, selbst wenn das alleine nicht befriedigt. Von der Schwierigkeit, eine Liste interoperabel zu linearisieren, mal ganz abgesehen.

Die Linearisierung entspricht nur einem Zugeständnis an die alten Konventionen des Papier-Zeitalters und ist daher verzichtbar.

Die Konventionen des Papierzeitalters haben ihren berechtigten Sinn und sind keine willkürlichen Phantasieprodukte. Ich sehe in der konventionellen Strukturierung mehr Vorteile hinsichtlich Informationsaufnahme und Verständnis, daher leuchtet mir nicht ein, warum diese Konventionen im Hypertextzeitalter überwunden werden sollten, nur weil sie alt sind, wo sie sich im Hypertext m.E. ebenfalls weitesgehend bewährt haben.

Mit Metadaten kann ich übrigens sehr sparsam sein, da ich diese Informationen ja zum großen Teil innerhalb der inhaltlichen Struktur unterbringen kann.

Ja, aber niemals mit derselben expliziten Semantik. <meta name="author" content="at"> ist etwas anderes als <p>Autor: at</a>, <meta name="DC.Modified" scheme="w3cdtf" content="2003-12-16"> ist etwas anderes als <p>Letzte Änderung: 16.12.2003</p> und so weiter.

[at]

Hallo.

Ich denke doch, ich halte Fließtext, wie er aus linearen Texten bekannt ist, in solchen Fällen für intuitiver als überall, wo möglich, Listen einzufügen und bei jedem Bezug Querverweise zu setzen.

Ich fand listenförmige Aufzählungen schon immer besser handhabbar als Textblöcke. Und wenn ich mir die Notizen und Skripte von Studenten und Dozenten, aber auch Kollegen und Kunden um mich herum ansehe, sind diese in den seltensten Fällen unstrukturierte Bleiwüsten, sondern meist listenförmig aufgebaut.

Mit der technischen Machbarkeit ist es wie gesagt auch nicht weit her, aber dir geht es ja nicht um Zuverlässigkeit.

Die technische Machbarkeit ist ja nur hinsichtlich der nachträglichen Linearisierung limitiert, und damit kann ich tatsächlich gut leben.

Ich verwende beispielsweise <abbr> zur Kennzeichnung des Sachverhaltes, dass es sich um eine Abkürzung handelt. Aber ich mich bei "USt.-ID" oder "MDStV." auch zu einer visuellen Kennzeichnung hinreißen lassen, da ich dem Leser so eine unter Umständigen wichtige Information darbiete, verzichte ich bei "PLZ" und "ISDN" darauf.

Das verstehe ich, doch muss man dann strenggenommen feststellen, dass diese Auszeichnung keinen mehr Zweck verfolgt, außer sich selbst zu genügen, davon abgesehen, dass sowohl der mit CSS unkenntlich gemachte Querverweise als auch die nicht gekennzeichnete Abkürzung etwa für Screenreaderbenutzer nützlich sein können.

Und das ist nichts? Damit kann ich Metadaten teilweise sehr praktisch ersetzen.

Schade, dass du nicht davon überzeugt werden kannst, dir Gedanken über die praktische Nützlichkeit zu machen und anscheinend nur aus rein logisch-semantischen Gründen auszeichnest, ohne dass sich Wirkungen oder gar positive Wirkungen feststellen lassen.

Die positiven Auswirkunegn hast du selbst gerade eben noch eingeräumt. Die praktische Nützlichkeit ist für mich jedoch kein strukturelle Problem, sondern eines der Darstellung -- und als solches löse ich es mittels CSS.

Es ging nicht darum, was irgendjemand persönlich für vorteilhaft hält, sondern ob und wie sich dieser Vorteil auf die Gesamtheit übertragen lässt. Wie ich es selbst handhabe, stand nicht zur Debatte und war nicht Teil meiner Aussage.

Dann hatte ich dich falsch verstanden, entschuldige bitte.

Dann müssten nichtsdestoweniger andere Leser existieren, die profitieren, und das stellte ich in Zweifel bzw. bezeichne sie als einer winzigen Gruppe angehörig, was m.M.n. nicht zufriedenstellen kann.

Mich stellt es durchaus zufrieden, die Leute zu erreichen, die ich erreichen möchte oder muss. Dass du nicht dazu gehörst ist zwar wirklich bedauerlich, aber letztlich eine Umstellung bzw. Reduzierung der Struktur auf Kosten derer, die ich bisher anspreche, nicht wert.

Niemand hat von »ellenlangen« Aufzählungen gesprochen und warum überhaupt nichtssagende Indizes ins Spiel gekommen sind, habe ich bereits dargelegt.

Aber ab wann wird eine Aufzählung ellenlang? Ich ziehe diese Grenze lediglich mittels CSS, so dass man sogar zwischen unterschiedlichen Darstellungen wechseln und die einem selbst genehme dann beibehalten kann.

Mein Posting bezog sich (nur) darauf, dass du Markup einsetzt und dann alles darab setzt, zu verhindern, dass die Auszeichnung auch in der gewohnten Form bzw. überhaupt in einer die Bedeutung wiedergebenden Form beim Leser ankommt.

Du machst dir doch die gleichen Gedanken, nur mit dem Unterschied, dass du die Darstellung in der Struktur tiefer verankerst, während ich die Darstellung möglichst weitgehend von der Struktur trenne.

HTML ist meinem Verständnis nach zu einem großen Teil nicht so abstrakt-theoretisch, wie wir hier damit umgehen, und orientiert sich an konkreten bekannten Textstrukturen.

Und die darf man deshalb nicht analysieren und deren Zweck und Nutzen hinterfragen? Das hast du zwar nicht gesagt, aber nur so kann ich diese Aussage interpretieren.

Das ist sicher das pragmatische Extrem, auf der anderen Seite steht das auf ebenso extreme Weise von jeglichen »natürlichen« Strukturdarstellungen entkoppelte Ansicht, dass HTML in erster Linie als formale Logiksprache einzusetzen sei und das vertraute Erscheinungsbild erst durch CSS hinzuzufügen sei.

Ich empfinde Fließtext zwar nicht zwangsläufiger als "natürlicher", aber ich gebe dir natürlich Recht, dass wir uns hier zwischen zwei Extremen bewegen.

Ich hatte nie vor, das Querverlinken an sich anzuzweifeln. Im Gegenteil, ich fragte mich, wieso du solche m.E. wertvollen Informationen in Form von Querverweisen einfügst, diese dann aber unkenntlich machst, sodass letztlich die meisten Benutzer nichts davon mitbekommen - von dem die Wirklichkeitsverhältnisse verzerrenden Beispiel des Handys abgesehen, schließlich »optimiert« man das Markup nicht hauptsächlich für eine diese Promillegruppe.

Das ist doch genau der Punkt. Ich "optimiere" das Markup überhaupt nicht auf ein bestimmtes Ausgabegerät hin, sondern generiere ein unverselles Markup. Dass dieser Ansatz einer vermeintlichen Randgruppe auch sehr entgegenkommt, wirkt auf mich daher vielmehr symptomatisch.
Das Unkenntlichmachen einzelner Elemente ist im Übrigen kaum etwas anderes als das "Tarnen von Listen durch das Integrieren derer Inhalte in den Textfluss unter Zuhilfenahme von Kommata. Nur -- ich wiederhole mich -- findet dies bei mir eben auf einer anderen Ebene statt, die darüber hinaus jeder Nutzer seinen Bedürfnissen anpassen kann, wenn er dies wünscht.

Die Konventionen des Papierzeitalters haben ihren berechtigten Sinn und sind keine willkürlichen Phantasieprodukte.

Sie haben auch heute noch sehr viel Sinn für bedrucktes Papier, aber in vielen Fällen sehr viel weniger in Hypertext-Medien.

Ich sehe in der konventionellen Strukturierung mehr Vorteile hinsichtlich Informationsaufnahme und Verständnis, daher leuchtet mir nicht ein, warum diese Konventionen im Hypertextzeitalter überwunden werden sollten, nur weil sie alt sind, wo sie sich im Hypertext m.E. ebenfalls weitesgehend bewährt haben.

Das hat mit dem Alter zunächst wenig zu tun, aber Papier ist eben ein seit verhöltnismäßig langer Zeit verwendeter Informationsträger. Und hätte er früher die Möglichkeiten geboten, die Hypertext-Medien heute bieten, wären mit hoher Wahrscheinlichkeit auch diese Konvetionen andere -- ein "siehe a)" hätte man sicher schon immer gern durch einen echten Verweis ersetzt.

Mit Metadaten kann ich übrigens sehr sparsam sein, da ich diese Informationen ja zum großen Teil innerhalb der inhaltlichen Struktur unterbringen kann.

Ja, aber niemals mit derselben expliziten Semantik. <meta name="author" content="at"> ist etwas anderes als <p>Autor: at</a>, <meta name="DC.Modified" scheme="w3cdtf" content="2003-12-16"> ist etwas anderes als <p>Letzte Änderung: 16.12.2003</p> und so weiter.

Keine Frage, da hast du natürlich Recht. Aber genau _diese_ Angaben verwende ich auch nach wie vor, entschuldige bitte die Ungenauigkeit. Ich bezog mich auf Schlüsselwörter und Inhaltsangaben, die ich ja bereits explizit im Quelltext stehen habe.
MfG, at

[molily]

Ich verstehe sehr wohl deine Dilemma in der Frage der Referenzierung von bestimmten Teilen eines Dokuments. HTML mag hier einige Lücken aufweisen, deshalb gibt es wohl solche Ideen wie H-Link oder C-Link und auch verschiedene CSS-Angaben.
Aber ich denke auch, dass solche Referenzierungen durchaus mit dem a-Element gelöst werden können (und Links sollten einen "sprechenden" Charakter haben, also nicht nur die übliche fußnotenartige Nummerierung).

Ja, darin stimme ich dir zu. Mein Dilemma ist letztlich das eigene Unvermögen, dass ich für das Referenzierte aufgrund seiner Vielheit, Vielfältigkeit und Komplexität keine annähernd gleichwertige Bezeichnung finde, die in ihrer Fülle und gleichzeitig in ihrer Begrenztheit die Inhalte der Listenelemente angemessen wiedergibt (eben »spricht«), und deshalb statt <dt>Bezeichnung</dt> und <th>Bezeichnung</th> mich in ein vorgegebenes Bezeichnungsschema flüchte. Sicherlich bestünde die Möglichkeit, nach Analogien zu suchen, so schräg sie auch sein mögen. Davon, die Bedeutung über ein vorhandenes Wort herzuleiten, dessen landläufige Bedeutung sich vielleicht auf einen Hauptaspekt übertragen ließe, im Allgemeinen aber keine Verbindung zum Bezeichneten besteht, halte ich aber wenig bzw. sehe wenig Nutzen für den Leser, der die Bezeichnung für genauso willkürlich hält wie »A« oder »X«.

Wenn ich dein Überschriftbeispiel aufgreife, sehe ich eine Grundlegende andere Fragestellung, nämlich ob du einen linearen Text wie aus Bücher gewohnt ins Internet stellen möchtest, oder einen stark vernetzen Hypertext.

Strenggenommen handelt der gesamt Thread von starren Sequenzen und Hierarchien, wir orientierten uns allesamt an der Buchmetapher. Das so entstehende Gewebe ist in seiner Struktur wenig »hyper«, somit wäre selbst ein streng linearer Text mit starker Herausarbeitung der internen Bezüge durch Querverweise letztlich kein entfesselter Hypertext.

[Thomas J.S.]

Hallo Mathias,

Mein Dilemma ist letztlich das eigene Unvermögen, dass ich für das Referenzierte aufgrund seiner Vielheit, Vielfältigkeit und Komplexität keine annähernd gleichwertige Bezeichnung finde, die in ihrer Fülle und gleichzeitig in ihrer Begrenztheit die Inhalte der Listenelemente angemessen wiedergibt (eben »spricht«), und deshalb statt <dt>Bezeichnung</dt> und <th>Bezeichnung</th> mich in ein vorgegebenes Bezeichnungsschema flüchte.

Was wolltest du damit sagen?
Außer dass du dir wiedersprichst? ;-)

Sicherlich bestünde die Möglichkeit, nach Analogien zu suchen, so schräg sie auch sein mögen.

Analogien für was?

Davon, die Bedeutung über ein vorhandenes Wort herzuleiten, dessen landläufige Bedeutung sich vielleicht auf einen Hauptaspekt übertragen ließe, im Allgemeinen aber keine Verbindung zum Bezeichneten besteht, halte ich aber wenig bzw. sehe wenig Nutzen für den Leser, der die Bezeichnung für genauso willkürlich hält wie »A« oder »X«.

Wir sprechen hier immer noch über nummerierte Listen?

Strenggenommen handelt der gesamt Thread von starren Sequenzen und Hierarchien, wir orientierten uns allesamt an der Buchmetapher. Das so entstehende Gewebe ist in seiner Struktur wenig »hyper«, somit wäre selbst ein streng linearer Text mit starker Herausarbeitung der internen Bezüge durch Querverweise letztlich kein entfesselter Hypertext.

Das sehe ich ähnlich, wobei ich mich vorher eher auf die durchnummerierung von Überschriften und Unter-Überschriften etc. bezog.

Grüße
Thomas

[Cyx23]

Hallo Mathias,

ich zweifle an der Vereinbarung, dass der Nummerierungstyp von geordneten Listen (ol) zur Präsentation gehört und deshalb ins Stylesheet und nicht ins Markup gehört.

auch wenn ich deine Frage nicht verwässern möchte, ist dennoch ein Grundproblem die m.E. falsche Vorstellung eines klar trennbaren Inhalts.

Diese Trennung lässt sich wohl begünstigen mit <ul><li>1., vgl. [pref:t=66463&m=380106], Bedarf nach einer solchen Trennung scheint ja auch zu bestehen, aber dennoch sollte auch die Unmöglichkeit oder Unvollständigkeit, ggf. Missverständlichkeit einer solchen Trennung hinreichend bedacht werden.

Zumindest muss wie du ja auch schon überlegt hast die starke inhaltliche Bedeutung von CSS bedacht werden.

Hinzu kommt die Frage nach m.E. bestehenden Vorteilen bei stark reduziertem HTML, welches natürlich wieder mehr CSS und Klassen statt zusätzlicher <div>s und <span> enthält.

Ähnlich wie die mögliche Tabelle <tr><td>1.</td><td>.. hier immer sinnvoller werden kann, scheint die Verwendung von Frames, besonders für die Navigation, zunehmend plausibler, um Interferenzen mit dem "Inhalt" zu vermeiden und sauber Bereiche zu trennen, ggf. auch bei barrierefreien Seiten.

Schließlich komme ich wieder zu der Notwendigkeit, Webseiten als Ganzes durch die Betrachtung als "Werk" zu beurteilen und die inhaltlichen Aussagen daraus abzuleiten, ob als Autor oder als Rezipient.

Grüsse

Cyx23

[MudGuard]

Hi,

<ol type="a">
<li>Äpfel, Bananen, Orangen</li>
<li>Mandarinen, Zitronen, Grapefruits</li>
<li>Mangos, Birnen, Kiwis</li>
<li>Trauben, Melonen, Pfirsiche</li>
</ol>
<p>Wir schneiden a) klein und würfeln b), pürieren c) und pressen d) aus. Fertig ist die Sauerei.</p>

Das Problem fängt doch eigentlich schon im HTML an, nicht erst im CSS.
Denn in der Dokumentstruktur findet sich keinerlei Hinweis darauf, daß sich das "a)" auf das erste li bezieht.

Soweit ich HTML kenne, gibt es hier auch keine Möglichkeit, dies so zu machen, daß die Numerierung übernommen wird.
Was ginge, wäre:

<ol type="a">
 <li id="bla">Äpfel, Bananen, Orangen</li>
 <li id="blubb">Mandarinen, Zitronen, Grapefruits</li>
 <li id="laber">Mangos, Birnen, Kiwis</li>
 <li id="sabbel">Trauben, Melonen, Pfirsiche</li>
</ol>
<p>Wir schneiden <a href="#bla">dies</a> klein und würfeln <a href="#blubb">das</a>, pürieren <a href="#laber">jenes</a> und pressen <a href="#sabbel">dieses</a> aus. Fertig ist die Sauerei.</p>

So besteht erst einmal überhaupt eine maschinenverwertbare Beziehung zurück zur Liste, die in Deinem Beispiel komplett fehlt.

Weder HTML noch CSS 2 (noch CSS 3 - soweit ich CSS3 bisher gesehen habe) bieten die Möglichkeit, den Inhalt eines Elementes zu kopieren, egal ob es statischer Inhalt (also "Äpfel, Bananen, Orangen" usw.) oder generierter Inhalt (die Numerierung) ist.

Eine Möglichkeit:
Du baust Dein Rezept als XML-Datei auf (inkl. ID für die Zutatengruppen und IDREF für die Bezüge darauf) und generierst dann die Aufzählungszeichen per XSLT - das kannst Du dann identisch für die Liste und für die Bezüge darauf machen.

cu,
Andreas

[at]

Hallo.

Eine Möglichkeit:
Du baust Dein Rezept als XML-Datei auf (inkl. ID für die Zutatengruppen und IDREF für die Bezüge darauf) und generierst dann die Aufzählungszeichen per XSLT - das kannst Du dann identisch für die Liste und für die Bezüge darauf machen.

Aber spätestens, wenn unterschiedliche grammatikalische Fälle oder Zahlen sich ändern, wird auch dies leider kompliziert: "Zutaten: Äpfel, ... Zubereitung: Nehmen Sie einen Apfel ..., einen weiteren Apfel ...". Ansonsten ist dies schon eine sehr gute Idee, danke.
MfG, at

[molily]

Das Problem fängt doch eigentlich schon im HTML an, nicht erst im CSS.
Denn in der Dokumentstruktur findet sich keinerlei Hinweis darauf, daß sich das "a)" auf das erste li bezieht.

Soweit ich HTML kenne, gibt es hier auch keine Möglichkeit, dies so zu machen, daß die Numerierung übernommen wird.
Was ginge, wäre:

<ol type="a">
 <li id="bla">Äpfel, Bananen, Orangen</li>
 <li id="blubb">Mandarinen, Zitronen, Grapefruits</li>
 <li id="laber">Mangos, Birnen, Kiwis</li>
 <li id="sabbel">Trauben, Melonen, Pfirsiche</li>
</ol>
<p>Wir schneiden <a href="#bla">dies</a> klein und würfeln <a href="#blubb">das</a>, pürieren <a href="#laber">jenes</a> und pressen <a href="#sabbel">dieses</a> aus. Fertig ist die Sauerei.</p>

Strenggenommen muss der Leser dabei in einem Satz vier Links folgen und jeweils wieder zurück in den Satz springen, da er ja nicht weiß, wohin ein Link mit dem Titel »dies« führt. Ein solcher Linktext ist bedeutungslos. Das wäre für einen Screenreaderbenutzer absoluter Overkill. Nirgendwo vorher wurde definiert, was »dies« sein könnte. Daher gab ich den Listenelementen Namen, die einmal genannt werden, deren Entsprechungen dann hoffentlich zumindest grob im Gedächtnis des Lesers bleiben und auf die man sich später beziehen kann. Im Hypertext kann man dann zusätzlich einen Link einfügen, im gedruckten Text würde der Leser kurz in die Zutatenliste darüber schauen, wenn »a)« genannt ist. Aber dieser Bezug sollte m.M.n. nicht nur durch Links ohne Linktexte, die nicht in irgendeiner Weise direkt auf die Listenelemente hinweisen, vorgenommen werden. Stell dir vor, obige Liste wird ausgedruckt, ohne dass durch ein Druckstylesheet Ankernamen und Linkadressen eingefügt werden, dann sähe der Ausdruck so aus:

a. Äpfel, Bananen, Orangen
b. Mandarinen, Zitronen, Grapefruits
c. Mangos, Birnen, Kiwis
d. Trauben, Melonen, Pfirsiche

Wir schneiden _dies_ klein und würfeln _das_, pürieren _jenes_ und pressen _dieses_ aus. Fertig ist die Sauerei.

Man würde nicht mehr wissen, was kleingeschnitten, was gewürfelt, was püriert und was ausgepresst werden muss.

So besteht erst einmal überhaupt eine maschinenverwertbare Beziehung zurück zur Liste, die in Deinem Beispiel komplett fehlt.

Angenommen, der erklärende Text unter der Liste bezieht sich dutzendfach in ständig wechselnder Reihenfolge auf die Listenelemente, so würde ich nicht jedes Vorkommen mit einen Link auszeichnen. Das ist nur nötig, wenn man die Autonomie bzw. die sogenannte köhäsive Geschlossenheit von unteilbaren Hypertextknoten hochhalten will:

<p>Wenn bla bla, dann bla bla.</p>
<p>Daraus folgt, dass bla bla.</p>

Wenn Absatz 2 wäre nicht kohäsiv geschlossen und somit nicht autonom, also eine Einheit, der nicht die Kriterien eines echten Knotens erfüllt.

<p id="sachverhalt1">Wenn bla bla, dann bla bla. Dies impliziert <a href="#sachverhalt2">Sachverhalt 2</a>.</p>
<p id="sachverhalt2">Aus <a href="#sachverhalt1">Sachverhalt 1</a> folgt, dass bla bla.</p>

Das würde den Ansprüchen genügen, mir geht es aber durchaus um streng lineare, aufeinander aufbauende Texte, ich will gar nicht alle Teile als autonom und kontextentrückbar begreifen und Beziehungen nicht immer explizit maschinenverwertbar angeben.

Weder HTML noch CSS 2 (noch CSS 3 - soweit ich CSS3 bisher gesehen habe) bieten die Möglichkeit, den Inhalt eines Elementes zu kopieren, egal ob es statischer Inhalt (also "Äpfel, Bananen, Orangen" usw.) oder generierter Inhalt (die Numerierung) ist.

Logisch wäre z.B. das Definieren von Entities, aber das hat verallgemeinert keinen Sinn, wenn die Entsprechung ein ellenlanger, hochkomplexer Text anstatt eines Begriffs oder einigen wenigen Begriffen ist und eine Ersetzung dieser Art nicht vorgenommen werden kann.

Eine Möglichkeit:
Du baust Dein Rezept als XML-Datei auf (inkl. ID für die Zutatengruppen und IDREF für die Bezüge darauf) und generierst dann die Aufzählungszeichen per XSLT - das kannst Du dann identisch für die Liste und für die Bezüge darauf machen.

Ja, sich über ein Metaformat Gedanken zu machen, welches die Zusammenhänge formal und eindeutig definiert, wäre sowieso ein interessanter Weg, was sich vor allem bei komplexere Fällen auszahlte.

[at]

Hallo.

Angenommen, der erklärende Text unter der Liste bezieht sich dutzendfach in ständig wechselnder Reihenfolge auf die Listenelemente, so würde ich nicht jedes Vorkommen mit einen Link auszeichnen. Das ist nur nötig, wenn man die Autonomie bzw. die sogenannte köhäsive Geschlossenheit von unteilbaren Hypertextknoten hochhalten will:

<p>Wenn bla bla, dann bla bla.</p>
<p>Daraus folgt, dass bla bla.</p>

Wenn Absatz 2 wäre nicht kohäsiv geschlossen und somit nicht autonom, also eine Einheit, der nicht die Kriterien eines echten Knotens erfüllt.

<p id="sachverhalt1">Wenn bla bla, dann bla bla. Dies impliziert <a href="#sachverhalt2">Sachverhalt 2</a>.</p>
<p id="sachverhalt2">Aus <a href="#sachverhalt1">Sachverhalt 1</a> folgt, dass bla bla.</p>

Das würde den Ansprüchen genügen, mir geht es aber durchaus um streng lineare, aufeinander aufbauende Texte, ich will gar nicht alle Teile als autonom und kontextentrückbar begreifen und Beziehungen nicht immer explizit maschinenverwertbar angeben.

In genau diesem Anwendungsfall würde ich eine <ol> verwenden, da hier ja die Reihenfolge die Abhängigkeit der Punkte klar herausstellt.

Ja, sich über ein Metaformat Gedanken zu machen, welches die Zusammenhänge formal und eindeutig definiert, wäre sowieso ein interessanter Weg, was sich vor allem bei komplexere Fällen auszahlte.

Ganz sicher sogar, aber leider ist es Umkehrschluss wohl auch so, dass der Aufwand bei kleinen Projekten oder einzelnen Seiten selten in einem angemessenen Verhältnis zum Ergebnis stehen dürfte.
MfG, at

[Thomas J.S.]

Hallo Andreas,

Weder HTML noch CSS 2 (noch CSS 3 - soweit ich CSS3 bisher gesehen habe) bieten die Möglichkeit, den Inhalt eines Elementes zu kopieren, egal ob es statischer Inhalt (also "Äpfel, Bananen, Orangen" usw.) oder generierter Inhalt (die Numerierung) ist.

Obwohl das mal andiskutiert wurde:
http://people.opera.com/howcome/2000/css3/clink-nov-6.html

link:found-in(X,);

Mal am Rande ;-)

Grüße
Thomas

[stefan]

Hallo molily.

Meiner Meinung nach verwechselst Du (textlichen) Inhalt und dessen Anordnung/Auszeichnung. Die <ol>-Liste stellt nur das Ordnungsprinip dar, nach dem die Inhalte strukturiert sind. Das "a." der Liste ist also kein inhaltliches, textliches "a.". Es ist lediglich die Darstellung der Struktur des Textes.

Struktur kann sich jedoch nur auf andere Struktur beziehen bzw. nur mit anderer Struktur verglichen werden. Genauso wie sich Inhalt nur auf anderen Inhalt, nicht aber auf Struktur oder Darstellung (also beispielsweise CSS), und Darstellung nur auf andere Darstellung, nicht aber auf Struktur oder Inhalt beziehen kann.

Du schreibst ja auch nicht: "bitte klicken sie hier" oder "bitte klicken sie auf den roten Link", weil sich dadurch zwangsläufig Inhalt und Präsentation überschneiden würden.

Mit Deiner <ol>-Lösung aber tust Du quasi dies. Du schreibst "bitte lesen sie das Ordnungsprinzip als Inhaltlichen Text". HTML und Text überschneiden sich.

Dein "a." wird einmal auf der strukturellen Ebene verwendet (bei der Liste), und einmal auf der inhaltlichen Ebene (beim Bezug auf die Liste).

Du hast zwei Möglichkeiten:

Entweder Du behältst das "a, b, c, d"-Prinzip innerhalb des HTML bei, also in etwa (plus CSS nach belieben):

<ol>
  <li>Äpfel, Bananen, Orangen</li>
  <li>Mandarinen, Zitronen, Grapefruits</li>
  <li>Mangos, Birnen, Kiwis</li>
  <li>Trauben, Melonen, Pfirsiche</li>
  </ol>

<ol>
  <li>Schneiden wir klein,</li>
  <li>würfeln wir,</li>
  <li>pürieren wir und</li>
  <li>pressen wir aus.</li>
  </ol>

<p>Fertig ist die Sauerei.</p>

Oder Du behältst das "a, b, c, d"-Prinzip innerhalb des textlichen Inhaltes bei und verwendest eine der von Dir erwähnten Tabellen-, Definitionslisten-, "<p> und <br>"-, oder <ul>-Lösungen (plus CSS).

Klar ist das ärgerlich, aber HTML bietet IMHO keine bessere Lösung.

Nette Grüße,
stefan

[Detlef G.]

Hallo stefan!

Meiner Meinung nach verwechselst Du (textlichen) Inhalt und dessen Anordnung/Auszeichnung.
Struktur kann sich jedoch nur auf andere Struktur beziehen bzw. nur mit anderer Struktur verglichen werden. Genauso wie sich Inhalt nur auf anderen Inhalt, nicht aber auf Struktur ...

Soll ich das als vollständige Trennung zwischen Struktur und Text verstehen.
Den Gedanken auf die Spitze getrieben, würde doch bedeuten, dass entweder eine Struktur die vollständige Information enthält oder aber ein die vollständige Information enthält, niemals aber die Information aus der Verbindung zwischen Text und logischer Auszeichnung desselben.

Warum lade ich dann nicht einfache unstrukturierte Textdateien hoch?

Ich denke Text darf sich durchaus auch auf logische Strukturen beziehen und die logische Struktur sollte auch vom Text abhängig sein.

oder Darstellung (also beispielsweise CSS), und Darstellung nur auf andere Darstellung, nicht aber auf Struktur oder Inhalt beziehen kann.

Darstellung, die sich nicht auf die Struktur und den Inhalt bezieht, kann vieleicht Kunst sein, niemals ein sinnvoles Seitendesign

Mit Deiner <ol>-Lösung aber tust Du quasi dies. Du schreibst "bitte lesen sie das Ordnungsprinzip als Inhaltlichen Text". HTML und Text überschneiden sich.

Welchen Sinn hat ein Ordnungsprinzip ohne Inhalt?
Ich dache immer HTML wäre auch dazu gedacht Text logisch auszuzeichnen. Inwieweit überschneidet sich dieses dann?

MFG
Detlef

[at]

Hallo.

Soll ich das als vollständige Trennung zwischen Struktur und Text verstehen.

Die Frage ist wohl, wie vollständig "vollständig" wirklich sein kann, ohne Zusammenhänge zu ignorieren.

Ich denke Text darf sich durchaus auch auf logische Strukturen beziehen und die logische Struktur sollte auch vom Text abhängig sein.

In einer Auszeichnungssprache ist die logische Struktur _immer_ vom Text bzw. der anderweitigen/ergänzenden Information abhängig.

Darstellung, die sich nicht auf die Struktur und den Inhalt bezieht, kann vieleicht Kunst sein, niemals ein sinnvoles Seitendesign

Was nicht der Information dient, kann dennoch sinnvoll sein -- etwa im dem Auge eine Pause zu gönnen. Mit Kunst hat dies zunächst nichts zu tun.
MfG, at

[Detlef G.]

Hallo at

Darstellung, die sich nicht auf die Struktur und den Inhalt bezieht, kann vieleicht Kunst sein, niemals ein sinnvoles Seitendesign

Was nicht der Information dient, kann dennoch sinnvoll sein -- etwa im dem Auge eine Pause zu gönnen.

Eine Darstellung, die z.B. "dem Auge eine Pause gönnt", dient vielleicht nicht dem Inhalt oder der Struktur selbst, soll doch aber dem besseren und/oder ermüdungsärmeren Erfassen desselben dienen, bezieht sich also indirekt wieder auf den Inhalt. Darstellung, ohne Bezug auf Inhalt und Struktur, wobei dieser Begriff nicht zu eng gefasst werden darf, würde eher stören.

Natürlich ist auch der Fall denkbar, dass eine Seite keinen Inhalt in herkömmlicher Form (Text, Information) hat, wobei die Darstellung an für sich steht, praktisch zum Inhalt wird. Diese Seite hätte dann aber mit HTML als Auszeichnungssprache nichts mehr zu tun, auch sie dieses Format als Werkzeug benutzt.
Solch eine Seite würde ich dann durchaus als Kunst (oder Kunstversuch) im weitesten Sinne bezeichnen.

MFG
Detlef

[at]

Hallo.

Eine Darstellung, die z.B. "dem Auge eine Pause gönnt", dient vielleicht nicht dem Inhalt oder der Struktur selbst, soll doch aber dem besseren und/oder ermüdungsärmeren Erfassen desselben dienen, bezieht sich also indirekt wieder auf den Inhalt.

"indirekt" ist natürlich ein schwer fassbarer Begriff. Wenn du ihn so interpretiert hast, sind wir uns ja einig.

Darstellung, ohne Bezug auf Inhalt und Struktur, wobei dieser Begriff nicht zu eng gefasst werden darf, würde eher stören.

Je nach Definition von "indirekt" in Bezug auf Inhalt und Struktur bliebe da aber nicht mehr viel übrig ;-)
Denn wenn etwa die Förderung des Lesevorgang in einem indirekten Bezug zum Inhalt steht, hat die Störung dieses Leseflusses den gleichen indirekten Bezug zum Text oder ist zumindest eine direkte Ableitung vom Lesefluss.

Natürlich ist auch der Fall denkbar, dass eine Seite keinen Inhalt in herkömmlicher Form (Text, Information) hat, wobei die Darstellung an für sich steht, praktisch zum Inhalt wird. Diese Seite hätte dann aber mit HTML als Auszeichnungssprache nichts mehr zu tun, auch sie dieses Format als Werkzeug benutzt.
Solch eine Seite würde ich dann durchaus als Kunst (oder Kunstversuch) im weitesten Sinne bezeichnen.

Eine solche Seite kann sicher Kunst sein, muss es aber sicher nicht. Und ob etwas einen Versuch darstellt, müssen wir wohl leider den Autoren überlassen.
MfG, at

[stefan]

Hallo,

Soll ich das als vollständige Trennung zwischen Struktur und Text verstehen.

Nein.

Den Gedanken auf die Spitze getrieben, würde doch bedeuten, dass entweder eine Struktur die vollständige Information enthält oder aber ein die vollständige Information enthält, niemals aber die Information aus der Verbindung zwischen Text und logischer Auszeichnung desselben.

Das war es nicht was ich meinte. Struktur und Text sind sogar direkt voneinander abhängig. Das eine Strukturiert das andere. Ich meinte eigentlich Folgendes:

Der Buchstabe "a.)" aus dem <ol>-Listenpunkt sieht auf zwar aus wie Text, er ist jedoch streng gesehen keiner. Er ist nur die vom Benutzeragenten in der Regel erzeugte Darstellung einer Ordnungsstruktur. Wie diese Ordnungsstruktur nun dargestellt wird, bleibt jedoch allein dem Benutzeragenten überlassen. Das einzige, wovon ausgegangen werden kann ist, dass zwei <ol>-Listen unter den selben Umständen im selben Benutzeragenten gleich dargestellt werden, nicht aber, wie sie dargestellt werden. In sofern bezieht sich die Struktur immer nur auf andere Struktur.

Wenn also der Buchstabe "a.)" garkein Text ist, sich also wohlmöglich garnicht als "a.)" manifestiert, sollte man ihn auch nicht als solchen behandeln, ihn also im wirklichen Text nicht als solchen erwähnen. In sofern sollten Text und Struktur einander nicht überschneiden.

Nette Grüße,
stefan

[Detlef G.]

Hallo stefan!

Das war es nicht was ich meinte. Struktur und Text sind sogar direkt voneinander abhängig. Das eine Strukturiert das andere.

Genau das wollte ich von dir hören.
Meine Überspitzung deiner Aussage sollte diese Klarstellung bewirken.

Wie diese Ordnungsstruktur nun dargestellt wird, bleibt jedoch allein dem Benutzeragenten überlassen.

Ja genau dann, wenn ich den Numerierungstyp als aus dem HTML ins CSS verbanne.

Ich frage mich, welchen Sinn hat eine geordnete Liste überhaupt, wenn auf diese Ordnung nie Bezug genommen werden kann.

Das einzige, wovon ausgegangen werden kann ist, dass zwei <ol>-Listen unter den selben Umständen im selben Benutzeragenten gleich dargestellt werden, nicht aber, wie sie dargestellt werden. In sofern bezieht sich die Struktur immer nur auf andere Struktur.

Wobei in deinem Beispiel aber auch kein Bezug zwischen den beiden Listen an sich besteht.

MFG
Detlef

[molily]

Der Buchstabe "a.)" aus dem <ol>-Listenpunkt sieht auf zwar aus wie Text, er ist jedoch streng gesehen keiner. [...] Wenn also der Buchstabe "a.)" garkein Text ist, sich also wohlmöglich garnicht als "a.)" manifestiert,

Ist das kein Missverhältnis, dass jeder Intuition zuwider läuft?

sollte man ihn auch nicht als solchen behandeln, ihn also im wirklichen Text nicht als solchen erwähnen.

In der Tat.  Ich finde das erschreckend.

[at]

Hallo.

Der Buchstabe "a.)" aus dem <ol>-Listenpunkt sieht auf zwar aus wie Text, er ist jedoch streng gesehen keiner. [...] Wenn also der Buchstabe "a.)" garkein Text ist, sich also wohlmöglich garnicht als "a.)" manifestiert,

Ist das kein Missverhältnis, dass jeder Intuition zuwider läuft?

In der Anwendung vielleicht, beim Lesen jedoch ergäbe sich dieses Problem ja dann gar nicht. Und wenn man sich die fast dreistellige Prozentzahl kaputter Seiten im Netz ansieht, scheint ja noch einiges mehr der Intuition zuwider zu laufen ;-)
MfG, at

[molily]

Der Buchstabe "a.)" aus dem <ol>-Listenpunkt sieht auf zwar aus wie Text, er ist jedoch streng gesehen keiner. [...] Wenn also der Buchstabe "a.)" garkein Text ist, sich also wohlmöglich garnicht als "a.)" manifestiert,

Ist das kein Missverhältnis, dass jeder Intuition zuwider läuft?

In der Anwendung vielleicht, beim Lesen jedoch ergäbe sich dieses Problem ja dann gar nicht.

Natürlich ergäbe sich ein Problem beim Lesen, weil auch der Leser intuitiv annimmt, der Text sei Text bzw. die Listennummerierung sei eine Indizierung und die Informationen entsprechend gedanklich verarbeitet, obwohl die Nummerierung in ihrer konkreten Dimension irrelevant ist. Selbst wenn der Autor darauf achtet, dass er sich nicht auf den Nicht-Text bezieht, als wäre er Text, erwartet dies der Leser, daher auch mein Vorschlag, die gewöhnlichen Nummerierungsschemata zur Verhinderung von Missverständnissen abzuschaffen.

[Axel Richter]

Hallo,

Natürlich ergäbe sich ein Problem beim Lesen, weil auch der Leser intuitiv annimmt, der Text sei Text bzw. die Listennummerierung sei eine Indizierung und die Informationen entsprechend gedanklich verarbeitet, obwohl die Nummerierung in ihrer konkreten Dimension irrelevant ist. Selbst wenn der Autor darauf achtet, dass er sich nicht auf den Nicht-Text bezieht, als wäre er Text, erwartet dies der Leser, daher auch mein Vorschlag, die gewöhnlichen Nummerierungsschemata zur Verhinderung von Missverständnissen abzuschaffen.

*g*
... Es folgt eine Auflistung der wichtigsten Arbeitsschritte. <span class="Anmerkung">Bitte beachten Sie, dass nur die Reihenfolge der Listenpunkte von Bedeutung ist. Die Nummerierung kann je nach User Agent variieren. Wir übernehmen deshalb keinerlei Garantie für die Nummerierung.</span> ;-))

Ich glaube, Ihr habt Euch hier beide vergaloppiert. Man kann ja den Listentyp per CSS vorgeben und der ist ja dann in allen User Agenten, die diese Art CSS interpretieren können, gleich. Man kann sich dann auch auf die Listenpunkte beziehen, allerdings eben nur so sicher, wie man sich auf den grün hinterlegten Anmerkungskasten  oder den rot umrandeten Bereich beziehen kann. Das finde ich allerdings auch schade und das bringt mich auch zu der Auffassung, das der Listentyp ins HTML gehört. Dann wäre die Bezugnahme so sicher, wie die auf die Tabelle "Wichtige Umsatzzahlen" (caption) oder auf das Bild "Berlin bei Nacht" (title-Attribut) oder von einem Bild auf dessen Beschreibung (longdesc-Attribut).

viele Grüße

Axel

[at]

Hallo.

... Es folgt eine Auflistung der wichtigsten Arbeitsschritte. <span class="Anmerkung">Bitte beachten Sie, dass nur die Reihenfolge der Listenpunkte von Bedeutung ist. Die Nummerierung kann je nach User Agent variieren. Wir übernehmen deshalb keinerlei Garantie für die Nummerierung.</span> ;-))

Auch 'ne Idee ;-)

Ich glaube, Ihr habt Euch hier beide vergaloppiert.

Ach was, das täuscht ;-)

Man kann ja den Listentyp per CSS vorgeben und der ist ja dann in allen User Agenten, die diese Art CSS interpretieren können, gleich. Man kann sich dann auch auf die Listenpunkte beziehen, allerdings eben nur so sicher, wie man sich auf den grün hinterlegten Anmerkungskasten  oder den rot umrandeten Bereich beziehen kann.

Das funktioniert schon einmal gar nicht, da diese Angaben ebenso unsicher sind.

Das finde ich allerdings auch schade und das bringt mich auch zu der Auffassung, das der Listentyp ins HTML gehört.

Ja, <ol>, <ul> und <dl> ;-)
MfG, at

[at]

Hallo.

Natürlich ergäbe sich ein Problem beim Lesen, weil auch der Leser intuitiv annimmt, der Text sei Text bzw. die Listennummerierung sei eine Indizierung und die Informationen entsprechend gedanklich verarbeitet, obwohl die Nummerierung in ihrer konkreten Dimension irrelevant ist. Selbst wenn der Autor darauf achtet, dass er sich nicht auf den Nicht-Text bezieht, als wäre er Text, erwartet dies der Leser, daher auch mein Vorschlag, die gewöhnlichen Nummerierungsschemata zur Verhinderung von Missverständnissen abzuschaffen.

Dem Fazit kann ich nur zustimmen.
MfG, at

[molily]

Meiner Meinung nach verwechselst Du (textlichen) Inhalt und dessen Anordnung/Auszeichnung. Die <ol>-Liste stellt nur das Ordnungsprinip dar, nach dem die Inhalte strukturiert sind. Das "a." der Liste ist also kein inhaltliches, textliches "a.". Es ist lediglich die Darstellung der Struktur des Textes.

Dann hat sich HTML fundamental vom landläufigen Listenbegriff entfernt. Die nummerierten Listen, die mir für gewöhnlich im Alltag begegnen, gehen allesamt von inhaltlichen Nummerierungen aus, die mehr als nur simple Anzeichen des Ordnungsprinzips sind. Es muss also herausgestellt werden, dass eine »geordnete Liste«, wie sie uns im Hypertext begegnet, in ihrem Wesen sehr wenig mit einer geordneten Liste, wie sie uns außerhalb des Hypertext andauernd begegnet, gemeinsam hat. Und eine Übertragung und Vereinbarung der Konzepte ist per se nicht möglich.
Das wäre jetzt kritisch zu untersuchen bzw. es gälte zu klären, was das in verschiedener Hinsicht bedeutet, was daraus folgt. Ich glaube, dabei käme nichts gutes heraus.

Struktur kann sich jedoch nur auf andere Struktur beziehen bzw. nur mit anderer Struktur verglichen werden. Genauso wie sich Inhalt nur auf anderen Inhalt, nicht aber auf Struktur oder Darstellung (also beispielsweise CSS), und Darstellung nur auf andere Darstellung, nicht aber auf Struktur oder Inhalt beziehen kann.

Es hat zwar nichts hiermit zu tun, aber ich glaube, diesen grundlegenden Struktur-Inhalt-Darstellung-Gegensatz als Verhältnis verschiedener an allen Punkten paralleler, per Definition nur mit vorgegebenen Mitteln verknüpfbarer, aber niemals in ihrer Grundkonstellation veränderbarer Ebenen wird ein Gewöhnlicher Webautor(tm) weder nachvollziehen wollen, weil er sich offensichtlich völlig von jeglicher Erfahrungswirklichkeit losgelöst hat, noch nachvollziehen können, weil er fern von nicht in bestimmte Bahnen gelenktem menschlichen Denken steht.