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 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.
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ómelindeDiskussion 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)
(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ómelindeDiskussion 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: <divclass="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. hellblauhellblau invertiert = #040D18, weiß würde schwarz, grau dunkel hellrot #ffcbcb → hellrot 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ómelindeDiskussion 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:
erforderlich,
vorgeschlagen
optional
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ómelindeDiskussion 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ómelindeDiskussion 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
<ulclass="gallery mw-gallery-traditional"><liclass="gallerybox"><divclass="thumb"><span><ahref=""class="mw-file-description"title=""><imgalt=""src=...class="mw-file-element"></a></span></div><divclass="gallerytext">...
<ahref="/wiki/..."title="...">...
</a></div></li><liclass="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.
@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
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;
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: 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.)
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.))
@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:
@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 wiehier. 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ómelindeDiskussion 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 ...
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.
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ómelindeDiskussion 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|Breite=80% |Rand=#8EAB8E |RandLinks=DarkSeaGreen |Hintergrund=#F0FFF0 |1=<divclass="darkmode-hintergrundfarbe-neutral"style="background:#F0FFF0; color:#202122;">Beispiel 3, wie im Musterartikel</div>}}
Ich hatte eben die Idee; kann man das nicht (in der/einer Vorlage) im CSS umrechnen?Ja, hier ein div mit style=background:hsl(fromvar(--background-color-base)hscalc(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)
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)
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ómelindeDiskussion 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:
@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.
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;
<divstyle="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>
@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)