Vorlage Diskussion:Auflistung

Anmerkungen

Hallo PerfektesChaos, ich habe deinen Hinweis auf diese Vorlage mal ein paar Tage wirken lassen und will mich jetzt und hier dazu äußern. Den Ansatz, Aufzählungen für Navigationsleisten wie herkömmliche (nummerierte oder unnummerierte) Listen entgegenzunehmen und für Screenreader auch als solche zu präsentieren, finde ich sehr interessant. Vor einem potenziellen großflächigen Einsatz in Navigationsleisten möchte ich gerne ein paar Weiterentwicklungen anregen, vor allem für Vorlagen mit mehreren Listen wie diese:

• Lassen sich für die Verwendung mehrerer getrennter Listen in Navigationsleisten die vertikalen Außenabstände der erzeugten Listen so einstellen, dass sie den Außenabständen der derzeitig erzeugten Absätze entsprechen?
• Ließe es sich erreichen, getrennte aufeinanderfolgende Listen durch Eingabe von leeren Quelltextzeilen zwischen ihnen zu erzeugen, anstatt diese Vorlage mehrfach aufzurufen?
• Falls wir nicht zu viele linksbündige Listen in Navigationsleisten im Einsatz haben, was zu prüfen wäre, könnte man dann diese Vorlage automatisch auf den Inhalt-Parameter aller Standard-Navigationsleisten anwenden, sodass für eine Umstellung einzelner Navigationsleisten allein die Ersetzung der nachfolgenden Trennzeichen (in Entity-Form) auf vorangestellte (mit einfachem Aufzählungssymbol) vorzunehmen wäre?

Varianten wie durchgehenden Umbruchschutz der einzelnen Einträge (nowrap) wie bei Filmlisten üblich und ein von einem einheitlichen Trennzeichen (Punkt oder Strich soll mir egal sein) abweichend zu verwendendes Trennsymbol könnte man dann durch Zusatzparameter der Navigationsleiste steuern. --Wiegels „…“ 01:38, 9. Nov. 2020 (CET)

Ich sortier mal:

• mehrere getrennte Listen
  • Ich habe gerade noch weitere HTML-Standard-Attribute style= id= lang= bereitgestellt.
  • Ich habe erstmal nicht so wirklich verstanden, was die „Außenabstände der derzeitig erzeugten Absätze“ sind.
  • Das müsste dann der jeweilige Anwendungsfall entscheiden. Navileisten sind nur eine Anwendung unter unendlich vielen.
• getrennte aufeinanderfolgende Listen durch Eingabe von leeren Quelltextzeilen zwischen ihnen
  • Theoretisch ja.
  • Praktisch fürchte ich, dass durch solche Zusatz-Syntax der Charme der größtmöglichen Einfachheit der privaten Spezial-Syntax dieser Vorlage verlorenginge. Momentan braucht man nur zu wissen: Sternchen-Aufzählung wie in konventionellem Wikitext, fertig.
  • Die Methodik ist universell; ob das ein für sehr viele Navileisten relevanter Anwendungsfall ist oder es nur hie und da mal eine Navileiste gäbe, wo das etwas einsparen würde, überblicke ich grad nicht.
  • Momentan zählt alles was nicht explizit neues Sternchen mit Text dahinter wäre als Bestandteil des letzten Elements. Damit wird die Geschichte auch robust gegen Fehlbedienung.
  • Das angegebene Beispiel hat am Beginn jeder Auflistung ein in Fettschrift und mit Doppelpunkt und ohne weiteres Trennzeichen angegebenes zusätzliches Element. Es gäbe aber nur einen einzigen Vorspann= für alle Listen des INHALT. Optisch ließe sich das als Teil des ersten Aufzählungs-Elements vom Anwender formatieren, was aber die Screenreader-gerechte Abspaltung der allerersten Verlinkung beeinträchtigt. Zurzeit wird die „Überschrift“ auch nicht bilderbuchmäßig als allererstes Element der Aufzählung behandelt, aber die erste Verlinkung ist wenigstens davon separiert. Der Charakter des Vorspann= ist universell; andernfalls hätte ich schon darüber nachgedacht, ihm einen ARIA-Charakter zuzuweisen. Die gebräuchliche Fettschrift, wahlweise auch Kursivschrift, signalisiert jedoch auch Screenreadern, dass es was Besonderes ist, und wäre im konventionellen Fließtext auch nicht anders.
  • Eine weitere Verkomplizierung der Syntax des Inhaltsbereichs mit irgendeinem kryptischen Sonderzeichen am Anfang für den Vorspann, womöglich ; aus unseliger Tradition missbrauchter Definitionslisten, möchte ich nicht einführen, und würde auch ein schlechtes Vorbild abgeben. Die Erkennung führender mehrfacher Apostrophe am Beginn einer Quelltextzeile oder gar kein Sternchen wäre zwar möglich, würde aber wieder auf eine komplexe private Syntax hinauslaufen, die am Ende niemand mehr versteht. Schließlich müssen auch VE-Benutzer diese Syntax offen eingeben, ggf. ohne Quelltext-Erfahrungen zu haben; könnten eines Tages vielleicht die Sternchen-Syntax direkt als VE-Aufzählung visuell in einen Parameterwert eingeben. Spätestens dann sind aber alle Experimente mit spezieller Quelltext-Syntax innerhalb des Parameterwerts abgeschossen. Hingegen kann in einem Parameter INHALT hoffentlich irgendwann das Einfügen einer oder mehrerer Vorlage:Auflistung mittels VE erfolgen, und in deren Parameter Liste dann per VE eine Aufzählung von Listenpunkten.
• Parameter INHALT der Standard-Navileiste
  • Die erweiterte Navileiste strebt gerade sowas an.
  • Die hat allerdings unbegrenzt viele (momentan noch grundlos limitiert bei 20) separate Abschnitte, wird zurzeit auf Lua nachmodelliert und kann jeden ihrer Abschnitte syntaktisch analysieren.
  • Die Standard-Navileiste hat nur den einen Parameter INHALT und muss mit diesem Wert unendlich viele Gestaltungen mit Zwischenüberschriften und Blöcken und Verweisen auf Gesamtdarstellungen usw. bewerkstelligen.
  • Sie müsste also in jeder ihrer halben Million Einbindungen den INHALT analysieren und bei Antreffen der reinen Sternchen-Liste hü und ansonsten hott als konventionelle Darstellung vornehmen.
  • Zwar ist die eine einzige Aufzählung und fertig ein Routinefall, jedoch weiß ich auch von recht vielen Navileisten, bei denen innerhalb des INHALT noch relativ viel strukturierte Darstellung in einzelnen Abschnitten, zeitlichen Perioden, nach Kontinenten oder Genre sortiert passiert.

Generell ist meine Erfahrung, dass die im zweiten und dritten Punkt angeregte Spezial-Syntax es denjenigen Bearbeitern erschwert, die nur sehr gelegentlich als Autor von Artikeln die jenen zugehörige Navileiste bearbeiten müssen. Solche Abkürzungen und Sondersyntax und „Vereinfachung“ ist immer nett und vereinfachend für die sehr wenigen, die sich intensiv damit auskennen und insbesondere immer den geistigen Urheber des Konzepts. Für jeden anderen schaffen solche Verkürzungen zusätzliche Kopfschmerzen und Einarbeitungsaufwand; und es wird nicht mehr vorhersehbar was welche Notation bewirken wird.

• Der Parameter INHALT ist ganz plump ein Bereich von Wikisyntax, wie er auch an jeder anderen Stelle oder genauso in Artikeln verwendet werden könnte. Fertig. Ein Hineingeheimnissen von Sonderparametern zusätzlich zum INHALT und Nebenwirkungen und Automatismen macht das zur Wundertüte. Der INHALT kann dann auch nicht mehr in beliebigem Kontext ausprobiert werden.

VG --PerfektesChaos 03:18, 9. Nov. 2020 (CET)

Anmerkungen 2

Ich hätte da drei Anmerkungen/Fragen/Wünsche. Zur übersichtlicheren Bearbeitung mit Zwischenüberschriften.

Trennzeichen Kreis

Wie kürzlich auf FzW angesprochen wurde, ist die aktuelle Darstellung des runden Trennzeichens noch nicht optimal. Soweit ich das sehe, wird das erzeugte Zeichen konsequent oben und unten leicht „angeschnitten“, wodurch es je nach Auflösung, Zoomstufe, Browser und Gerät unterschiedlich stark verformt aussieht. Ich habe mich nicht in die Vorlage vertieft, aber warum nicht einfach „•“ (• Alt+7) verwenden (am besten zur Verdeutlichung mit font-weight: bold;)? Das Symbol ist im Bestand das am weitesten verbreitete (entspricht damit den Erwartungen der User) und ist darüber hinaus zoom-, browser- und gerätebeständig.–XanonymusX (Diskussion) 17:18, 22. Jan. 2021 (CET)

• Gucke ich mir an; ich habe kein Gerät mit diesem Problem oder einer in der Normaldarstellung auftretenden Problematik.
  • Regel-Anwendung ist das Quadrat.
• Warum nicht •
  • Barrierefreiheit.
    • Die Darstellung ist bei eingeschränkten kognitiven oder visuellen Möglichkeiten zu klein und die Darstellungsgröße von der Schriftart abhängig.
    • Autoren sind regelmäßig die falschen Bewerter der Verständlichkeit ihrer Darstellung durch Dritte. Autoren wissen schon alles, hatten das ja selbst geschrieben, kennen langjährig alle Fachausdrücke.
    • Autoren wollen die leserfreundliche Gliederung gern ganz ganz klein und so unauffällig wie möglich. Sie wissen ja schon wo die Trennungen liegen.
    • Unbeteiligte Menschen, die das alles zum ersten Mal sehen, und womöglich nicht so gut gucken können, haben eine völlig andere Wahrnehmung, wie ich über viele Jahre aus Rückmeldungen von Bekannten und Verwandten weiß.
    • Autoren argumentieren gern, dass man dies schon immer so gemacht habe, seit 2005, weil andere Möglichkeiten habe man 2005 nicht gekannt. Die Leser leben immer noch, also müsse die Methodik von 2005 auch immer weiter so gemacht werden, weil es hätte die Leser ja bisher nicht umgebracht.
  • Verhält sich beim C&P anders, und dies ist nur per CSS-Generierung möglich.
    • Bei mir gibt es weiterhin Trennzeichen auch beim C&P-Resultat, in der enWP gibt es einen unstrukturierten Wortbrei.
    • Ist auch umseitig ausdrücklich beschrieben.

VG --PerfektesChaos 12:01, 23. Jan. 2021 (CET)

Bei mir ist es wirklich überall abgeschnitten (Mobilgeräte, PC; Safari, Chrome; diverse Zoomstufen; Minerva, Vector). Quadrat scheint okay zu sein. Den ersten Punkt kann ich schon nachvollziehen, wobei Abhängigkeit von der Schriftart schon ihr Gutes haben kann, um grafische Abwegigkeiten zu verhindern. Den zweiten Punkt habe ich nicht verstanden; dass das Zeichen per CSS generiert wird, bestreitet ja niemand, aber das spricht nicht gegen „•“, auch das wird per CSS erzeugt und ist nicht kopierbar. Gruß—XanonymusX (Diskussion) 12:37, 23. Jan. 2021 (CET)

Das umseitige Trennzeichen ist kein Schriftzeichen, sondern eine CSS-Hintergrundgrafik.

Das umseitige Schriftzeichen ist ein Pipe-Symbol.

Natürlich ist CSS an allem irgendwie beteiligt.

VG --PerfektesChaos 12:58, 23. Jan. 2021 (CET)

Die Größe der CSS-Hintergrundgrafik ist in em berechnet; da gilt es keine „grafische Abwegigkeiten“ zu verhindern. VG --PerfektesChaos 13:17, 23. Jan. 2021 (CET)

Ja, jetzt habe ich die Technik dahinter verstanden. Das Problem ist also der genaue Wert des border-radius; im Moment treffen sich die Abrundungen der Ecken wohl nicht besonders genau, wodurch oben und unten noch die Kante sichtbar ist. Kann ich bei mir auch noch mal mit experimentieren. Gruß—XanonymusX (Diskussion) 13:30, 23. Jan. 2021 (CET)

Wahrscheinlich ein Rundungsproblem; das kenne ich von calc und womöglich kommen manche Browser mit einem Drittelpixel nicht so gut zurecht. Ich werde experimentieren. VG --PerfektesChaos 19:21, 23. Jan. 2021 (CET)

Auch noch verglichen: Der Middot in Vorlage:Subpage/styles.css ist von der Form her stabil (klar, ohne border-radius), aber hat das Problem, dass er bspw. in Safari vertikal nicht mehr zentriert und im Verhältnis zur Schrift zu groß ist (so etwas Ähnliches hatten wir ja schon bei der ursprünglichen Lösung der Linkzeile bei In den Nachrichten). Gruß–XanonymusX (Diskussion) 21:56, 23. Jan. 2021 (CET)

Eine Lösung über SVG fällt mir auch noch ein, etwa mit list-style-image: url(/w/skins/Vector/resources/skins.vector.styles/images/bullet-icon.svg);.–XanonymusX (Diskussion) 02:25, 25. Jan. 2021 (CET)

Danke, den kenne ich sehr wohl.

• Er ist dank WMF-Domain auch TemplateStyles-fähig.
• Aber er ist immer und nur schwarz.
• Jedoch .breadcrumb-nav-bullet-blue erlaubt konzeptionell von Anfang an auch blaue Trenner, und ebenso wären weiße, gelbe, rote und grüne Trenner möglich, falls die Aufzählung vor einem invertierten Hintergrund oder mit anderen Schriftfarben geschieht. Und dies unabhängig von einem Commons-Zoo.
• Betrachte deine SVG mit konventioneller Wikisyntax:

• Erster Punkt
• Zweiter Punkt

VG --PerfektesChaos 15:46, 25. Jan. 2021 (CET)

Umbruch (erl.)

Die Vorlage bietet die Option Nowrap an. Allerdings ist die Erwartung im Normalfall nicht etwa, dass die gesamte „Aufzählung“ auf einer Zeile steht (für Mobilgeräte kann das sowieso ein K.-O.-Kriterium sein, sollte also für schmale Bildschirme noch grundsätzlich deaktiviert werden), sondern dass das Trennzeichen nicht am Anfang einer Zeile stehen kann. In so gut wie allen Navigationsleisten, die ich kenne, werden die Einträge konsequent durch  • abgeschlossen. Die Änderung dieses Verhaltens finde ich im WP:Autorenportal nach der Umstellung auch am störendsten. Das Problem habe ich in meiner Adaption der enWP-hlist durch ein banales \00A0 vor dem Trenner im CSS-content gelöst, ob das bei dieser Vorlage ebenfalls die Lösung ist, durchblicke ich noch nicht. Zum Vergleich Vorlage mit Nowrap, Vorlage ohne Nowrap und hlist ohne Umbruch vor Trenner:

• Das kleine Mädchen mit den Schwefelhölzern |
• Der kleine Klaus und der große Klaus |
• Der standhafte Zinnsoldat |
• Des Kaisers neue Kleider |
• Die kleine Meerjungfrau |
• Die Prinzessin auf der Erbse

• Das kleine Mädchen mit den Schwefelhölzern |
• Der kleine Klaus und der große Klaus |
• Der standhafte Zinnsoldat |
• Des Kaisers neue Kleider |
• Die kleine Meerjungfrau |
• Die Prinzessin auf der Erbse

• Das kleine Mädchen mit den Schwefelhölzern
• Der kleine Klaus und der große Klaus
• Der standhafte Zinnsoldat
• Des Kaisers neue Kleider
• Die kleine Meerjungfrau
• Die Prinzessin auf der Erbse

–XanonymusX (Diskussion) 17:18, 22. Jan. 2021 (CET)

• Ist mir jetzt nicht klar, worauf du hinaus willst.
• „sondern dass das Trennzeichen nicht am Anfang einer Zeile stehen kann“
  • Tritt bei mir auch nicht auf; es gibt eine Testsuite zur umseitigen Vorlage, in der genau das untersucht wird.
• Voraussetzung ist, dass jedes einzelne Element so kurz wäre, dass inhaltlich alle Elemente ohne Entgleisung jedes für sich selbst zusammengehalten werden können.
  • Es gibt viele Navileisten mit in Summe zigtausenden
    {{nowrap|Paul Maier •}}
{{nowrap|Petra Meier •}}
  • Die umseitige Option |nowrap=1 hält nicht nur deinen • hinten an dem ier dran, sondern auch Vor- und Nachnamen zusammen.
  • Setzt natürlich voraus, dass da nicht grad die Maria Timofeija Alessandrowa Chatschaturnojewskinska in der Liste auftaucht; dann sollte das besser unterlassen werden.
  • Wenn du dir übrigens dein hlist-Beispiel mal genauer anguckst, und ggf. dein Browser-Fenster (sofern Desktop) ziehst: Bei mir steht gerade „• Der“ am Ende der einen und „standhafte Zinnsoldat“ am Beginn der folgenden Zeile. Eins drüber hingegen endet die Zeile auf „•“ und die nächste beginnt mit „Der standhafte Zinnsoldat“.
  • Heißt: Russische Olympiamannschaften im Kugelstoßen sollten den Parameter vielleicht besser nicht setzen; wenn die Elemente hingegen überschaubar sind und zur besseren Lesbarkeit „Bad Berneck“ am Stück und nicht in Scheiben geliefert werden soll, dann wäre das eine Option.
• Was wäre an „Jedes Element vollständig auf derselben Zeile“ misszuverstehen, und worin könnte der Unterschied liegen zu dass die gesamte „Aufzählung“ auf einer Zeile steht und dass das Trennzeichen nicht am Anfang einer Zeile stehen?
• Wo genau finde ich dieses Feature in der hochgejubelten enWP?

VG --PerfektesChaos 12:01, 23. Jan. 2021 (CET)

Dann nochmal von vorne. Hat nix mit enWP zu tun, dort gibt es bei den Aufzählungen keinen grundsätzlichen Umbruchschutz. Bei den Beispielen oben ragt mir das erste über den Bildschirmrand und beginnen beim zweiten Zeilen mit dem Trenner. Beides unschön.

Ich habe in meinem Beispiel per CSS umgesetzt, was bis dato in den meisten mir bekannten Navigationsleisten mit  • gelöst wird. Heißt: Die Elemente können frei ungebrochen werden (könnten gerade bei Film-, Lied- oder Buchtiteln ziemlich lang sein), aber das Trennzeichen steht nie am Zeilenanfang. Das ist der aktuell überall gewünschte Effekt bei derlei Aufzählungen und ich fände es nicht sinnvoll, das plötzlich zu ändern. Wäre aber möglich, dass durch die eingeschobene Pipe dieser Umbruchschutz nicht so banal durch das \00A0 zu lösen ist, da müsste ich erst tiefer einsteigen.

Nowrap findet in der Tat in einigen Navigationsleisten Anwendung, und dort ist der eingebaute Schalter dann die richtige Lösung. Allerdings sollte das responsiv für schmale Bildschirme deaktiviert werden; ändert nichts am Umbruchschutz vor dem Trennzeichen.

Gruß—XanonymusX (Diskussion) 12:52, 23. Jan. 2021 (CET)

|nowrap=1 ist eine zuschaltbare Option, die dann einzusetzen wäre, wo die Länge jedes Elements die zu erwartenden Bildschirmbreiten nicht sprengen würde, und wo dies zurzeit ohnehin per {{nowrap|}} bzw.   zwischen den Einzelwörtern umgesetzt ist.

Dies mit Änderung eines Byte mal eben im VE abzuschalten, statt 17 einzelne Listeneinträge umschreiben zu müssen, sähe ich als Fortschritt an.

Was du nun wieder mit Bildschirmrändern hast, weiß ich nicht. Wenn für dich die „Schwefelhölzern“ zu lang werden – die umseitige Doku braucht Anwendungsbeispiele, wo der zu beobachtende Effekt mal auftritt, ohne dass das Desktop-Browserfenster auf die Breite einer Armbanduhr zusammengezogen werden muss.

Wie es dazu kommen kann, dass das Trennzeichen bei dir nicht angehängt bleibt, wäre zu untersuchen. Die Testsuite spielt alle Fälle durch; nach den mir prima vista geläufigen Umbruchregeln sollte das in keinem Browser passieren. Kann ich aber nochmal forschen, aber nicht mehr diesen Monat. Ich habe inzwischen eine Bugwelle von zwei bis drei Monaten zum Abarbeiten und eigentlich gar keine Zeit und Ruhe für sowas.

VG --PerfektesChaos 13:11, 23. Jan. 2021 (CET)

Ja, Nowrap grundsätzlich in der Mobilversion responsiv zu deaktivieren wäre sinnvoll, dann spart man sich vorlagenseitige Basteleien. Wobei ich das Gefühl hatte, dass etwas in die Richtung schon existiert, vielleicht über eine der ominösen englischen CSS-Klassen. Werde ich auch noch nachforschen. Denn dass {{Nowrap}} auch jetzt schon problematisch ist, ist klar.

Ich hoffe, wir haben uns richtig verstanden; mein Problem mit den Umbrüchen ist Beispiel 2 (mit Nowrap bleibt auch das Trennzeichen in der oberen Zeile). Ich habe den Umbruch auch hier wieder auf allen Geräten, Safari/Chrome, Minerva/Vector. Gestern schien mir allerdings, dass das Problem in der Vorschau des VE nicht mehr reproduzierbar war, egal wie sehr ich das Fenster zusammengeschoben habe. Das wäre allerdings ein sehr seltsamer Effekt. Gruß—XanonymusX (Diskussion) 13:24, 23. Jan. 2021 (CET)

Okay, das Problem hab ich jetzt verstanden: Das Trennzeichen ist zwar umbruchgeschützt, aber nur in Bezug auf das transparente Pipe. Letzteres hingegen rutscht, da separater span, nach Belieben in die nächste Zeile und nimmt dabei natürlich das Trennzeichen mit. Eine einfache CSS-Lösung habe ich jetzt auf die Schnelle nicht gefunden. Irgendwie müsste der Umbruch vor dem span auf jeden Fall verhindert werden. Falls mir was einfällt, geb ich nochmal Bescheid, aber ich hab ja auch andere Projekte auf der To-Do-Liste. Gruß–XanonymusX (Diskussion) 15:17, 23. Jan. 2021 (CET)

Laut meinen Tests (nur Chrome) lässt sich der Umbruch ganz einfach verhindern, indem vor jedes Pipe statt eines Leerzeichens ein   eingefügt wird. Die Idee mit dem nowrap im span war also richtig, aber bleibt offenbar wirkungslos (zumindest in Chrome und Safari, angeblich verhält sich Firefox in diesem Punkt etwas anders). Gruß–XanonymusX (Diskussion) 14:12, 28. Jan. 2021 (CET)

Zumindest das ist gelöst, war ja wirklich ganz simpel! Ich wurde die letzten Tage beim Autorenportal dauernd von Bullets am Zeilenanfang begrüßt, sehr unschön. Gruß–XanonymusX (Diskussion) 23:49, 28. Mär. 2021 (CEST)

Mehrere Ebenen

Diese Vorlage kann, im Unterschied zur hlist, nicht mit mehreren Aufzählungsebenen (nested lists in enWP) umgehen. Zum Vergleich:

• A |
• B |
• * B.1 |
• * B.2 |
• C

• A
• B
  • B.1
  • B.2
• C

Wäre mE noch eine sinnvolle Funktionserweiterung (müsste dann auch mit Kombinationen von ol und ul umgehen können; in meiner Adaption für die Navigationsleisten habe ich ol momentan nicht vorgesehen). Ob es jetzt unbedingt die Klammerung sein muss, weiß ich nicht, aber ich kenne keine andere Variante.–XanonymusX (Diskussion) 17:18, 22. Jan. 2021 (CET)

• Ich finde das absolut nicht sinnvoll.
• Ich finde die Darstellung in der enWP äußerst verwirrend und nicht intuitiv.
• Die Regel ist KISS: alles, was diese Vorlage generiert, wird ggf. in einer einzigen Zeile, jedenfalls als Fließtext dargestellt.
• Die enWP ist verbastelt, und übermäßig verkompliziert.
• Ich würde erwarten, dass die ** dann wie bei einer normalen Aufzählung in derselben Fließtext-Zeile stehen würden, und die mit nur * bekommen dann einen Listenpunkt. Die Auswirkung deines Doppelstern-Formats ist für mich nicht intuitiv vorhersehbar. Alles mit einem * vorn erschiene in einer einzigen Zeile, immer, es sei denn es gäbe auch ** dann wieder doch nicht, weil dann, und die * danach dann wieder.
• Ich sehe keinerlei großflächige Anwendung in unseren Navileisten, wo es eingeklammerte Unter-Listen geben würde. Genauer: Ich habe sowas noch nie gesehen.
  • Was es gibt, das wären eingeklammerte einzelne Elemente, etwa weil Eintrag veraltet; nicht aber Untergruppen von gleichrangigen Elementen. Die einzelnen Elemente können auch hier einzeln in Klammern und kursiv usw. gesetzt werden.
• Auch aus Sicht des Endkonsumenten, egal ob blind oder sehend, finde ich diese eingestreuten Klammern und was sie zusammenhalten sollen weder übersichtlich noch in ihrer Bedeutung verständlich. Welche arme Sau soll denn in einer Aufzählung von 20 Elementen die jeweils zugehörige schließende Klammer wiederfinden? Wenn hingegen die veralteten, inzwischen ausgeschiedenen oder abgerissenen oder versunkenen Einträge jeweils in Kursivschrift gesetzt werden, dann ist dies sowohl für Screenreader wie für Sehende leicht verständlich und erkennbar. Bedarf natürlich einer Legende, aus welchen Gründen die einen anders sind als andere.
• Die Methodik mit verdoppelsternchend kann ich auf en:Template:Hlist auch nicht entdecken.
  • Was es da gibt, ist: Giant planets (J S U N)
  • Das ist bei uns per Vorspann= gelöst, und ohne Klammern.
  • Ich hatte mir das Zitat eben per C&P geholt, bzw. holen wollen. Einfach mal ausprobieren, und dann die enWP-Experten hochleben lassen.
• Solche Anti-KISS-Verbastelei begreifen immer nur die Handvoll Nerds, die das mal persönlich rangefrickelt hatten. Alle anderen werden dadurch vor die Tür gestellt. Ich bin seit Jahren dabei, genau solche kryptischen unvorhersehbaren Wirkungen rauszuschmeißen, und das Vorlagensystem insgesamt möglichst zu vereinfachen.
• en:Template:Hlist #Parameters ist mir viel zu exotisch verkopft, das will ich in einer auf potenziell 40.000 Navileisten umzusetzenden Methodik auf keinen Fall haben.
  • Knapp jede zweite Vorlage ist eine Navileiste, und da muss die Pflege durch die Autoren passieren und so trivial wie möglich sein.
  • Es gibt drei Boolesche Schalter zur Anpassung, und dann noch vier verbreitete Standard-HTML-Attribute, und damit fertig. Der INHALT soll kinderleicht vorhersagbar und ohne Überraschungen definierbar sein.
  • font-size: 90%; machen wir auch nicht, wegen Barrierefreiheit. Inhaltlich bedeutungstragende Informationen werden nicht verkleinert.
  • Es soll überhaupt nicht tausenderlei Rumfrickel-Parameter geben, die nur überflüssige Privatgeschmacks-Dekoration einbringen und den nachfolgenden Bearbeitern das Leben zur Hölle machen.
• Ganz grundsätzlich betreibe ich neue Einführungen nicht per C&P, sondern finde zu neuen Sachverhalten jetzt aktuelle neue zeitgemäße Lösungen per eigener Hirnaktivität. Was irgendwer hier oder in der enWP immer schon so gemacht hatte interessiert mich nur peripher (1. Thess 5,21). Nur weil irgendwas in der enWP gemacht wird kann es trotzdem unbrauchbarer Bockmist sein.

VG --PerfektesChaos 12:01, 23. Jan. 2021 (CET)

Schön, ich finde es absolut sinnvoll, nicht verwirrend und äußerst intuitiv! :D Ich sprach nicht von der Vorlage, sondern von der Klasse hlist; die Vorlage, die dieser hier ungefähr entspricht, wäre en:Template:Flatlist. Aber stimmt schon, die nested lists sind standardisiert wohl nur innerhalb der Navboxen vorgesehen, wenn man sich die Beiträge auf der Vorlagendiskussion zu Gemüte führt.

Hm, war auch nur ein Feature Request. Ich bin der Meinung, dass eine Auflistung genannte Vorlage mit allen Möglichkeiten von HTML-Aufzählungen (bzw. deren Wikitext-Varianten) umgehen können muss. Wie sie das macht, ist natürlich offen, ich kenne keine standardisierten Styleguides zu horizontal lists, aber die untergeordneten Elemente einfach auf die gleiche Ebene zu holen und einen Asterisken mit in den Inhalt zu nehmen, ist nicht besonders elegant.

Ob es gebraucht wird, kann ich in der Tat nicht beurteilen; grundsätzlich ist deWP ja bis heute ganz ohne horizontale Listen ausgekommen. In diesem Sinne kein Beinbruch, wenn weitere Aufzählungsebenen innerhalb dieser Vorlage verboten werden (sollte dann aber explizit dokumentiert werden, dass nur eine Aufzählungsebene unterstützt wird). Gruß—XanonymusX (Diskussion) 13:13, 23. Jan. 2021 (CET)

Naja, umseitig ist dokumentiert, was gemacht werden soll. Wie in allen Dokumentationen wird praktisch nie dokumentiert, auf was für irgendwie vorstellbare Ideen man alles nicht kommen solle, weil die Aufzählung aller nicht zu vollziehenden Abwege um ein Mehrfaches länger würde als das was getan werden soll. Was sich katastrophal auf die Übersichtlichkeit und Verständlichkeit auswirkt. Nur wenn in der Praxis beobachtet wird, dass bei der Anwendung sehr häufig bestimmte Fehler gemacht werden, wird im ersten Schritt die positive Beschreibung klarer und eindeutiger gefasst; erst wenn das nicht hilft in einem zweiten Schritt nach Jahren auch noch eine Beschreibung der typischen Ideen, die nicht umgesetzt werden können.

Ich habe immer noch nicht verstanden, was für einen Effekt ich mir von Doppelsternen erwarten soll. Doppelsterne zielen auf eine vertikale Liste ab, bei denen mehrfache Aufzählungszeichen auch bewirken können, dass eine neue Einrückungsebene geschaffen wird. In einer horizontalen, scheinbaren Fließtext-Aufzählung gibt es nur eine einzige ganz lange ausfließende Zeile und keinerlei Einrückungsebenen, und darin ist ein Konzept von „mehreren Ebenen“ sinnfrei.

Wenn es jemand macht, dann wird ein * in der Darstellung sichtbar, und dann käme man schon allein drauf dass dies so nicht geht.

Wir haben keine Navileisten oder sonstige Aufzählungen mit eingeklammerten Unterleisten.

Was es gibt, das sind Flotten oder Bahnlinien. Die Schiffe, die noch schwimmen, stehen in gerader Schrift; was abgesoffen oder verschrottet wurde in kursiv. Die Bahnhöfe die noch in Betrieb sind bekommen gerade Schrift; was abgerissen oder umgebaut wurde, und wo kein Zug mehr hält ist kursiv. Das wird simpel jedem Element zugeordnet und in der Legende erklärt. Dass wir Untergruppenlisten in derselben Zeile mit Klammern hätten habe ich noch nie gesehen.

VG --PerfektesChaos 13:34, 23. Jan. 2021 (CET)

Ich kenne natürlich die Vorlage:Wikipedia:Navigationsleiste Chartvorlagen (die ich wohlgemerkt ohne Kenntnis der Navbox-Technik mal so entworfen hatte)! ;) Rein semantisch bedeutet eine zweite Aufzählungsebene doch, dass diese Listenpunkte dem vorhergehenden höheren Punkt untergeordnet sind. Als Fließtext gedacht erscheint es mir nach gängiger Zeichensetzung völlig logisch, diese Unterordnung als Klammerung darzustellen. Und diese Vorlage will ja Screenreadern helfen, indem derlei Semantik im HTML beibehalten wird.

Wie gesagt, dass vermutlich kein Bedarf besteht, sehe ich ein (und die Klammerungen weiter manuell an Listenpunkte anzuhängen, ist eine Kleinigkeit); aber die Logik dahinter erscheint mir alles andere als schwer verständlich. Gruß—XanonymusX (Diskussion) 13:51, 23. Jan. 2021 (CET)

• Das <small> in Vorlage:Wikipedia:Navigationsleiste Chartvorlagen ist bereits nicht barrierefrei und in einer zukunftsweisenden Neukonzeption nicht akzeptabel. Alle bedeutungstragenden Elemente müssen die Mindestschriftgröße einhalten.
• Es sind witzigerweise die Screenreader die einzigen, die sowohl einen Unterschied zwischen # und * in der umseitigen Vorlage wahrnehmen könnten, wie auch die Untergruppierungen; während kein Sehender Überblick hat, an welcher Stelle eine schließende Klammer nach einer Untergruppe von soundsoviel (10? 15?) Untergruppen-Elementen auftauchen würde – die auch keine Verkleinerung der Schriftgröße enthalten dürfen.
• Auch deine Untergruppen können also nur Screenreader verstehen; für Sehende sind sie nicht erfassbar.
• Nebenbei bist du da noch mit Kommata zwischen den Elementen zugange.
• Wenn du mit Vorlage:Wikipedia:Navigationsleiste Chartvorlagen eine strukturierte Navigation über diverse Typen und Gruppen von Vorlagen anbieten willst, dann ist es eine konventionelle vertikal orientierte Liste mit dem Haupttyp, ggf. als Vorspann= in umseitigen Sinn; und danach kämen die Untertypen dieses Haupttyps als horizontale Auflistung (zurzeit mit runden Klammern und Kommata).
• Und ein Block dieser ein oder mehrerer Haupt- und Untertypen korrespondiert dann mit der Überschrtift links.
• Nebenbei verwenden wir im Zeitalter der VisualEditor-Newbies keine Insider-Syntax wie {{Charttabelle}} mehr; wer mit dem VE groß wird, kann nicht wissen, was geschweifte Klammern bedeuten sollen. Dies ist obsolet.
• Weil aber ohnehin ausschließlich Vorlagen verlinkt sind, ist es unverständlich, warum manche Vorlagen mit {{...}} verlinkt sind und andere dann wiederum nicht. Was will mir das sagen? Hier wäre Fettschrift und Vorspann= für mich als Außenstehenden leichter erklärlich.
• Das ist mal wieder so ein Fall, wo für den Ersteller seine private Logik klar ist, weil man selbst das ja schon strukturiert und seit Jahren verinnerlicht hat. Für mich der ich es zum ersten Mal sehe ist dem nicht so. Ich bemühe mich regelmäßig, auf meine eigenen Werke mit fremden Augen zu blicken, oder ziehe bislang völlig unbeteiligte Versuchskarnickel heran und lasse diese die Verständlichkeit erproben.
• Kategorie:Vorlage:Navigationsleiste Vorlagen hätte ich erwartet.

VG --PerfektesChaos 19:21, 23. Jan. 2021 (CET)

Was genau tun die Ausführungen zu dieser meiner Privatnavigation jetzt zur Sache? Ich nehme die Anregungen gerne zur Kenntnis, aber das hilft hier auch nicht weiter.

Es ging um den Umgang der Vorlage:Auflistung mit mehreren Aufzählungsbenen. Brauchbareres Beispiel wäre etwa en:Template:Former French colonies in Asia and Oceania (mal unabhängig von der Frage, ob das so als Navigation taugt, nach deWP-Maßstäben wohl kaum). Über Vorlage:Auflistung sehe ich hier nur die Umsetzung durch einfache Klammern mit Inhalt innerhalb eines Aufzählungspunktes, wie das auch jetzt schon gemacht würde. Oder eine ganz andere Konzeption, keine Ahnung. Semantisch sinnvoller sind mehrere Aufzählungsebenen, wenn das in dieser Vorlage nicht gewollt/gewünscht ist, dann ist das eben so. Gruß–XanonymusX (Diskussion) 20:50, 23. Jan. 2021 (CET)

Dark

Weil es mir zufällig aufgefallen ist: In den Wikipedia-Apps gibt es ja einen eingebauten Dark Mode. Der funktioniert offenbar reichlich schlecht, was nicht zuletzt bei dieser Vorlage zum Vorschein kommt: Der transparente Trenner wird plötzlich überall wieder sichtbar! Verstehe nicht wirklich, wie es dazu kommt. Das Dark-Mode-Gadget macht hingegen keine Probleme. Ich hoffe nur, dass die Dark-Mode-Extension, die in Entwicklung ist, nicht auf dem Modus der App basiert. --XanonymusX (Diskussion) 01:11, 4. Mär. 2022 (CET)

Das Dark-Mode-Geschwätz für Wikis ist sowieso ein totgeborenes Kind, ersonnen von lernbefreiten geistigen Tieffliegern.

• Das funktioniert auf Facebook, Twitter usw., die keinen User-gestylten Text kennnen, sondern nur weiß, schwarz, blau und Fotos.
• Bei uns gibt es Millionen von Seiten, die sich darauf verlassen, dass bestimmte Hintergrundfarben vorliegen, und Grafiken aller Art einen hellen Hintergrund benötigen, weil es dunkle Elemente auf transparent sind, und andere einen dunklen Hintergrund herstellen und dann eine helle Grafik auf transparent zeigen.
• Und auch der vielbeschworene „intelligente Farbwechsel“ versagt beim Revierderby #Spiele zwischen Borussia Dortmund und dem FC Schalke 04 und liefert wahlweise
  • Borussia Dortmund – FC Schalke 04
  • Borussia Dortmund – FC Schalke 04

Warum das nicht funktioniert, ist ganz simpel: Die schreiben die resultierenden Farben in den Zuweisungen um, und haben dementsprechend irgendwas nicht begriffen. Wahrscheinlich war ihnen transparent schon zu hoch.

Ich weigere mich grundsätzlich, diesen Schwachsinn zur Kenntnis zu nehmen, und ich bitte eindringlich, zukünftig meine Kraft und Nerven und Arbeitszeit mit derartigen Luftnummer-Hinweisen zu verschonen.

• Diese Anmerkungen bei jeder erdenklichen Vorlage zu platzieren, damit zog erst neulich so ein Honk durch den Vorlagen-Namensraum und forderte die Umprogrammierung von Infoboxen.

Wer abends Dark möchte, soll seinen Blau-Anteil runterregeln; mein Laptop macht das vollautomatisch zwischen 21:00 und 06:00.

VG --PerfektesChaos 16:32, 4. Mär. 2022 (CET)