Wikipedia:Dark Mode/Probleme

From Wikipedia, the free encyclopedia

Auf dieser Seite können Probleme mit dem MediaWiki-eigenen Dark Mode gemeldet werden. Sie ist im Erscheinungsbild-Menü des Skins Vector 2022 unter „Ein Problem mit dem Dunkelmodus melden“ verlinkt.

Probleme melden

Probleme können etwa sein:

  • zu geringer Farbkontrast zwischen Text- und Hintergrundfarbe
  • Darstellung von transparenten Grafiken auf dunklem Hintergrund
  • fehlerhafte Invertierung von hellen Hintergrundfarben
Probleme beheben

Probleme bitte nur dann beheben, wenn du ausreichend Erfahrung mit der Anpassung von Wikipediaseiten für den Dunkelmodus hast. Anpassungen sollen sich nur in Ausnahmefällen bzw. marginal auf die Darstellung im hellen Modus auswirken. Die Einschränkung farblicher Gestaltung im hellen Modus nur aufgrund der Optimierung für den Dunkelmodus ist unzulässig.

Übersicht potenziell problematischer Parameter:

festgesetzte Hintergrundfarbe

Vorlage:Autoarchiv-Erledigt/Wartung/Parameter Zeigen auf Nein gesetzt

Gemeldete Probleme, die einer Softwareänderung bedürfen

Allgemein – Hinweisbalken auf neue Nachrichten hat schlechten Farbkontrast
/Archiv/2026#Benachrichtigung Neue Nachricht auf deiner Diskussionsseite Hellblau auf leuchtend Gelb
phab:T372056
Codex – Pfeile im Dropdownmenü werden nicht invertiert
/Archiv/2024#Spezial:Seiten mit ungesichteten Versionen
phab:T358703
Inhalt – Hintergrundfarbe einer Tabellenüberschrift wird im Minvera-Skin überschrieben
/Archiv/2025#Benutzer:Eichg/Spielwiese1#Farbfehler
phab:T361838
VisualEditor – Icon in Sortierschlüssel-Popup wird nicht invertiert
/Archiv/2024#VisualEditor Kategorien
phab:T371074
VisualEditor – bei Bearbeitung eines Notensatzes wird die Vorschau nicht invertiert
/Archiv/2024#VisualEditor allgemein
phab:T371176

Portal:Genf/Politik Vorlage:Sitzverteilung und Ähnliche

Bunte Vorlagen verlieren im Portalnamensraum komplett ihre Farben, das wäre auch für die Vorlage:Wahldiagramm der Fall. Das kommt zwar nicht so häufig vor, aber es gibt welche, einmal auch mit Wahldiagramm Portal:St. Pölten/Politik. Kann man da irgendetwas machen? --Liebe Grüße, Lómelinde Diskussion 11:30, 20. Nov. 2024 (CET)

Geht derzeit so gut wie gar nicht, deshalb phab:T381524 eröffnet. -- hgzh 20:06, 4. Dez. 2024 (CET)
Wenn es vom NR und Modus abhängt, ob ein Diagramm seine Farben behält, dann ist das gewiss ein Mangel der Vorlage. Egal ob Hell- oder Dunkelmodus und egal welcher NR: Die Farben dürfen nicht verschwinden. ÅñŧóñŜûŝî (Ð) 21:08, 16. Dez. 2025 (CET)

Hilfe/style Dunkelmodus-Fehler

Das Template:Hilfe wird nicht "korrekt" dargestellt im Dunkelmodus, heller farbiger Hintergrund, und dunkle Schrift. --Joshinils (Diskussion) 22:17, 27. Aug. 2025 (CEST)

Dass gewisse Farben erhalten bleiben, ist beabsichtigt. Du müsstest ansonsten konkreter werden, wo es ein Problem gibt. -- hgzh 13:03, 28. Aug. 2025 (CEST)
z. B.
(wenn ich solche externe Bilder anders handhaben soll, bitte sagen, ich weiß es nicht besser.)
Dort sehe ich die Transklusion quasi identisch in beiden Modi, bis auf die Schrift, die beim Hellmodus etwas heller erscheint.
Ich würde für diesen Fall erwarten, dass der Hintergrund deutlich dunkler und weniger intensiv ist als dieses grün: #e0ffd0. Das ist als HSL (100°, 100%, 91%), ich finde 91% wohl intuitiv zu hell. --Joshinils (Diskussion) 23:53, 31. Aug. 2025 (CEST)
Da musst du dich an Benutzer:PerfektesChaos wenden. Die grüne Farbe dient der optischen Erkennung der Zugehörigkeit zum Hilfenamensraum. Für diese Stylezuweisungen ist er zuständig, zumindest sollte keine Änderung an ihm vorbei durchgeführt werden, da er diese Farbschemata (Hilfe/Wikipedia) entworfen hat. --Liebe Grüße, Lómelinde Diskussion 08:17, 1. Sep. 2025 (CEST)

TemplateData Dunkelmodus-Fehler

Überall wo TemplateData in der Dokumentation einer Seite angezeigt wird, ist diese immer im Hellen Modus.

Im HTML gibt es dort um alles ein div mit der Klasse notheme: <div class="notheme"> --Joshinils (Diskussion) 22:42, 27. Aug. 2025 (CEST)

Da musst du dich an Benutzer:PerfektesChaos wenden. Und ja, ein Großteil dieser Linterfehler wird auch durch diese Vorlage erzeugt, aber … auch das liegt in seinem Zuständigkeitsbereich. Die Farben selbst haben jeweils eine statische Bedeutung (erforderlich, erwünscht, optional, veraltet) das muss optisch erkennbar bleiben. Und wenn eine Beschreibung lautet „die erforderlichen Parameter werden hellblau hinterlegt“, dann muss „hellblau“ auch „hellblau“ sein, sonst steht da (Vorlage:TemplateData#Verbesserte Präsentation Abschnitt Weitere Effekte:) Murks. Es reicht eben nicht immer und überall alles zu invertieren. hellblau hellblau invertiert = #040D18, weiß würde schwarz, grau dunkel hellrot #ffcbcbhellrot invertiert = _, damit wäre nichts mehr sinnvoll unterscheidbar blauweißgraurot und die Bedeutung geht verloren. Das bedeutet im Umkehrschluss, wer daran etwas ändern möchte, muss alle Seiten, die mit Templatedata im Zusammenhang stehen anpassen, etwa Hilfe:TemplateData/JSON#Erläuterung des Status anhand eines Minimalbeispiels. Natürlich könnte man mit Variablen arbeiten, aber Text hellblau, weiß, grau, hellrot und Aussehen müssen zusammenpassen. Das einzige was ohne größere Probleme machbar ist, wäre der weiße Hintergrund, der um die Tabelle gelegt wird, der muss nicht weiß bleiben sondern könnte, meiner Meinung nach, durchaus auch class="hintergrundfarbe-basis" vertragen. --Liebe Grüße, Lómelinde Diskussion 08:17, 1. Sep. 2025 (CEST)
Nicht archivieren! Auf dieser Seite muss erkennbar bleiben, dass dieses Problem auf einen einzelnen, mutwillig(!) störenden (Siehe seine Reverts) Verursacher zurückgeht.
Zur Sachlage: Selbstverständlich kann man jede dieser Farben per CSS-Klasse und TemplateStyles für den DarkMode individuell ändern. Damit ist auch eine im DarkMode gut erkennbare Gestaltung möglich. Das scheitert aber am Widerstand von PC, sonst gibt es kein Hindernis. Beweis:
  1. erforderlich,
  2. vorgeschlagen
  3. optional
  4. veraltet

Diese Farben sind in beiden Modi gut erkennbar. ÅñŧóñŜûŝî (Ð) 19:30, 14. Nov. 2025 (CET)

@Lómelinde, Joshinils: Eine Änderung im Modul wäre Aufgabe von Benutzer:PerfektesChaos. Es ist nicht anzunehmen, dass er im Modul die Farbkonstanten auf in beiden Modi gut erkennbasre Werte ändert. Insoweit hier de facto erledigt. ÅñŧóñŜûŝî (Ð) 23:06, 8. Jan. 2026 (CET)
Das mit dem div wurde von hgzh angepasst →Spezial:Diff/249474598/261517834. Damit entfällt der störende weiße Kasten um die Tabelle, mehr würde ich da jetzt nicht verlangen. --Liebe Grüße, Lómelinde Diskussion 07:07, 9. Jan. 2026 (CET)
Das ändert aber nichts daran, dass die invertierten Farben für den Hintergrund immer noch kaum unterscheidbar sind. Insoweit ist das nicht in Ordnung und zeigt einmal mehr auf, welche Nachteile es hat, im Bereich der Vorlagen von einem User so sehr abhängg zu sein. Wenn er kein Bock hat, dann bleibt es, oder wir müssen uns gegen diese Willkür, den Dark Mode nicht zu unterstützen und Anpassungen zu torpedieren, wehren! ÅñŧóñŜûŝî (Ð) 22:36, 9. Jan. 2026 (CET)
Ich verstehe jetzt nicht, was du meinst, die Farben werden nicht invertiert, die Tabellen bleiben genau so, wie im hellen Modus. --Liebe Grüße, Lómelinde Diskussion 07:41, 10. Jan. 2026 (CET)
Du hast Recht. Fakt ist, dass die verwendeten H-Farben für erforderlich, vorgeschlagen und optional schlecht auseinanderzuhalten sind und im Dunkelmodus wegen der Augenadaption noch schlechter. Man kommt zwar wegen der verschiedenen Worte auch ohne klar, aber wenn man schon H-Farben zur zusätzlichen Unterscheidung einsetzt, dann sollten sie auch sinnvoll gewählt werden. ÅñŧóñŜûŝî (Ð) 11:49, 10. Jan. 2026 (CET)

Bildtafel der Verkehrszeichen in der Bundesrepublik Deutschland seit 2017

SVG-Datein in den Galerien brauchen einen hellen Hintergrund. Invertierung ist nicht möglich, da die Symbole weiterhin schwarz sein sollen.

Zusätzlich gibt es im Dark Mode noch Probleme mit einigen SVG. --Salino01 (Diskussion) 16:46, 19. Okt. 2025 (CEST)

Eine unter den Uploadern von SVGs eine weit verbreitete Unsitte ist es, SVGs ohne Hintergrund hochzuladen. Das ist ungefähr so, als würde man nicht auf ÜPapier, sondern auf einer Glasplatte zeichnen und darauf spekulieren, dass diese zukünftig immer auf einem weißen Tischtuch liegt. Der Dark Mode legt die Glasplatte aber auf ein schwarzes Tuch und dann ist das Symbol halt weg. Ich kann die Grafiken gerne aktualisieren und damit normgerecht machen, brauche dazu aber ggf. Unterstützung gegen Reverts. ÅñŧóñŜûŝî (Ð) 16:58, 19. Okt. 2025 (CEST)
Ich hab mir den Unterschied angesehen, und bemerkt, dass die SVG ohne Hintergrund (auf Glas) im Hell-Modus keinen Rand haben, die mit Weißem Hintergrund aber schon.
Das wird daher kommen, dass die Galerie selber einen Hintergrund hat, welcher nicht ganz weiß ist.
Dadurch entsteht dann dieser Rand, selbst im Hell-Modus, auch wenn dieser womöglich schwer zu erkennen ist.
Demzufolge funde ich die Variante ohne Hintergrund besser, man muss nur damit umgehen. --Joshinils (Diskussion) 08:53, 21. Okt. 2025 (CEST)
Es müsste eigentlich eine Lösung gefunden werden wie bei Vorschaubildern, die standardmäßig mit hellem Hintergrund dargestellt werden. Die offensichtlichen Fehler in den Dateien (Fenster bzw. Gespanfuhrwerk) können aber unabhängig geändert werden. --Salino01 (Diskussion) 17:07, 19. Okt. 2025 (CEST)
Vor allen Dingen sollten die Grafiken von "Glas" auf "Papier" übertragen werden und einen weißen Hintergrund bekommen. ÅñŧóñŜûŝî (Ð) 17:50, 19. Okt. 2025 (CEST)
Das sollte nur bei diesen oder ähnlichen Bildtafeln der Fall sein, nicht generell ist ein weißer, aber weiterhin ein transparenter Hintergrund erwünscht, wie es bei vielen Wappen-SVG-Grafiken z.B. der Fall ist. Ein weißer Hintergrund bei SVG-Dateien ist nur dann sinnvoll, wenn die Grafik nur aus schwarzer Farbe besteht. --Doc Taxon (Diskussion) 10:20, 27. Okt. 2025 (CET)
Vielleicht lässt sich die <gallery>-Funktion so anpassen, dass bei zutreffenden Grafiken, wo heller Hintergrund Sinn macht (vielleicht auch hellgrau statt weiß), ein Parameter eingefügt werden kann, der den Hintergrund der jeweiligen gallery-Zelle hell einfärbt. Vielleicht als erste Idee mit <light>-Tags in die jeweilige Zeile der gallery (ist nur eine erste Idee, dass das (noch) nicht geht, ist klar). --Doc Taxon (Diskussion) 10:31, 27. Okt. 2025 (CET)
Das Problem ist die interne Kaskade der CSS-Klassen. Das Wiki-Gallery-Tag wird in HTML als
<ul class="gallery mw-gallery-traditional">
  <li class="gallerybox">
    <div class="thumb">
      <span>
        <a href="" class="mw-file-description" title="">
          <img alt="" src=... class="mw-file-element">
        </a>
      </span>
    </div>
    <div class="gallerytext">...
      <a href="/wiki/..." title="...">...
      </a>
    </div>
  </li>
  <li class="gallerybox">
    <!-- hier das zweite Element u.s.w. -->
  </li>
</ul>
dargestellt. Die Eigenschaften der verschachtelten Klassen "gallerybox" und "thumb" sind nicht so einfach zu ändern. Dazu müsste die WP-eigenen Klassen zentral angepasst werden. ÅñŧóñŜûŝî (Ð) 19:54, 14. Nov. 2025 (CET)
Könnte man nicht in der Definition des gallery-Tags eine zusätzliche Option für die Hintergrundfarbe angeben?
Das hieße zwar eine Änderung an MediaWiki selbst, soweit ich das verstehe, aber warum nicht.
Ich bezweifle, dass ein standardmäßiges weiß überall die richtige Wahl ist, hier aber sinnvoll und notwendig.

Analog zu Vorlage:Galerie was selber bauen hierfür geht auch nicht (?).

FYI: Beim Dateiupload in Wikimedia Commons erscheint nach Auswahl der Datei eine Vorschau des SVG, in dieser ist die Grafik dann in einem Quadrat zentriert, und weiß hinterlegt.
Ich bezweifle aber, dass diese Funktion irgendwie nutzbar ist hier.
joshinils (Diskussion) 21:49, 16. Nov. 2025 (CET)
@Hgzh: Hast du eine Idee, wie man allgemein (also ohne eigene Einstellungen / CSS-Datei) im Darkmode den Thumb-Hintergrund in einer Gallery dunkel bekommt? ÅñŧóñŜûŝî (Ð) 17:01, 15. Nov. 2025 (CET)
Im Darkmode ist der Hintergund doch dunkel? -- hgzh 15:14, 16. Nov. 2025 (CET)
@Hgzh: Ähem... Ich meinte hell bekommen, auch im Darkmode. Ich habe es mit meiner CSS-Seite gelöst, aber das ist halt nur für den jeweiligen User. ÅñŧóñŜûŝî (Ð) 15:57, 16. Nov. 2025 (CET)
Das ist im Prinzip phab:T372255. Dort passiert nur leider nichts mehr, sodass ein zentraler lokaler Stil vonnöten wäre. Ich bin übrigens kein Freund des erzwungenen weißen Hintergrunds, weil das die Nachnutzung auf andersfarbigem Hintergrund erschwert. -- hgzh 17:15, 16. Nov. 2025 (CET)
@Hgzh: Das ist bei diversen Grafiken wie chem. Strukturformeln wohl häufiger, weil reines SW auch wie schwarzer Text genutzt werden kann. Bei einem bunten Diagramm hast du bei nicht-weißem Hintergrund aber gewiss Probleme. Insgesamt brauchen wir also das weiße Tischtuch (dahinterliegendes Objekt wie z. B. Tabellenzelle ist weiß), um die "Glasmalerei" draufzulegen. Brauchen wir also Einträge in MediaWiki:Vector-2022.css, um das für alle Nutzer des DarkMode zu aktivieren? Ich habe auf meiner CSS-Seite für die Gallery
   @media screen {
	html.skin-theme-clientpref-night .gallerybox .thumb { background-color:#ffffff !important; 	}
	html.skin-theme-clientpref-night gallery    { background-color:#ffffff !important; 	}	
	html.skin-theme-clientpref-night .mw-gallery-packed { background-color:#ffffff !important; 	}
   }
:
Für die Icon in Suchergebnissen steht
  .searchResultImage-thumbnail img { background:#ffffff !important;}
:

Letzteres hinterlegt weiße Fläche direkt hinter das Icon. Sowas in der Art würde ich versuchen. ÅñŧóñŜûŝî (Ð) 21:12, 20. Nov. 2025 (CET)

Transparenz und Abdunkelung bei Gallerien, Thumbs etc.

(Überschrift eingeführt, da übergreifendes Thema)

@Hgzh: Dieses Problem betrifft alle Gallery-Tags in der WP. Kannst du dafür sorgen, dass die Selektoren .gallerybox .thumb, gallery und .mw-gallery-packed im Darkmode grundsätzlich einen weißen Hintergrund bekommen? ÅñŧóñŜûŝî (Ð) 22:29, 27. Jan. 2026 (CET)
Habe jetzt eine Lösung umgesetzt, die sich an der für Miniaturbilder orientiert. -- hgzh 12:16, 31. Jan. 2026 (CET)
Also ich sehe keinen großen Unterschied in dem Beispiel hier, oder auf der Bildtafel. Nur haben die eigentlich "korrekt" dargestellten Grafiken, welche keinen Rand brauchen jetzt doch einen Hintergrund, die anderen (symbole) aber nicht.
Kann es sein, dass jetzt die Bilder dunkler sind als vorher? Also, noch dunkler als der darkmode das sowieso macht. Wenn ja, nehm ich an, dass das nicht beabsichtigt ist?
Ich wäre bei so einer Lösung dafür, dass dieser Hintergrund eine andere, etwas dunklere Farbe bekommt als das "weiß" im Bild selber, damit man das unterscheiden kann.
Ich versuch mal eine Auflistung;
----
Oh, gallery-tag wegen der Indentierung in der Diskussion sieht nicht richtig aus in der Vorschau. Da ist es "hell" und ohne Hintergrund, also gar keiner, und nicht zentriert …
Edit: ja, auch veröffentlicht ist das falsch, die grafik zu hoch, aber der andersfarbige dunkle Hintergrund ist jetzt da.
----
100px sieht "normal", aus, transparent, und "hell";
----
100px left hingegen ist abgedunkelt, mit Hintergrund;
----
thumb left auch abgedunkelt;
thumb left
joshinils (Diskussion) 15:14, 31. Jan. 2026 (CET)
Du kannst dir im Dokumentinspektor anschauen, was angewendet wird: weißer Hintergrund und Helligkeit auf Faktor 0,8. Das ist das gleiche wie bei den Miniaturbildern, was ich zwecks Konsistenz auch für sinnvoll halte. Dass alle Bilder in Galerien einen Hintergrund bekommen, war ja Sinn der Sache. Selektiv geht es nur mit einzelnen Bearbeitungen.
Galerien funktionieren nicht korrekt innerhalb von Definitionslisten, deshalb kommt da ein anderer DOM-Teilbaum raus, den der Selektor nicht erfasst. -- hgzh 12:24, 1. Feb. 2026 (CET)
@Hgzh: Auf Wappen des Landkreises Weißenburg-Gunzenhausen sind im Darkmode weiße Farben jetzt wohl generell grau statt weiß. Ebenso in Wappenlisten: Liste der Wappen im Landkreis Weißenburg-Gunzenhausen. Gerade in diesem Fall finde ich das nicht richtig, wo auch bei Hoheitsfarben zwischen weiß und dark white, also ein gräuliches Weiß unterschieden wird. Außerdem ist auch bei offiziellen Logos nun mal ein Weiß ein Weiß und kein Grau. Vielleicht wäre es möglich, bei gallery ein Farbparameter mit zu geben wie <gallery white=1> ... </gallery>, der trotz Dark Mode weiß auch wirklich weiß aussehen lässt. Doc Taxon (Diskussion) 19:09, 11. Feb. 2026 (CET)
Oder eher andersrum, dass grau die (per Parameter wechselbare) Ausnahme ist und weißes weiß der default. Sonst muss man analog den Grafiken überall ein class=skin-invert anfügen.
joshinils (Diskussion) 19:32, 11. Feb. 2026 (CET)
@Joshinils: gallery class="skin-invert" dreht aber auch alle Farben um. Wie soll das funktionieren? --Doc Taxon (Diskussion) 21:01, 11. Feb. 2026 (CET)
Nein, ich meine, dass man sonst das "white=1" an (vmtl.) wesentlich mehr galleries anfügen müsste, statt den default beizubehalten. Dann kann man die Fälle wo es notwendig ist manuell anpassen.
(Ich finde, dass das Invertieren von Grafiken mittels einem CSS tag an der Stelle wo ein Bild benutzt wird nicht praktisch ist. Das sollte eher an der Bilddatei selber hängen. Das wäre hier ja quasi das gleiche, nur auf andere Art.)
joshinils (Diskussion) 21:13, 11. Feb. 2026 (CET)
Ich hab hier; Hilfe:Bilder#Bilder Nebeneinander, und erinnere mich auch an JPEG, leider wieder was gesehen.
Bilder in z. B. <div> sind nicht abgedunkelt.
Hierher kopiert, aber dasselbe Bild verlinkt;
ohne div
mit div
Beide mit "mini" Format. (Ohne mini: , dann auch ohne Hintergrund, und nicht abgedunkelt)

In dem JPEG Artikel sind die Beispiele dann schlechter erkennbar.
Auch sieht man den Unterschied zwischen nicht-abgedunkelten, und hellen Bildern dort im Abschnitt JPEG#Beispielbild, wo Bilder in einer Tabelle enthalten sind. Egal wie, in Tabellen sind Bilder auch immer Hell.
{| class="wikitable"
|-
| [[Datei:0 white, red rounded rectangle.svg|40px]] ohne || [[Datei:0 white, red rounded rectangle.svg|mini|40px|Mini]] || <div>[[Datei:0 white, red rounded rectangle.svg|mini|40px|Mini mit div]]</div>
|}
ohne
Mini
Mini mit div
(Tabellen gehen wohl in Diskussionsantworten auch nicht, das mit den Doppelpunkten zur Indentierung scheint echt suboptimal.)
((Ich hab die mal dazwischenkopiert ohne Indentierung, ich hoffe mal da geht jetzt nichts schief.))
joshinils (Diskussion) 19:24, 13. Feb. 2026 (CET)
@Hgzh: Weißt Du, wo genau das herkommt, dass das weiß dunkel wird? --Doc Taxon (Diskussion) 11:21, 14. Feb. 2026 (CET)
Wie ich oben schrieb, habe ich mich bei den Galerien daran orientiert, was auch die Miniaturbilder machen. Also weißer Hintergrund und Helligkeit auf 80%. Das hat seine Nachteile, aber man sollte dann sowohl Galerien als auch Miniaturbilder betrachten. -- hgzh 18:25, 16. Feb. 2026 (CET)
@Hgzh: Ja, hm ... könnten wir zumindest eine class entwickeln, die die Helligkeit des Bildes (weil es von fall zu fall sinnvoller sein könnte) auf 100% Helligkeit setzt? --Doc Taxon (Diskussion) 20:46, 16. Feb. 2026 (CET)
Nach Überlegung wäre es mir lieber, diese Abdunklung gar nicht vorzunehmen, aber das sollte dann wieder einheitlich passieren. -- hgzh 21:52, 23. Feb. 2026 (CET)
@Hgzh: Ja, einheitlich, das finde ich auch gut. Kriegen wir das irgendwie hin? --Doc Taxon (Diskussion) 18:19, 1. Mär. 2026 (CET)
Eine SVG mit transparentem Hintergrund, weißem Rand und weißer Innenfläche sollte im Darkmode auch genauso dargestellt werden: Hintergrund der Transparenz wird schwarz und Weiß bleibt weiß. Hat die SVG schwarz am Rand, dann braucht es eine Möglichkeit, individuell mit notheme zu hantieren. Ähnlich bei Thumbnails. Das automatische Abdunkeln finde ich nicht gut, denn es liegt in der Natur des Darkmode, dass größere weiße Flächen sehr hell wirken. Das ist aber richtig und normal. Verkehrszeichen haben, soweit es konstrukte wie Baken, Andreaskreuze, etc. sind, alle (!) einen schmalen weißen Rand zur optischen Absetzung vom Hintegrund neben der Straße beim Draufschauen. Der jetzige Zustand ist schlecht:
Rechter Thumb
Linker Thumb
ohne alles
Abdunkelung in der Galerie störend:

Mit class="notheme":

ÅñŧóñŜûŝî (Ð) 22:51, 1. Mär. 2026 (CET)

@Hgzh: Da das eigentlich hier hin gehört, unten aber thematisch aufgegriffen wurde, schreibe ich das hier noch einmal. Die Beantwortung wäre besser hier aufgehoben:
Bei den amtlichen Schildern oben ist das eindeutig definiert (ist jede Farbe eindeutig definiert), dass Weiß #fff zu sein hat.
Warum sollte das für uns wichtig sein? Nun, es ist deshalb wichtig, weil wir mit alternativen Farben und Helligkeiten die Symbole in Wikipedia nicht richtig darstellen. Und wir wollen und dürfen keine fehlerhaften Inhalte in Artikeln präsentieren. Man kann Thumbs und Galerien auch gerne einheitlich so belassen, wo wir aber farbkorrekt arbeiten müssen (Schilder, Wappen, Flaggen, fest farbdefinierte Symbole), muss die Vergrauung und Farbveränderung ausgeschaltet werden können.
Lösungsvorschlag, wenn sich das machen ließe: Einen zusätzlichen Parameter hinzufügen, wie z.B. color=save, der eine Vergrauung verhindert und die Farben so lässt, wie die Dateien sie mitbringen, aber transparente Hintergründe im Darkmode dunkel darstellt und im Lightmode hell.
Hgzh, ich würde mich sehr freuen, wenn Du uns diesbezüglich helfen könntest. --Doc Taxon (Diskussion) 11:10, 21. Mär. 2026 (CET)
Eine Variante ist ein <div> drum zu legen (wie ich hier schon schrieb), dann greift die CSS Regel nicht mehr, da der Pfad anders ist.
Ob das eine empfehlenswerte, gute, wartbare Lösung ist, naja – das in eine Vorlage zu scheiben wäre wohl besser? Die macht dann nix anderes, erlaubt aber die Einbindungen zu verfolgen, im Wikitext steht dessen Name, hat eine eigene Seite wo auch weitere Erklärungen stehen können, kann simpel durch andere Lösung zentral ersetzt werden.
Ohne könnte man evtl. versucht sein das einfach blindlings wieder zu entfernen, schließlich tut das nichts, und im Hellmodus sieht beides identisch aus (genauso wie die klasse=skin-invert-image, die hat jedoch einen eigenen Namen).
joshinils (D) 11:35, 21. Mär. 2026 (CET)

Überschriften und Hintergrundfärbung

Es ist ja generell so, dass der Dunkelmodus davon ausgeht, dass sich die Überschriften der Ebene 1 bis 5 auf dem Basishintergrund befinden und daher von basis-schwarz zu basis-weiß wechseln. Dabei wird nicht kontrolliert, ob dies wirklich der Fall ist. Nun gibt es aber Leute hier, die immer alles bunt färben wollen, insbesondere ihre Benutzerseiten oder ihre WikiProjekte. Da sich die Schriftfarben der Überschriften nicht von außen überschreiben lassen, kann zwar jeder Überschrift von außen ein class="notheme" mitgegeben werden, aber oftmals sind die Seiten durch verschachtelte Vorlagen- oder Seiteneinbindungen so unübersichtlich, dass das schwierig ist. Die Vorlage:Überschriftensimulation umgeht dieses Problem, da sie nicht mit richtigen Überschriften arbeitet. Unproblematisch sind natürlich hintergrundfarbe-basis hintergrundfarbe1 hintergrundfarbe5 Ebenfalls eher unkritisch ist hintergrundfarbe4 aber es wird ja auch mit anderen Farben gespielt besonders intensiv im GLAM-Projekt das nur und ausschließlich im hellen Modus einigermaßen, aber auch nicht immer (Ausklappmenüs mit unpassender Schriftfarbe siehe auch Modul:GLAMpage, Vorlage:GLAMpage#Farben), lesbar ist. Auf vielen Seiten sieht es im Dunkelmodus dann so aus wie hier. Nachfolgend eine Demo mit hintergrundfarbe8 Überschrift das sieht dann im Dunklen so → Überschrift aus

Überschrift (===)

Überschrift (h3)

Überschrift (h3 class="notheme")

Das ist mir schon sehr oft aufgefallen. Gibt es irgendeine andere Lösung als alle Seiten einzeln umbauen zu müssen? --Liebe Grüße, Lómelinde Diskussion 17:54, 17. Jan. 2026 (CET)

1) Sind wir für "Klickibunti" im BNR zuständig? Ich finde nein.
2) Das muss man m. e. auch auf jeder Seite extra anpassen. In Projekten und Portalen obliegt es den dortigen Autoren, ihre Projekt- und Portalseiten so zu gestalten, dass sie in beiden Modi passen. Ein paar Tipps kann man schon geben.

So z. B. "Feste Farbwerte für Hintergründe müssen für schwarzen und weißen Text brauchbar sein." Ansonsten gibt es die Farbklassen und "notheme", "skin-invert-image" und ein paar andere. Damit kommt man mit gutem Willen hin. Ich empfehle mittelhelle feste Farben. ÅñŧóñŜûŝî (Ð) 01:16, 18. Jan. 2026 (CET)

Hier die Farbklassen. Mir erscheinen hintergrundfarbe1, hintergrundfarbe4, hintergrundfarbe5 und hintergrundfarbe6 am ehesten i. O.

Überschrift #ff9900

Überschrift #99cc99

Überschrift H-Farbe 1

Überschrift H-Farbe 2

Überschrift H-Farbe 3

Überschrift H-Farbe 4

Überschrift H-Farbe 5

Überschrift H-Farbe 6

Überschrift H-Farbe 7

Überschrift H-Farbe 8

Hier die 216 Farben mit heller und dunkler Schrift:

Weitere Informationen Tabelle der 216 websicheren H-Farben ...
Tabelle der 216 websicheren H-Farben
#000000
#000000
#000033
#000033
#000066
#000066
#000099
#000099
#0000CC
#0000CC
#0000FF
#0000FF
#003300
#003300
#003333
#003333
#003366
#003366
#003399
#003399
#0033CC
#0033CC
#0033FF
#0033FF
#006600
#006600
#006633
#006633
#006666
#006666
#006699
#006699
#0066CC
#0066CC
#0066FF
#0066FF
#009900
#009900
#009933
#009933
#009966
#009966
#009999
#009999
#0099CC
#0099CC
#0099FF
#0099FF
#00CC00
#00CC00
#00CC33
#00CC33
#00CC66
#00CC66
#00CC99
#00CC99
#00CCCC
#00CCCC
#00CCFF
#00CCFF
#00FF00
#00FF00
#00FF33
#00FF33
#00FF66
#00FF66
#00FF99
#00FF99
#00FFCC
#00FFCC
#00FFFF
#00FFFF
#330000
#330000
#330033
#330033
#330066
#330066
#330099
#330099
#3300CC
#3300CC
#3300FF
#3300FF
#333300
#333300
#333333
#333333
#333366
#333366
#333399
#333399
#3333CC
#3333CC
#3333FF
#3333FF
#336600
#336600
#336633
#336633
#336666
#336666
#336699
#336699
#3366CC
#3366CC
#3366FF
#3366FF
#339900
#339900
#339933
#339933
#339966
#339966
#339999
#339999
#3399CC
#3399CC
#3399FF
#3399FF
#33CC00
#33CC00
#33CC33
#33CC33
#33CC66
#33CC66
#33CC99
#33CC99
#33CCCC
#33CCCC
#33CCFF
#33CCFF
#33FF00
#33FF00
#33FF33
#33FF33
#33FF66
#33FF66
#33FF99
#33FF99
#33FFCC
#33FFCC
#33FFFF
#33FFFF
#660000
#660000
#660033
#660033
#660066
#660066
#660099
#660099
#6600CC
#6600CC
#6600FF
#6600FF
#663300
#663300
#663333
#663333
#663366
#663366
#663399
#663399
#6633CC
#6633CC
#6633FF
#6633FF
#666600
#666600
#666633
#666633
#666666
#666666
#666699
#666699
#6666CC
#6666CC
#6666FF
#6666FF
#669900
#669900
#669933
#669933
#669966
#669966
#669999
#669999
#6699CC
#6699CC
#6699FF
#6699FF
#66CC00
#66CC00
#66CC33
#66CC33
#66CC66
#66CC66
#66CC99
#66CC99
#66CCCC
#66CCCC
#66CCFF
#66CCFF
#66FF00
#66FF00
#66FF33
#66FF33
#66FF66
#66FF66
#66FF99
#66FF99
#66FFCC
#66FFCC
#66FFFF
#66FFFF
#990000
#990000
#990033
#990033
#990066
#990066
#990099
#990099
#9900CC
#9900CC
#9900FF
#9900FF
#993300
#993300
#993333
#993333
#993366
#993366
#993399
#993399
#9933CC
#9933CC
#9933FF
#9933FF
#996600
#996600
#996633
#996633
#996666
#996666
#996699
#996699
#9966CC
#9966CC
#9966FF
#9966FF
#999900
#999900
#999933
#999933
#999966
#999966
#999999
#999999
#9999CC
#9999CC
#9999FF
#9999FF
#99CC00
#99CC00
#99CC33
#99CC33
#99CC66
#99CC66
#99CC99
#99CC99
#99CCCC
#99CCCC
#99CCFF
#99CCFF
#99FF00
#99FF00
#99FF33
#99FF33
#99FF66
#99FF66
#99FF99
#99FF99
#99FFCC
#99FFCC
#99FFFF
#99FFFF
#CC0000
#CC0000
#CC0033
#CC0033
#CC0066
#CC0066
#CC0099
#CC0099
#CC00CC
#CC00CC
#CC00FF
#CC00FF
#CC3300
#CC3300
#CC3333
#CC3333
#CC3366
#CC3366
#CC3399
#CC3399
#CC33CC
#CC33CC
#CC33FF
#CC33FF
#CC6600
#CC6600
#CC6633
#CC6633
#CC6666
#CC6666
#CC6699
#CC6699
#CC66CC
#CC66CC
#CC66FF
#CC66FF
#CC9900
#CC9900
#CC9933
#CC9933
#CC9966
#CC9966
#CC9999
#CC9999
#CC99CC
#CC99CC
#CC99FF
#CC99FF
#CCCC00
#CCCC00
#CCCC33
#CCCC33
#CCCC66
#CCCC66
#CCCC99
#CCCC99
#CCCCCC
#CCCCCC
#CCCCFF
#CCCCFF
#CCFF00
#CCFF00
#CCFF33
#CCFF33
#CCFF66
#CCFF66
#CCFF99
#CCFF99
#CCFFCC
#CCFFCC
#CCFFFF
#CCFFFF
#FF0000
#FF0000
#FF0033
#FF0033
#FF0066
#FF0066
#FF0099
#FF0099
#FF00CC
#FF00CC
#FF00FF
#FF00FF
#FF3300
#FF3300
#FF3333
#FF3333
#FF3366
#FF3366
#FF3399
#FF3399
#FF33CC
#FF33CC
#FF33FF
#FF33FF
#FF6600
#FF6600
#FF6633
#FF6633
#FF6666
#FF6666
#FF6699
#FF6699
#FF66CC
#FF66CC
#FF66FF
#FF66FF
#FF9900
#FF9900
#FF9933
#FF9933
#FF9966
#FF9966
#FF9999
#FF9999
#FF99CC
#FF99CC
#FF99FF
#FF99FF
#FFCC00
#FFCC00
#FFCC33
#FFCC33
#FFCC66
#FFCC66
#FFCC99
#FFCC99
#FFCCCC
#FFCCCC
#FFCCFF
#FFCCFF
#FFFF00
#FFFF00
#FFFF33
#FFFF33
#FFFF66
#FFFF66
#FFFF99
#FFFF99
#FFFFCC
#FFFFCC
#FFFFFF
#FFFFFF
Schließen
ÅñŧóñŜûŝî (Ð) 02:08, 18. Jan. 2026 (CET)
Das beantwortet meine Frage nicht wirklich. Gibt es irgendeine bessere Lösung als alles einzeln umzubauen? Es sind auch nicht nur Benutzerseiten und von Benutzern initiierte WikiProjekte betroffen. Den Portalnamensraum kannst du vernachlässigen, der wird komplett anders behandelt. Und insbesondere nach außen wirkende Wikipedianamensraumseiten sollten für alle Lesenden gut lesbar sein.
Es gibt hier sehr schlaue Leute, die meinen es sei eine Superidee reguläre Überschriften in Tabellen zu setzen. Das kann aber den identischen Effekt haben, sie werden dann teilweise unlesbar. Beispiel Spezial:Diff/154404725: → Liste der Kreiszugehörigkeit bayerischer Gemeinden
Wenn dort dann beispielsweise hintergrundfarbe2 stehen würde, sieht man nur noch den Link [ Bearbeiten ]. Überschriften haben generell nichts innerhalb von Tabellen zu suchen sondern sollen immer linksbündig stehen Wikipedia:Formatierung#Überschriften, weil meiner Meinung nach so etwas nicht wirklich barrierefrei ist. Das interessiert hier aber niemanden. Jeder mach, was er will und findet genau das supertoll. Ich war schon immer gegen Überschriften innerhalb von Tabellen, weil es auch teilweise einfach nur doof aussieht und nun durch den Dunkelmodus bestätigt sich meine Auffassung, aber wen interessiert hier schon meine Meinung. --Liebe Grüße, Lómelinde Diskussion 07:13, 18. Jan. 2026 (CET)
Ach so war das gemeint. Nun, da brauchen wir eine passende Insoure-Abfrage, welche die Seiten zuverlässig auflistet. Mit insource:/\|( ?\n)*==/ gibt es bereits 2836 Treffer im ANR. Das kann man kaum alles manuell ändern. Ein Bot wird das auch nicht hinbekommen. Die Überschriften haben auch keine CSS-Klasse und sind nur H-Tags. Das kann wohl nur mit der WP-Software fixiert werden. ÅñŧóñŜûŝî (Ð) 19:22, 18. Jan. 2026 (CET)

Vorlage:Achtung Dunkelmodus-Fehler

Bzgl. WP:Formatvorlage/Musterartikel, dort erscheint der "Hintergrund" als zweiter, hellgrüner, innerer Rand. Das sieht vielleicht nur wegen einem Mangel an Abstand zum Inhalt seltsam aus.

{{Achtung|Beispiel 1}}

{{Achtung|Breite=80% |Rand=#8EAB8E |RandLinks=DarkSeaGreen |Hintergrund=#F0FFF0 |1=<div>Beispiel 2</div>}}
{{Achtung|Breite=80% |Rand=#8EAB8E |RandLinks=DarkSeaGreen |Hintergrund=#F0FFF0 |1=<div class="darkmode-hintergrundfarbe-neutral" style="background:#F0FFF0; color:#202122;">Beispiel 3, wie im Musterartikel</div>}}

Auch sind dort Listen enthalten:

  • Listenelement

Welche Links dem grün zu nahe kommen.

joshinils (Diskussion) 15:14, 15. Feb. 2026 (CET)

Ich hatte eben die Idee; kann man das nicht (in der/einer Vorlage) im CSS umrechnen?Ja, hier ein div mit style=background: hsl(from var(--background-color-base) h s calc(mod(l + 120, 100) ) ); color:var(--color-base);
Dieser Text hat je nach Dunkel/Hell-modus eine andere Hintergrundfarbe.
Man kann also eine als Argument übergebene Farbe umrechnen, z. B. eine Hintergrundfarbe von einer Randfarbe abhängig ableiten.
joshinils (Diskussion) 15:14, 15. Feb. 2026 (CET)
Beispiel 4:
background:DarkSeaGreen; color:var(--color-base);

Beispiel 5:
background:hsl(from DarkSeaGreen h clamp(0, s, 15) clamp(10, l / 3, 50) ); color:var(--color-base);

Jemand anderem fällt vielleicht was intelligenteres ein statt diesem clamping.
joshinils (Diskussion) 15:29, 15. Feb. 2026 (CET)

Vorlage:Navigationsleiste Dunkelmodus-Fehler

Beispiel; Vorlage:Navigationsleiste_Wikimedia_(WP-NR)

Das logo ist nicht invertierbar da es ein logo ist, dessen farben sollten gleich bleiben. Ob das mit transparentem Hintergrund gut aussieht, genug kontrast hat, müsste man dann ja sehen.

In Vorlage:Auflistung/styles.css hatte ich noch was gesehen, das hat damit vmtl. nix zu tun – das falsch geschriebene currentcolor statt currentColor, kann das aber weder testen (wüsste nicht wie) noch selbst ändern.
joshinils (D) 07:38, 6. Mär. 2026 (CET)

Wo genau siehst du da ein Problem? Bei mir ist das Logo grau hinterlegt, aber nicht invertiert wie hier Vorlage:Klappleiste/styles.css Spezial:Diff/258748653/259258228 vorgegeben. --Liebe Grüße, Lómelinde Diskussion 09:41, 6. Mär. 2026 (CET)
Ja, genau das grau hinterlegte ist mein problem. Ich persönlich finde das unschön. Liegt auch daran, dass es über und links von dem grau noch einen abstand in diesem überschriftsbalken gibt, und das grau unterhalb diesen herausragt.
Ohne das grau merkt/sieht man das nicht.
Bei Vorlage:Navigationsleiste Griechisches Alphabet war es ähnlich, aber außerdem nicht möglich zu invertieren ohne dass es damals den grauen hintergrund beibehielt, das wurde gelöst.
joshinils (D) 10:08, 6. Mär. 2026 (CET)
Ich finde das in Ordnung, und sieht meiner Meinung nach auch gut aus. Ein grauer Überschriftsbalken mit Abstand zum Rahmen, im Hell- und Dunkelmodus vorhanden. Das Logo mit transparentem Hintergrund halb oben drauf. Passt ... --Doc Taxon (Diskussion) 10:59, 6. Mär. 2026 (CET)
Dem würde ich zustimmen, wenn dem so wäre.
Im Hellmodus ja, im Dunkelmodus hat das Logo keinen transparenten Hintergrund.
 grau hinterlegt oder   transparent
Kann ja sein, dass das so gewollt ist, ich fände das aber nicht schön.
Das sieht so aus, als sei das grau teil des Logos, ein Hintergrund fehlt, oder ein teil falsch oder unvollständig geladen wurde.

Wie man das dann allgemeingültig macht, dass es immer funktioniert, und alle Logos, sei es helle, dunkle, transparente, oder nicht in sowohl dem hell- und dunkelmodus sichtbar sind mit ausreichend kontrast, das weiß ich auch nicht.
joshinils (D) 14:37, 6. Mär. 2026 (CET)
Man könnte es rund einbinden und weiß hinterlegen, zudem mit |rahmenlos versehen. Bilder reagieren leider je nach Attribut sehr unterschiedlich
Transparente Hinterlegung hat ein Problem mit dunklem rot, blau, grün ebenso wie mit schwarz. Diese Logos sind nun mal nicht für dunklen Hintergrund entworfen. --Liebe Grüße, Lómelinde Diskussion 15:04, 6. Mär. 2026 (CET)
Wieder einmal ein "Glasplatte-statt-Papier-Problem". Es ist extrem schlecht, wenn so ein Logo keinen(!) Hintergrund hat. Wenn das dann auch noch in eine Navileiste eingebaut wird, dann muss man sich nicht wundern. Einfach eine Grafik mit Hintergrund nehmen und der WP-Software die Macke, bei "thumb" eigenmächtig umzufärben, wegprogrammieren. Hier rechts eine Version mit kreisrundem, weißem Hintergrund und in einem Div-Tag mit class="float-right" statt "Thumb-Parameter". Wie man sieht: Das Bild wird von der WP-Software nicht manipuliert und es passt. ÅñŧóñŜûŝî (Ð) 19:11, 6. Mär. 2026 (CET)
Ja, die variante die grafik selbst anzupassen ist natürlich auch möglich. Ich würd sogar sagen, dass die besser ist, wenn man das von vornherein beachtet.
Hatte man hier aber leider nicht.
joshinils (D) 19:26, 6. Mär. 2026 (CET)
Alternativ geht (für dieses logo) auch ganz schwarz als hintergrund, da ist der kontrast auch groß genug. Die geringe differenz zu der farbe des überschriftsbalken ist ja auch teil des problems.
joshinils (D) 19:42, 6. Mär. 2026 (CET)
Nutzt man stattdessen den Thumb-Parameter, dann fängt die Software an zu spinnen: Sie "füllt" den transparenten Bereich außerhalb vom Kreis mit Weiß und konvertiert dann alles, was weiß ist, in ein Grau (#CCCCCC). Das ist das Problem hier. ÅñŧóñŜûŝî (Ð) 19:23, 6. Mär. 2026 (CET)
Des Weiteren: Nimmt man die Datei mit rundem Hintergrund für die Navi, dann sieht es so aus:
Hier bleibt zwar der Kreis weiß, aber das Auffüllen zum Quadrat in Grau wird trotzdem vorgenommen. Das bedeutet:
Die extrem zentrale Vorlage:Navigationsleiste ist nicht richtig Darkmodefähig! Wer soll das wann korrigieren? ÅñŧóñŜûŝî (Ð) 19:34, 6. Mär. 2026 (CET)
@Antonsusi: Gehört die Vergrauung nicht eher in den Abschnitt #Transparenz und Abdunkelung bei Gallerien, Thumbs etc. oben? --Doc Taxon (Diskussion) 17:06, 8. Mär. 2026 (CET)
@Hgzh: Hast du eine Idee, wie man hier eine Lösung findet? ÅñŧóñŜûŝî (Ð) 15:31, 7. Mär. 2026 (CET)
@Joshinils: Hm, erst mal sollten wir uns überlegen, warum das bei Dir anscheinend grau hinterlegt war, und bei mir der Hintergrund transparent war? Kann nicht sein, dass das bei Dir anders angezeigt wird als bei mir, (wobei ich mich auf Vorlage:Navigationsleiste Wikimedia (WP-NR) vor der Änderung durch @Antonsusi beziehe). Das war schön transparent, nichts graues. --Doc Taxon (Diskussion) 17:02, 8. Mär. 2026 (CET)
Bei Vorlage:Navigationsleiste_Wikimedia_(WP-NR)&oldid=241570056 ist auf meinem iPad und Android-Handy sowohl in Firefox (beide), Google Chrome (beide) und beim iPad auch in Safari das Logo überall grau hinterlegt.
joshinils (D) 14:48, 9. Mär. 2026 (CET)
Doch, je nach Browser-Engine, Betriebssystem, Softwareversion, etc. kann was leider auch mal anders aussehen.
Einzig Screenshots sind da eineindeutig – die jeweils für jedes kleine Beispiel in commons zu laden soll man wohl nicht, und mag ich auch nicht, alternativen (gute Beispiele?) sind dann immer extern und können in Zukunft von Link rot betroffen sein. Das könnte dann aber auch egal sein, weil es Archiviert wurde, und nicht mehr Relevant.
joshinils (D) 14:56, 9. Mär. 2026 (CET)
Ich habe in diesem Bereich eigene CSS-Einstellungen. Deshalb areite zwar mit Firefox, aber das Betrachten mache ich mit Opera und diversen Microsoft-Browser, weil ich dann nicht eingeloggt bin. Es darf aber nicht vom Browser abhängen, was zu sehen ist. Die H-Farbe muss immer klar definiert sein, damit es alle (bugfreie) Browser gleich darstellen. Besonders merkwürdig: Umhüllt man den Thumb mit einem Div-Tag (egal welche H-Farbe oder transparent)), dann ist alles "brav" weiß. ÅñŧóñŜûŝî (Ð) 20:25, 10. Mär. 2026 (CET)
Hier geht alles mögliche durcheinander.
  • Die graue Hinterlegung gibt es deshalb, weil nicht automatisch festzustellen ist, welches Logo invertiert werden kann, welches gar keinen Hintergrund braucht oder welches unlesbar wird. Das mag in manchen Fällen unvorteilhaft aussehen, aber mal zur Einordnung: es geht hier um ein schnödes Dekobildchen in einer Navigationsleiste, das bei mobilen Seitenabfrufen nicht einmal angezeigt wird. Da sind Ressourcen anderswo besser eingesetzt.
  • Die Graufärbung an sich folgt der gleichen Logik wie der der Thumbs, also weißer Hintergrund mit Brightness-Filter. Wie schon weiter oben im anderen Abschnitt geschrieben, ist auch diese Lösung nicht alternativlos, sollte aber wenigstens einheitlich gehandhabt werden.
-- hgzh 16:45, 17. Mär. 2026 (CET)
Mit den Ressourcen geb ich dir recht. Ich tendiere dazu gern alles das ich als Fehler sehe ohne zu sortieren melden zu wollen, oder selbst zu ändern.
Ob und wo man was tun soll oder muss, das kann und will ich nicht grundsätzlich entscheiden.

Ursprünglich ging es mir auch um die eingeschränkte Erkennbarkeit des Logos. Da das nun ersetzt wurde durch eine Dateiversion mit weißem Hintergrund ist zumindestens das gelöst.
Von oben, ich; „[…] dass es über und links von dem grau noch einen abstand in diesem überschriftsbalken gibt, und das grau unterhalb diesen herausragt.“ Das stört mich nur optisch, und ich seh das vermutlich mit zu viel Perfektionismus.
Die Variante mit dem Kreis-"Ausschnitt" find ich hübsch, ist aber auch eine einzel-Lösung.
----
Vielleicht kann man eine andere art Unterkategorie bauen, für solch unkritischen Sachen?
Sowas ist ja per se kein Problem, sondern mehr kosmetisch. Nur weiß ich oft nicht wie ich etwas korrekt ändern kann oder soll, oder womöglich mach ich was kaputt ohne es gar zu merken.
joshinils (D) 19:58, 17. Mär. 2026 (CET)
@Hgzh: Bei diesen Logos würde ich jetzt auch nichts sagen, aber bei den amtlichen Schildern oben ist das eindeutig definiert (ist jede Farbe eindeutig definiert), dass Weiß #fff zu sein hat.
Warum sollte das für uns wichtig sein? Nun, es ist deshalb wichtig, weil wir mit alternativen Farben und Helligkeiten die Symbole in Wikipedia nicht richtig darstellen. Und wir wollen und dürfen keine fehlerhaften Inhalte in Artikeln präsentieren. Man kann Thumbs und Galerien auch gerne einheitlich so belassen, wo wir aber farbkorrekt arbeiten müssen (Schilder, Wappen, Flaggen, fest farbdefinierte Symbole), muss die Vergrauung und Farbveränderung ausgeschaltet werden können.
Lösungsvorschlag, wenn sich das machen ließe: Einen zusätzlichen Parameter hinzufügen, wie z.B. color=save, der eine Vergrauung verhindert und die Farben so lässt, wie die Dateien sie mitbringen, aber transparente Hintergründe im Darkmode dunkel darstellt und im Lightmode hell.
Hgzh, ich würde mich sehr freuen, wenn Du uns diesbezüglich helfen könntest. --Doc Taxon (Diskussion) 11:04, 21. Mär. 2026 (CET)
Auch bei Logos kann ich mir vorstellen, dass da so manch eine Firma, Konzern, Marketingabteilung diese gern korrekt dargestellt haben will, mehr als die Datei ändern wollen/können/sollen die aber nicht machen müssen, der rest sollte dann „von allein“ passieren, ja.
Ich find, dass sowas auch wieder ein Attribut wäre, das viel eher an der Datei selbst hängen sollte, statt dass sowas bei jeder Einbindung separat beachtet werden muss. Dann kann man das einmalig dort einstellen, und das propagiert überallhin. Heute muss in jedem Wiki, in jeder Sprache, bei jeder Einbindung das mit der klasse=skin-invert-image händisch korrigiert werden, und wenn es eine neue Dateiversion gibt, merkt man das nicht, und müsste das potenziell überall wieder rückgängig machen.
joshinils (D) 11:43, 21. Mär. 2026 (CET)

Junktoren der Aussagenlogik Dunkelmodus-Fehler

Linienfarbe(n) und Textfarbe(n) der zwei Grafiken;

,

Invertiert sind andere Teile schlecht sichtbar;

,
joshinils (D) 13:20, 8. Mär. 2026 (CET)

input Ainput Boutput f(A,B)X and ¬XA and B¬A and BBA and ¬BAA xor BA or B¬A and ¬BA xnor B¬A¬A or B¬BA or ¬B¬A or ¬BX or ¬X
X or ¬X¬A or ¬BA or ¬B¬A or BA or B¬B¬AA xor BA xnor BAB¬A and ¬BA and ¬B¬A and BA and BX and ¬X
Übersicht der Junktoren in der Aussagenlogik
Das konnte man eventuell so lösen. Ist zwar auch nicht optimal aber etwas besser lesbar. --Liebe Grüße, Lómelinde Diskussion 15:42, 9. Mär. 2026 (CET)

Babel bitte …

Benutzer:Martin1978/Hugglenutzer einmal ersetzen durch

<div style="float:left; border:1px solid; margin:1px">
{| class="infobox" style="width:238px; background:#FFE7BA; color:#202122; border-spacing:0;"
|-
|class="hintergrundfarbe-basis" style="width:45px; height:45px;"| [[Datei:Nuvola apps krec.svg|40px|alt=|zentriert|klasse=hintergrundfarbe2|Huggle]]
|style="font-size:0.70em; padding:0.47em; line-height:1.25em"| Dieser Benutzer nutzt [[Wp:Huggle|Huggle]] zur Vandalismusbekämpfung und es ist ihm Wurst, was andere darüber denken.
|}
</div>

Es sind zwar nicht viele Einbindungen, aber es wäre trotzdem nett auch wegen der Überbreite. Es werden vermutlich noch mehr kommen, Benutzer:Martin1978/Vorlage Wrestling-Gürtel sieht auch nicht schön aus, da Benutzer:Martin1978/Babel Besser emanzipiert fehlt zudem das Icon, im Grunde hat er ja alle Unterseiten sperren lassen, sonst würde ich das selbst reparieren. --Liebe Grüße, Lómelinde Diskussion 16:20, 19. Mär. 2026 (CET)

@Lómelinde: Die Unterseiten sind zur Wartung kurzzeitig für Dich geöffnet worden. Melde Dich, wenn Du alles erledigen konntest. Grüße, --Doc Taxon (Diskussion) 00:21, 20. Mär. 2026 (CET)
Dankeschön, @Doc Taxon, kann wieder zu. --Liebe Grüße, Lómelinde Diskussion 06:41, 20. Mär. 2026 (CET)
Dieser Abschnitt kann archiviert werden. --Lómelinde 06:41, 20. Mär. 2026 (CET)

Related Articles

Wikiwand AI