Vorlage Diskussion:Löschkandidatenseite

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 2 Monaten von Doc Taxon in Abschnitt Gestaltung der Info
Zur Navigation springen Zur Suche springen

Gestaltung der Datumslinks[Quelltext bearbeiten]

Nachdem wir uns wohl einiogermaßen einig sind, dass dort keine Tabelle hin darf, bitte ich hier um Gestaltungsvorschläge, soweit das Bestehende nicht gefällt. ÅñŧóñŜûŝî (Ð) 18:07, 9. Okt. 2023 (CEST)Beantworten

Ehrlich gesagt hat mir die bisherige Gestaltung schon recht gut gefallen. --Matthiasb – (CallMyCenter) Wikinews ist nebenan! 14:14, 10. Okt. 2023 (CEST)Beantworten
Das mag schon sein. Mir hat sie, von der Rahmenfarbe abgesehen, auch gefallen. Bedauerlicherweise ist so eine Layout-Tabelle zum einen für mobilen Zugriff recht schlecht geeignet und zum anderen auch nicht barrierefrei. Siehe dazu die vorrausgegangene Diskussion unter Wikipedia Diskussion:Löschkandidaten. Gruß von ÅñŧóñŜûŝî (Ð) 19:21, 10. Okt. 2023 (CEST)Beantworten
Hallöchen. Bei mir funktioniert die Zeile auf allen Geräten die ich nutze perfekt und mir gefällt auch die Lösung, dass die Links jetzt mittig sind. Gerade auf dem iPhone muss ich dadurch nun nicht mehr zwischen den Daten scrollen. Greets --איזבלה「Ysabella」Geredt mit di Ysa du vunderlakhe Mentsh 04:25, 11. Okt. 2023 (CEST)Beantworten
Ich würde gerne links ein weiteres Datum ergänzen. Das hätte den Vorteil, von der aktuellen Tagesseite mit einem Klick auf die anderen Tage der Standardfrist zu gelangen. ÅñŧóñŜûŝî (Ð) 23:11, 15. Okt. 2023 (CEST)Beantworten

Gestaltung der Info[Quelltext bearbeiten]

Wir müssen auch klären, was an der Info geändert werden sollte. Vorschläge erbeten. ÅñŧóñŜûŝî (Ð) 18:09, 9. Okt. 2023 (CEST)Beantworten

Ich fange mal an und plädiere dafür, dass der Fließtext nicht zentriert wird. ÅñŧóñŜûŝî (Ð) 18:15, 9. Okt. 2023 (CEST)Beantworten
Du plädierst dafür und setzt es schon mal um, toll. Momentan sieht die Vorlage mal wieder extraschlimm aus. Ich wünsche mir nur noch eins, nämlich den ganzen Kasten einschließlich schwarzen Unterstrichs ausblenden zu können. Dazu den Strich bitte in ein div mit class packen oder was auch immer.--Berita (Diskussion) 00:11, 11. Okt. 2023 (CEST)Beantworten
Ich habe jetzt selbst ids ergänzt, mit denen man alles oder Teile ausblenden kann. Damit bin ich hier soweit raus, ich bezweifle, dass es zu einem Konsens kommt, anscheinend geht es jetzt vor allem darum, dass es auf bestimmten Handys gut aussieht, Leute mit PC sehen alt aus.--Berita (Diskussion) 00:50, 11. Okt. 2023 (CEST)Beantworten
Einen Konsens darüber, was "schön" aussieht, wird niemals möglich sein. Da muss jeder Abstiche machen. Es muss hauptsächlich mal lesbar und verständlich sein. Lesbarkeit - auch für Screenreader - erreicht man u. A. auch durch möglichst große Darstellung und deshalb optisch einfacher, normaler Fließtext ohne "Seitenlinien". Die horiz. Linien waren schon immer drin. Bei der Einbindung muss es eine Absetzung vom anschließenden Seiteninhalt geben. Kann man unterschiedlich umsetzen. Viel wichtiger wäre es, die Verständlichkeit zu erhöhen. ÅñŧóñŜûŝî (Ð) 01:52, 11. Okt. 2023 (CEST)Beantworten
Auf der Vorlagenseite wird im Moment ein Tagesaktuelles Beispiel "Kategorie" eingeblendet. Dies ist extrem verwirrend und sollte dort raus und nützt dort ehrlich gesagt auch nichts. --איזבלה「Ysabella」Geredt mit di Ysa du vunderlakhe Mentsh 04:32, 11. Okt. 2023 (CEST)Beantworten
Einen Konsens darüber, was "schön" aussieht, wird niemals möglich sein – ja, dann hättest du aber doch besser gleich einfach mal ganz die Finger davon gelassen, statt hier deine Privatvorstellungen durchzusetzen. Die aktuelle, maximal potthässliche Form ist inakzeptabel, insbesondere der schwarze Unterstrich. --Icodense 18:03, 12. Okt. 2023 (CEST)Beantworten
Ich hab diesen imho maximalen Unsinn, den Kasten zu entfernen, aber dann oben und unten zwei einzelne Striche zu machen, jetzt beseitigt. Auch weitere solche Änderungen werde ich konsequent elimieren. --Icodense 18:17, 12. Okt. 2023 (CEST)Beantworten
Hallo @Icodense99. Falls die Vorlage trotzdem nicht gelöscht wird, kannst du diesen eingeblendeten "Kategorien-Quatsch" da im eingeblendeten Beispiel rausnehmen? Ich weiss leider nicht wie, aber ich halte dies für unnötig. Grüsse --איזבלה「Ysabella」Geredt mit di Ysa du vunderlakhe Mentsh 23:12, 13. Okt. 2023 (CEST)Beantworten
Das ist kein Quatsch sondern das sind zumindest teilweise LAs wie andere auch. Sie tauchen auf, weil Benutzer:Doc Taxon am 6. Oktober die Einbindung der Kategorie-LDs in die vorlage integriert hat, um das nicht auf jeder LD-Seite zu wiederholen. Ich habe diese jetzt mal mit einer Seitenabhängigkeit versehen. Damit dürfte das einiugermaßen behoben sein. ÅñŧóñŜûŝî (Ð) 14:21, 14. Okt. 2023 (CEST)Beantworten
Das es richtige LA's waren ist auch mir klar, aber braucht man hier nun nicht als Beispiel einzublenden. Wie es genau ausschaut sieht man ja seit dem 30. September an jeder aktuellen Seite. Hab Dank für's entfernen. --איזבלה「Ysabella」Geredt mit di Ysa du vunderlakhe Mentsh 14:57, 14. Okt. 2023 (CEST)Beantworten
Danke. ÅñŧóñŜûŝî (Ð) 16:45, 14. Okt. 2023 (CEST)Beantworten
Danke für das Maskieren des Kategorienabschnitts, da war ich nicht sofort drauf gekommen. Übrigens, wer sagt denn eigentlich, dass zentrierte Texte nicht vom Screenreader gelesen werden können. Vielleicht war das mal so, aber heute können die das ganz gut. – Doc TaxonDisk.14:00, 15. Okt. 2023 (CEST)Beantworten
Der hatte besonders mit der alten Tabelle Probleme. Gemäß Angaben mehrerer Personen in meinem Umfeld gibt es (evtl alte?) Screenreader, welche mit einer Tabelle nicht so gut klar kommen. Da gibt es wohl erklärende Einfügungen wie "Beginn Tabelle" "erste Zeile" etc. Wenn die Tabelle aber nur dem Layout dient, ist das überflüssig. Außerdem macht die Layout-Tabelle bei Smartphones Probleme. Bei mir z. B. wird bei meinem privaten Handy und Firefox-Browser alles auf Screenbreite gedrückt (kein horiz. Scrollen) und der Zelleninhalt erscheint winzig mit viel Platz drumherum. Das hängt wohl vom Phone und von der App ab. Darüber hinaus war bisher alles auf 90% Breite gesetzt. Auch völlig unnötig. Jetzt ist es normal lesbar. Der zentrierte Text ist eher ein Problem für Personen, welche eingeschränkt sehen und lesen können. Denen passiert es bei Zentrierung häufiger, in der Zeile zu verrutschen. ÅñŧóñŜûŝî (Ð) 21:02, 15. Okt. 2023 (CEST)Beantworten
Das Problem ist nicht, dass Handys alles auf Screenbreite drücken oder ziehen und damit Texte klein machen und viel Platz entsteht – das Problem ist, dass wir in Sachen Styles und Design nicht zwischen Desktops und Mobiles unterscheiden (können oder auch wollen). In Sachen Software WMF wäre es gut, wenn Styles und Design für Mobiles umgerechnet oder transformiert würden, an zig tausend Ecken wurde danach schon geschrien, passiert ist kaum was, obwohl das so schwer eigentlich gar nicht ist, jedenfalls heute nicht mehr. Uns bleibt also nur, sämtliche Vorlagen und gewohnte Designs zu verändern, was viele Benutzer auch ärgert. @Thiemo Kreuz (WMDE): Kann WMDE nicht bei WMF ein ernst gemeintes Ohr finden, solche Dinge schon softwaretechnisch grundsätzlich zu ermöglichen? Vielen Dank an alle, die sich das antun. – Doc TaxonDisk.21:34, 15. Okt. 2023 (CEST)Beantworten
Layouttabellen sind ganz allgemein unflexibel in Bezug auf die heute sehr verschiedenen Zugriffe (Client-Umgebungen). Deshalb sollten sie weitestmöglich vermieden werden. Solange nicht mehr umgekrempelt werden muss, als eine derartige Tabelle zu ersetzen, kann man das doch aushalten. Das Bessere ist der gefährlichste Feind des Guten. ÅñŧóñŜûŝî (Ð) 23:09, 15. Okt. 2023 (CEST)Beantworten
  1. Es geht um die barrierefreie Navigation.
    • Dazu sind Tabellen grundsätzlich ungeeignet.
      • Tabellen, mit denen nur eine optische Anordnung bewirkt oder gar nicht-responsiv erzwungen werden sollen, heißen „Layout-Tabellen“.
      • Wir schmeißen sowas systematisch raus, mindestens aus Funktionsseiten.
      • Tabellen sind ausschließlich für strukturierte Daten zu verwenden.
    • Mittel der Wahl sind Aufzählungen.
      • Sie können über Tab navigiert, von Element zu Element gesprungen und abgebrochen werden.
      • Sie sagen vorher, dass jetzt eine Aufzählung kommt. Tab geht zum ersten Element; Esc bricht jederzeit diese Aufzählung ab und springt zum nachfolgenden Block.
    • Seit zwei Jahrzehnten ist der Portalrahmen aller Wiki-Skins als derartige Aufzählung organisiert; sowohl vertikal wie auch oben horizontal. Aus Gründen.
    • Geht mit * bzw. # oder Vorlage:Auflistung.
    • Bei einer Tabelle kommt erstmal die Frage: „Möchten Sie die Tabelle zu einem unbekannten Thema öffnen?“
      • „Diese Tabelle hat keine Spaltenüberschriften.“
      • „Zu welcher Zeile und Spalte möchten Sie navigieren?“
      • Wenn jemand nicht sehen und überblicken kann, was das alles ist, was für Elemente ingesamt zur Auswahl stehen, dann ist mit sowas übel gekniffen.
  2. „Sowas gibt es in keiner anderen Funktionsseite“, beschwerte sich kürzlich jemand, die hätten alle so eine Box um die gesamte Intro.
    • Alle Funktionsseiten mit dieser Box drumrum sind ca. 2007 unter Desktop-Bedingungen und ohne Gedanken an Barrierefreiheit entstanden.
    • Alle diese Seiten bzw. Intros sind Sanierungsfälle.
    • Eine Argumentation ist unredlich, die sich darauf beruft, alle anderen vergleichbaren Seiten wären ja auch nur für Desktops gedacht und deshalb müssen auch weiterhin alle Funktionsseiten gleichmäßig Smartphones benachteiligen und deren Bildschirmplatz vergeuden.
    • Diese Box-Einteilungen vergeuden für die vertikalen Linien Platz links und rechts. Sie verhindern, dass die gesamte Intro und möglichst noch das Inhaltsverzeichnis auf den Smartphone-Bildschirm passt. Sie sind teils nicht responsiv, d. h. sie verhindern mittels Layout-Tabellen (eins vor) eine dem Endgerät angemessene Darstellung und erzwingen Desktop-Aufteilungen.
    • In Sachen der diversen Motivationscomics hatte ich bereits eingegriffen; Screenreader erfahren von deren Existenz überhaupt nichts, und sie würden auch nicht weiterhelfen.
    • Vor einigen Jahren ist mal in einem Kraftakt die Hauptseite mobilgerecht responsiv und barrierefrei umgestellt worden. Nach Erarbeitung und Erörterung auf BETA, und produktiver Implementierung erst nachdem alles passte. Das geht auch nicht in lauter kleinen Schrittchen, weil es einer Gesamtkonzeption bedarf, in die alle Einzelkomponenten eingepasst werden müssen. Und natürlich muss der Ort, an dem die jeweils aktuellen MockUps besichtigt werden können, allgemein kommuniziert werden, und dann kann über Verbesserungen daran diskutiert werden.
  3. Wenn wir über Layout-Tabellen bestimmte Desktop-Designs erzwingen, kann keine Software daran noch etwas ändern.
    • Die Vorstellung, man könnte schlechte Konzepte aus den Nuller Jahren beibehalten, aber irgendeine Zauber-Software könne irgendwas daran rummachen, damit alles bleibt wie es ist und gleichzeitig alles anders wird, ist nicht umsetzbar.
    • Vom Publikum wird gewünscht, dass Desktop und Mobil sich möglichst ähneln sollen, wenn von mobil nach Desktop nach mobil nach Desktop gewechselt wird. Es sind dieselben Seiten, dieselben Inhalte; aber deren Details dürfen nicht explizit vorgeschrieben werden, sondern das Endgerät muss die Freiheit bekommen, es den aktuellen Bedingungen entsprechend anzuordnen.
    • Man muss der Software ja erklären und fordern, was sie eigentlich präsentieren soll. Und wenn man das falsch beschreibt und von jedem Detail verlangt, es müsse aber ganz genau so und so gemacht werden, dann kann es hinterher auch keine Super-Software mehr rausreißen.

VG --PerfektesChaos 00:02, 16. Okt. 2023 (CEST)Beantworten

Danke für diese ausführliche Stellungnahme. Krempeln wir also die Ärmel hoch und legen zuerst einmal möglichst genau die Zielsetzung fest. Ich sehe da folgende Aufgaben:
  • Der Seitenkopf muss die Funktion der Seite erklären und dabei zumindest als weiterführende Links auf Löschregeln und LA-Prozedur verweisen.
  • Einfaches Eintragen einer Seite. Dafür haben wir bisher den Button.
  • Den Rahmen hatte ich schon mal entfernt. Das brachte mir unverhältnismäßig heftigen Protest ein.
  • Die Datumsleiste, jetzt nur noch ein Div-Tag mit Span-Tags darin, soll leichtes navigieren von "heute" auf die letzten sechs Tage ermöglichen.
Dazu hätte ich noch folgende Fragen:
  1. Ist der Button barrierefrei?
  2. Stören einfache horiz. Linien die Barrierefreiheit?
ÅñŧóñŜûŝî (Ð) 19:11, 16. Okt. 2023 (CEST)Beantworten
Ja, wozu da ein Rahmen drum muss, habe ich bis heute nicht kapiert. @Berita: wenn ich mich nicht täusche, wolltest Du, glaube ich, einen Rahmen drum haben, oder? Und die Autorenportal-Liste wie auf WP:LK sollten wir angepasst auch mit einbauen, um schnell auf themenrelevante Seiten navigieren zu können (dort einen Link auf RK mit einbauen und auf Kategorie:Wikipedia:Schnelllöschen) – Doc TaxonDisk.20:50, 16. Okt. 2023 (CEST)Beantworten

Gestaltung der Info - TemplateStyles[Quelltext bearbeiten]

Da ich oben angesprochen wurde, möchte ich hier kurz aus meiner Sicht als MediaWiki-Softwareentwickler reagieren:

  • Ausgewogene Barrierefreiheit, die allen zugute kommt, erfordert viel Fingerspitzengefühl. Gemeinplätze wie „Tabellen sind grundsätzlich ungeeignet“ sind nicht zielführend.
  • Barrierefreiheit auf Screenreader zu reduzieren ist ebenso wenig hilfreich.
  • Screenreader lassen sich mit ARIA-Attributen sehr feingliedrig steuern. Seit 2016 sind die auch in der Wiki-Syntax nutzbar. Hier bieten sich ganz konkret role="banner" für die gesamte Tabelle und evtl. role="navigation" und role="search" für die entsprechenden Teile der Tabellen an.
  • Die Trennung zwischen Desktop und Mobil gilt inzwischen als veraltet und wird schrittweise abgebaut. Statt dessen setzen wir beispielsweise auf Media Queries, die dank TemplateStyles auch in Vorlagen nutzbar sind.
  • Die relativ neue Echtzeit-Vorschau im Wikitext-Editor bietet eine gute Möglichkeit, schon während des Editierend zu testen, wie gut Artikel und Vorlagen auf schmalen Bildschirmen funktioniert.

Ich hoffe, das hilft der Diskussion weiter. --Thiemo Kreuz (WMDE) 09:49, 17. Okt. 2023 (CEST)Beantworten

@Thiemo Kreuz (WMDE): Das sind gewiss wichtige Sachinformationen. Bleibt die Frage, ob die TemplateStyles auch korrekt im Browser umgesetzt werden. ÅñŧóñŜûŝî (Ð) 18:52, 17. Okt. 2023 (CEST)Beantworten
@Antonsusi: na das ist aber Sache des anwendenden Programmierers. Er sollte das dann auch testen. Auch dafür bietet sich Beta an. – Doc TaxonDisk.18:57, 17. Okt. 2023 (CEST)Beantworten
Gewiss. Es dürfte aber ein ziemlicher Aufwand sein. Nehmen wir mal an, du willst testweise bei Screens mit mind. HD Überschriften mit 200px darstellen, ansonsten nur 100px. In einer Datei wäre das dann:
	<style>
	@media screen   {
	h2 {font-size:100px;}
	}
	@media screen and  (min-device-width: 1920px)   {
	h2 {font-size:200px;}
	}
	</style>

Wenn du das auf einer CSS-Unterseite einträgst und per TemplateStyles einbindest, dann kanst du damit nur alle oder keine Überschrift ansprechen, denn die zwei "=" hintereinander erlauben im Unterschied zum H2-Tag von HTML keine Attribute. ÅñŧóñŜûŝî (Ð) 19:13, 17. Okt. 2023 (CEST)Beantworten

@Antonsusi: In der umseitigen Vorlage ist doch gar keine Überschrift verbaut oder überseh ich die. Für den Kategorienabschnitt kann das vernachlässigt werden, denn damit kommt ja alles klar. – Doc TaxonDisk.19:27, 17. Okt. 2023 (CEST)Beantworten
Ich sortier mal.
  • „Stören einfache horiz. Linien die Barrierefreiheit?“
    • Horizontale Linien haben keinen Einfluss; sie existieren schlicht nicht.
    • Genausowenig ein div ohne sehr spezielle Attribute, das allenfalls einen neuen Block ankündigt.
  • „Ist der Button barrierefrei?“
    • Aber sowas von.
    • Weil mit role="button" ausgestattet und damit kein normales Text-Element mehr, sondern über Formularnavigation ansteuerbar.
  • „Datumsleiste, jetzt nur noch ein Div-Tag mit Span-Tags darin, soll leichtes navigieren von "heute" auf die letzten sechs Tage ermöglichen“
    • Macht es für Sehende.
    • Ist aber kein „leichtes navigieren“ für Screenreader/Blinde, weil keine Tab-Navigation unterstützt wird und das einfach nur als völlig konfuser Fließtext vorgelesen wird und kein Ende findet.
    • Wir haben auch Leute (etwa 10 % des Publikums), die diese kleinen Kullerchen zwischen den Elementen in horizontalen Auflistungen nicht als existent und gar wichtig wahrnehmen können. Die selbstbezogenen Privatgeschmackler mit den Adleraugen beschweren sich dann seit jeher, die sichtbaren Kuller wären ihnen zu klobig und ihre Ästhetik bekäme einen Schaden.
  • „Media Queries […] TemplateStyles“
    • Es gibt kaum eine Handvoll Leutchen in der deWP, die damit umgehen könnten.
    • Die müssen auch alle Lua-Module, JavaScript und Hunderte andere Geschichten pflegen.
    • Nicht nur Artikel, sondern die Grundgestaltung von Meta-Seiten muss von möglichst vielen mit Basis-Wikitext-Kenntnissen gepflegt werden können.
    • Die einzige offizielle Seite mit sowas ist die Hauptseite, nach einem extrem anstrengenden Kraftakt, und dann gibt es noch diverse Portalseiten usw. als Bastelarbeiten von Einzeltätern.
  • „Die Trennung zwischen Desktop und Mobil gilt inzwischen als veraltet“
    • Wir wollen hier keine „Trennung zwischen Desktop und Mobil“.
    • Wir wollen Seiten, die mit ein und demselben Wikitext auf allen Geräten von Armbanduhr bis Kinoleinwand gut darstellbar sind.
    • Dabei verbieten sich Elemente, die insbesondere für Desktop ein bestimmtes Layout zu optischen Zwecken erzwingen.
    • Schon die meisten Wikipedistas überfordernd sind Flex-Gestaltungen von Blöcken, die responsiv nebeneinander, auf dem Smartphone jedoch untereinander dargestellt werden.
    • Wir fordern die gleiche Seitenstruktur derselben Seite, die je nach Situation am Endgerät (Schrift, Fensterbreite usw.) mit den schon im letzten Jahrhundert bekannten Möglichkeiten beim Wechsel Mobil → Desktop → Mobil → Desktop inhaltlich und funktional weitgehend gleich bleibt, und nur durch die unterschiedlichen Bildschirmfenstergrößen bedingt eine angepasste Anordnung derselben Elemente vornimmt.
    • Dabei muss der Wikitext von möglichst vielen pflegbar bleiben, vielleicht mit Ausnahme des Sonder- und Einzelfalls Hauptseite.
  • role="banner" für die gesamte Tabelle
    • Weiß nicht.
    • Das erklärt den gesamten Bereich zur ausblendbaren Reklame, also überflüssig und überspringbar.
    • Da stehen aber wesentliche Infos drin, vom neuen Abschnitt über den Erledigt-Status. Oder was immer ein Banner und eine gesamte Tabelle sein mag.
  • Der Sinn und Zweck des in diesem Abschnitts angegebenen CSS-Codes erschließt sich mir nicht.
    • Solche Verkomplizierungs-Dramen sind völlig überflüssig für die Löschkandidaten oder andere Funktionsseiten.
    • Niemand kann das dann noch warten oder pflegen, und es wird auch nicht benötigt.
    • Es werden ganz schlicht und simpel nur Elemente verwendet, die sowohl Mobil wie Desktop wie Screenreader sinnvolle Ergebnisse liefern, und für Sehende sieht alles weitgehend gleich aus. Bloß dass die einen einen schmalen Bildschirm haben, andere einen Desktop oder eine Kinoleinwand.
Warum erscheint der ganze Neue-Abschnitte-anlegen-Kram denn immer noch, wenn heute längst nicht mehr heute ist?
  • In der LD von gestern oder vor einem Jahr oder drei Tagen gibt es keine neuen Abschnitte weil keine neuen Kandidaten mehr.
VG --PerfektesChaos 19:33, 17. Okt. 2023 (CEST)Beantworten
Hm, zur Sache Media Queries / TemplateStyles: @Thiemo Kreuz (WMDE): Wenn wir nur eine Handvoll Leutchen in deWP haben, die sowas hinzaubern können bzw. die Zeit auch haben, sowas hinzaubern zu können, ist es dann nicht möglich, auf Dich und Deine Softwareentwickler-Kollegen zurückzukommen, die uns dabei helfen könnten? Schließlich habt Ihr gute Kenntnisse (und könntet nebenbei, wenn es sich ergibt, auch Vielfach- oder Globalverwendungen in die MediaWiki-Software einbringen). Ich sehe hier ein größeres Projekt zwischen WMDE/WMF und dewiki bzw. programmierende Benutzer, die Wikipedia verbessern und Barrieren nebenbei ausräumen wollen. Vielleicht können wir da etwas größeres bewegen. Kannst Du das innerhalb WMDE mal im Team irgendwo ansprechen? – Doc TaxonDisk.20:00, 17. Okt. 2023 (CEST)Beantworten
@PerfektesChaos:
  • Einfache horiz. Linien: meinst du mit "existieren nicht", dass der Screenreader sie ignoriert?
  • Der Quelltext ist ein allgemeines fiktives Beispiel um aufzuzeigen, dass wir hier auch noch das Parsen vom Wiki-Quelltext zur Erstellung von HTML beachten müssen, was Einschränkungen ergibt. Mir ist keine Möglichkeit bekannt, einer per == erzeugten Überschrift zwecks eindeutigem Selektor eine ID zuzuordnen,
  • Viel einfacher als ein Div-Tag mit Span-Tags darin geht kaum noch. Allenfalls noch eine Auflistung per "*", also das Ul-Tag in HTML. Das bewirkt aber separate Zeilen und dürfte wohl kaum akzeptiert werden, weil das bei "Kinoleinwand" viel Leerraum erzeugt. Jetzt bricht die Aufzählung dort um, wo beim Leser der rechte Rand ist. Das ist eindeutig ein Schritt in Richtung Anpassung an den Client.
  • Media Queries sind keine Zauberei. Kann man u. A. auf dieser Seite detailliert finden. Wer Vorlagen schreibt, der sollte auch damit klar kommen.
ÅñŧóñŜûŝî (Ð) 20:50, 17. Okt. 2023 (CEST)Beantworten
@Doc Taxon: Es gibt hier genügend User, welche Media Queries umsetzen können. Es fehlt eher an der Akzeptanz durch Andere und es birgt viel Streitpotenzial. ÅñŧóñŜûŝî (Ð) 20:50, 17. Okt. 2023 (CEST)Beantworten

Es ist völlig überflüsssig, für diese Funktionsseite irgendwelche TemplateStyles oder Media Queries einzuführen, weil sie völlig unnötig und ein absoluter Holzweg sind.

  • Und noch viel gefährlicher wäre es, dass wir unsere Wikitext-Seiten so überkandidelt und mit sinnlosem CSS überfrachten, dass sie nur noch von extern bezahltem Software-Personal gepflegt werden könnten.
  • Es braucht diesen ganzen hier einleitend vorgeschlagenen Mist überhaupt nicht. Es reicht völlig, diejenigen Elemente nicht zu verwenden, die sowohl im enzyklopädischen Artikel wie auch auf einer Funktionsseite eine ganz bestimmte Desktop-Optik erzwingen sollen.
  • Das Theater, auch mit Kasten drumrum, ist eine Wiederholung der alten, alten Melodie: Die deWP muss auf ewige Zeiten immer ganz genauso aussehen wie sie damals, 2005 – oder hier 2008 – mal ausgesehn hatte, und ohne persönliche Genehmigung jedes einzelnen Wikkifanten darf nichts nirgendwo verändert werden.
  • Der Weg, wie man ein auf allen Geräten wirksames Design erreicht, ist ganz simpel und war schon im letzten Jahrhundert bekannt gewesen: Keine Tabellen verwenden, es sei denn für strukturierte Daten, also keine Layout-Tabellen. Das wusste man schon 1998. Obendrein dann auch für Screenreader navigierbar.

Den jetzt gebildeten Abschnitt eröffnend findet sich das Zitat: „aus meiner Sicht als MediaWiki-Softwareentwickler“

  • Ich weiß nicht so ganz, was dieser Begriff implizieren soll, nur die eigene Position oder diejenigen, die unsere Artikel-Quelltexte und Funktionsseiten pflegen.
  • Letzteres machen grad keine „MediaWiki-Softwareentwickler“, sondern recht normale Menschen mit mäßigen Vorkenntnissen.

Einfache horiz. Linien: meinst du mit "existieren nicht", dass der Screenreader sie ignoriert?

  • Ja.
  • Wie soll er denn eine optische Dekoration vorlesen?
  • Sie existieren für Screenreader nicht. Übrigens in aller Regel auch alles CSS ausgenommen display:none und vielleicht visibility:hidden mit Glück.

Allenfalls noch eine Auflistung per "*", also das Ul-Tag in HTML. Das bewirkt aber separate Zeilen und dürfte wohl kaum akzeptiert werden, weil das bei "Kinoleinwand" viel Leerraum erzeugt.

  • Die Vorlage:Auflistung #Barrierefreiheit bewirkt keine separaten Zeilen, und wird auch nicht von HD-Kinoleinwand-Bildschirmen beeinflusst.
  • Übrigens hatte ich einen Bildschirmkilometer weiter oben bereits einmal empfohlen, diese Navigation über Datum vorher, später und hilfreiche Richtlinienseiten rechts außen anzuordnen, wie das bei Hunderten anderer Seiten ggf. auch kontextsensitiv gemacht wird.

VG --PerfektesChaos 21:17, 17. Okt. 2023 (CEST)Beantworten

Ich bin hier für alles offen, was nützt. Wenn hier aber bereits das Umwandeln der Layouttabelle in ein Div-Tag derart viel Zoff erzeugt, obwohl das zumindest für Mobilgeräte schon mal ein Vorteil ist, weil der Kopf der LD-Seiten nicht mehr exakt so aussieht wie zuvor, dann ist da ein dickes Brett zu bohren. Ich bin mit allem einverstanden, was auf möglichst vielen Medien und für möglichst viele Leser / Hörer les- bzw. hörbar ist. Für User, welche gelegentlich Seiten drucken, sollten Metaseiten m. E. weitestgehend auf Farbe verzichten, zumindest bei Druckansicht. Ich z. B. Drucke bevorzugt mit S/W-Laserdrucker, also Graustufen. ÅñŧóñŜûŝî (Ð) 21:45, 17. Okt. 2023 (CEST)Beantworten
Das ist auch total albern: der LD-Kopf muss nicht mal annähernd so aussehen wie jetzt (es ist nur eine Service-Seite), wir sollten Barrierefreiheit, Mobillesbarkeit und Navigierbarkeit an erste Stelle setzen und dann ist schon alles gut. – Doc TaxonDisk.21:58, 17. Okt. 2023 (CEST)Beantworten
Ich frag mal ganz kurz die Admins drüben auf WP:AADoc TaxonDisk.21:59, 17. Okt. 2023 (CEST)Beantworten
Warum? Das bekommen wir hier doch ohne Admins hin. Die von PerfektesChaos erwähnte Vorlage - selbstverständlich seine Kreation ein lächelnder SmileyVorlage:Smiley/Wartung/:-)  - finde ich gut. Ich setz das mal ein. Macht optisch fast keinen unterschied. Wir werden dann ja sehen, wer hier alles mehr oder weniger hysterisch aufschreit... ÅñŧóñŜûŝî (Ð) 22:15, 17. Okt. 2023 (CEST)Beantworten
Damit werden wir aber nichts gewinnen – wenn denn jemand aufschreit. – Doc TaxonDisk.22:27, 17. Okt. 2023 (CEST)Beantworten
@Antonsusi: Mach die Umsetzung nach PC erst mal auf Beta, damit wir mit einer perfekten Lösung des Seitenkopfes zurückkommen können. Danke sehr, – Doc TaxonDisk.22:35, 17. Okt. 2023 (CEST)Beantworten
Beta ist eine feine Sache. Der große Nachteil: Keiner aus der "Nichts-Verändern-Fraktion" wird sich dort melden. Hast du dann alles fertig und überträgst dein "perfektes Ergebnis", dann gibt es hier trotzdem (extra viel) Zoff. Das ist, wie wenn du eine große Tiefgarage zusperren willst: Wenn du laut rufst: "Ist hier noch jemand drin?", dann bekommst du keine Antwort. Schaltest du aber testweise einfach das Licht aus, dann wirst du, wenn noch jemand drin ist, einen lauten Protest hören. Die größten Motzer und Protestierer sind genau die User, welche sich im Vorfeld garantiert nicht zu Wort melden. Beta ist sinnvoll, es erspart aber nur funktionelle, inhaltliche oder SW-Fehler. Mehr Konsens erreicht man damit nicht. Meinetwegen können wir auf Beta vorbereiten, aber ich bezweifle, dass damit Streit gemindert wird. ÅñŧóñŜûŝî (Ð) 22:49, 17. Okt. 2023 (CEST)Beantworten

Gestaltung der Info - Datumslinks[Quelltext bearbeiten]

Ich habe dir das auf den obigen Bildschirmkilometern bereits dreimal und im letzten Jahrzehnt bereits zigmal erklärt:
  • Diskutiert wird weiterhin genau hier; zumindest in der echten deWP.
  • Es wird jedoch von hier aus auf die MockUp-Seiten auf BETA verlinkt, auf denen die Entwurfsfassungen auf Dummy-LD eingebunden sind, damit das Aussehen im Kontext des Seitendatums relativ zu „heute“ dargestellt werden kann.
  • Kein Mensch erwartet, dass Mitleser auf BETA sich von sich aus an irgendwas beteiligen würden, denn die befassen sich wenn zufällig anwesend mit ihrem eigenen Kram.
VG --PerfektesChaos 22:54, 17. Okt. 2023 (CEST)Beantworten
Genau so! Insbesondere Punkt 2! Natürlich wird hier diskutiert. Beta ist nur zum Testen und Zeigen da. – Doc TaxonDisk.23:12, 17. Okt. 2023 (CEST)Beantworten
@Antonsusi: Was sagst Du zu diesem PCs Punkt: "Übrigens hatte ich einen Bildschirmkilometer weiter oben bereits einmal empfohlen, diese Navigation über Datum vorher, später und hilfreiche Richtlinienseiten rechts außen anzuordnen, wie das bei Hunderten anderer Seiten ggf. auch kontextsensitiv gemacht wird." Ich finde das auch ziemlich gut. – Doc TaxonDisk.23:18, 17. Okt. 2023 (CEST)Beantworten
@PC: zum Neue-Abschnitte-anlegen-Kram auf gestrigen Seiten: nun dort steht drunter geklammert "(auf der aktuellen Seite)". Aber egal, auf gestrigen Seiten braucht es das auch meiner Meinung nach nicht. – Doc TaxonDisk.23:26, 17. Okt. 2023 (CEST)Beantworten
Eine einfache "ein Tag davor - Ein Tag danach"-Verlinkung ist m. E. unzureichend. Da muss man sich ja entweder tageweise durchhangeln oder im Suchfenster direkt eintippen. Eine weitere Möglichkeit wäre es, einen Unterschied zwischen den letzten sieben Tagen und anderen Seiten zu machen. Ich plädiere dafür, diese Tage von allen Seiten aus zu verlinken und für andere Tage eine separate Lösung zu erstellen. ÅñŧóñŜûŝî (Ð) 07:15, 18. Okt. 2023 (CEST)Beantworten
@Antonsusi: Das war auch eher beispielhaft gemeint, die Menge der Tage sollte schon wie vorher bleiben. – Doc TaxonDisk.11:03, 18. Okt. 2023 (CEST)Beantworten
warum sollen denn nicht die aktuellen Seiten immer drauf sein? Das wäre dann:
Funktioniert auch. ÅñŧóñŜûŝî (Ð) 20:40, 18. Okt. 2023 (CEST)Beantworten
Nein, fände ich besser, wenn die Tage per Datum gelistet werden, wie jetzt auch schon, damit man die Tage nicht zurückrechnen braucht. Wir sollten's so einfach wie möglich halten. – Doc TaxonDisk.21:41, 18. Okt. 2023 (CEST)Beantworten
@PerfektesChaos: Hattest Du die schicken beta-Versionen noch einmal überarbeitet? – Doc TaxonDisk.16:07, 24. Feb. 2024 (CET)Beantworten
Ich hatte auf BETA irgendwas gemacht, aber längst vergessen worum es irgendwann ging. Der dortige Stand mag bestaunt werden.
Wegen gleichzeitig ausgebrochener Dramen habe ich diese Angelegenheit auf Eis gelegt und andere, eiligere Sachen vorgezogen.
Ich kann nicht immer, wenn irgendwem plötzlich einfällt, irgendwas spontan umzuwurschteln, alle Daueraufgaben stehen und liegen lassen und alle meine Ressourcen in solche planlosen Aktionen stecken. Erst kürzlich gab es eine längere Auseinandersetzung um LD-Seiten auf A/A.
Wiedervorlage erst nach Ostern.
VG --PerfektesChaos 20:44, 24. Feb. 2024 (CET)Beantworten
Du sollst doch nicht alles stehen und liegen lassen. Ich werde auf Deine Idee aufbauend vielleicht eine leicht abweichende Beta-Version bauen und stell beide unsere Versionen mal den Admins auf WP:AA vor. Mal schauen, was dabei rumkommt. Besten Dank schon jetzt für Deine Unterstützung. Liebe Grüße, – Doc TaxonDisk.22:45, 24. Feb. 2024 (CET)Beantworten