SVG Replacer und <object> Element

[Rolf B]

Hallo alle,

bekanntlich hat der Safari Probleme, in per <img src="..."> geladenen SVGs den Darkmode zu erkennen.

Die Lösung soll angeblich sein, SVGs nicht als img, sondern als object einzubinden.

<object type="image/svg+xml" data="url" 
        width="..." height="..." class="...">
</object>

Ich habe eine Testversion des SVG-Replacers erstellt. Sie befindet sich im Wiki unter Benutzer:Rolf b/native_svg.js, um sie einzubinden, gibt es seit kurzem die Replacement-Instrumentierung.

Dazu in den Entwicklertools auf die Seite App (Chrome) oder Web-Speicher (Firefox) gehen - keine AHnung wie das im Safari heißt - und dem localStorage den Key "skins.Selfhtml.native_svg" den Wert "replace=Benutzer:Rolf_b/native_svg.js" hinzufügen.

Das native_svg-Modul unterstützt diese Instrumentierung und lädt dann die Version aus meinem Benutzernamensraum.

Das Ergebnis ist grausig.

• Die SVGs bekommen einen weißen Hintergrund, ich weiß nicht woher
• img Elemente haben implizit einen aspect-ratio der ihrer intrinsischen Größe entspricht, bei object ist das nicht der Fall. Dementsprechend sind kleinere SVGs jetzt alle zu hoch.

Wer sich berufen fühlt, möge den Test-Replacer mal aktivieren (im Hauptwiki) und sich das anschauen.

• Auf der Startseite
• Auf der Seite JavaScript_und_das_DOM/Was_ist_das_DOM

Ich habe keine Ahnung, woher der weiße Hintergrund kommt und wie man das Größenproblem lösen kann.

Rolf

[Matthias Scharwies]

Servus!

Hallo alle,

bekanntlich hat der Safari Probleme, in per <img src="..."> geladenen SVGs den Darkmode zu erkennen.

Die Lösung soll angeblich sein, SVGs nicht als img, sondern als object einzubinden.

<object type="image/svg+xml" data="url" 
        width="..." height="..." class="...">
</object>

Das klang gut und vielen Dank, das du das ausprobiert hast.

Mist, dass der SafarIE noch kein prefers-color-schemeunterstüzt.

Ich würde vorschlagen, dass wir diese Baustelle beenden und alle SVGs der Kategorie:Infografik auf ihre Tauglichkeit überprüfen und ggfalls anpassen.

Dabei gäbe es zwei Möglichkeiten:

transparenter Hintergund, Schrift und Pfeile in blau

Der Hintergrund bleibt transparent.

Die blaue Farbe (#337599) ist sowohl auf weißem, als auch dunklem Hintergrund erkennbar und bietet gute Kontraste.

dunkler Hintergrund im SVG-Element

Das Bild erhält im svg-Element bereits einen dunklen Hintergrund entweder im CSS oder als style-Attribut

Vorteile:

1. Schrift ist gut erkennbar
2. Im hellen Modus sieht es nicht schlimm aus, der dunkelblaue Hintergrund zeigt, dass es ein Bild ist. Im Dark Mode sorgt es nicht für einen weißen Blitz.^[1]

---

Vorteile dieses Ansatzes:

1. img sind img, keine workarounds nötig.
2. Einige wenige SVGs müssen überarbeitet werden.

Herzliche Grüße

Matthias Scharwies

---

1. Das haben wir ja eh bei den Screenshots mit weißem Hintergrund. ↩︎

[MudGuard]

Hi,

dunkler Hintergrund im SVG-Element

Das Bild erhält im svg-Element bereits einen dunklen Hintergrund entweder im CSS oder als style-Attribut

Nachteil ist, daß damit alle dark mode bekommen. Ob sie wollen oder nicht.

cu,
Andreas a/k/a MudGuard

[Matthias Scharwies]

Servus!

Hi,

dunkler Hintergrund im SVG-Element

Das Bild erhält im svg-Element bereits einen dunklen Hintergrund entweder im CSS oder als style-Attribut

Nachteil ist, daß damit alle dark mode bekommen. Ob sie wollen oder nicht.

Ja, einen Tod muss man sterben. Dunkler Hintergrund bei SVGs im light mode, so wie bei Fotos mit dunklem Motiv - dafür heller Hintergrund bei Screenshots im Dark Mode.

Wir haben genügend andere Baustellen!

Und sobald der Safari prefers-color-scheme unterstützt, läuft das ohne workaround!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

es gibt diese alte Maxime von W. C. Fields:

If at first you don't succeed, try, try again. Then quit. No use being a damn fool about it.

Ich weiß, dass man sie ohne die beiden "try" öfter mal auf Shirts findet. So demotiviert bin ich aber noch nicht, und meine Hoffnung ist ja, dass die beiden Zusatzversuche jemand anders macht. Und zwar nicht Du!

Rolf

[Bertie]

Eine mögliche Strategie, hier eine Testseite: https://www.macsimum.ch/SELFHTML/Test_SVG_transparent_blau.html

SVG transparent, die Idee von Matthias aufgegriffen alles was auf der Transparenz liegt, blau zu machen (anstatt schwarz).

Ein so helles blau, dass es auf schwarz oder dem dunkelblau des wiki-Hintergrundes für Safari erkennbar bleibt. Im Beispiel habe ich aus der Farbpalette https://wiki.selfhtml.org/wiki/Hilfe:Farbpalette mal das blau aus der Spalte "Vollton" --blue hsl(201 50% 40%) verwendet.

Nachteil: Im light mode aus meiner Sicht nicht optimal, aber vielleicht zumutbar?

Intern im SVG für andere Browser auch die Farben für den dark mode fertig gestalten, im unteren Beispiel links im Firefox den Text weiss.

Wäre ein möglicher Notbehelf für die paar BesucherInnen, welche Safari auf einem Apple Gerät im dark mode benutzen, bis Apple vielleicht doch irgendwann mal aus den Puschen kommt?

Damit bekämen alle mit anderen Browsern auf allen Betriebssystemen einen gestalteten dark mode.

[Rolf B]

Hallo,

wie gesagt: Ich bin nicht bereit, so schnell aufzugeben wie Matthias das fordert.

Nach etwas Forschen habe ich den Grund gefunden:

https://issues.chromium.org/issues/40811132

Aber es ist nicht nur Chromium. Firefox tut das Gleiche. Ich kann mir auch vorstellen, weshalb sie das machen - wenn ich eine Darkmode-Seite habe und einen object-Inhalt einbinde, der davon nichts weiß, ist im object nichts mehr zu erkennen. D.h. das ist kein Bug, sondern eher ein Feature um das Web nicht kaputtzumachen.

Diese Überlegung würde auch für ein img gelten - nur tun sie es dort nicht.

Und es gibt einen opt-out aus diesem Lesbarkeitshelfer - danke an StackOverflow:

object {
   color-scheme: light;
}

Dann bleibt es auch dann transparent, wenn die Seite selbst im Darkmode ist. Innerhalb des SVG kann man immer noch abfragen, ob prefers-color-scheme: dark gewünscht ist. Oder direkt mit color-scheme:light dark und light-dark() arbeiten.

Einziger Schönheitsfehler: Wenn die Host-Seite (also das Wiki) sich mittels color-scheme: light dem Darkmode entzieht, propagiert das weder per img noch per object auf den Inhalt des object. Obwohl dieses Caniuse nahelegt, dass sowas passieren müsste (aber nicht gespecct ist).

Ich bin nicht wirklich glücklich damit.

Jetzt muss ich vom PC weg, ich werde noch:

• Diesen opt-out ins CSS einbauen
• Dem Object width und height wegnehmen und statt dessen per style Attribut ein aspect-ration vorgeben, dann passt das auch mit der Höhe.

Ich melde mich, wenn's testbar ist.

Rolf

[Rolf B]

Hallo,

Nachtrag: Ich hatte wohl beim Test nicht aufgepasst, darum ist mir das vorher nicht aufgefallen. Beim Nachlesen in den vom Bug ausgehenden Links fand ich einen Spec-Hinweis, dass der weiße Hintergrund Absicht ist, wenn color-scheme von Host- und Child-Document abweichend sind.

Ich hatte es schon versucht, im SVG mit color-scheme zu arbeiten, aber dabei wohl meine lokale Kopie editiert und die Version vom Wiki eingebunden.

D.h. wir müssen in den SVGs, die Darkmode-fähig sein sollen,

:root {
   color-scheme: light dark;
}

einbauen, dann matchen die Farbschemata und der weiße Hintergrund sollte nicht erscheinen.

Ich melde mich, wenn's drin ist.

Rolf

[Rolf B]

Hallo,

so, ich habe jetzt eine HTML-Seite und ein SVG-Bild erstellt, worin sich das Farbschema auswählen lässt. Im SVG habe ich dafür per foreignObject ein HTML-Fragment mit Fieldset und Radiobuttons drin.

Dumm nur, dass das den Wiki-Upload verhindert - Mediawiki ist hier absolut paranoid und meint, der IE könnte das als HTML erkennen und das wäre gefährlich und deshalb ist das FERR-PO-TEN! Das betrifft aber nur das Labor-SVG, für unsere Wiki-SVGs ist das nicht von Belang. Glaub ich.

Also steht das SVG jetzt unter https://wiki.selfhtml.org/local/color-scheme-selectable.svg.

Das foreignObject darin ist ein fieldset, dessen Hintergrundfarbe per light-dark() das per color-scheme selektierte Farbschema zeigt. Die Radiobuttons darin werden vom SVG-Stylesheet abgefragt, um das color-scheme des SVG zu ändern.

Hinzu kommt ein <text>-Element, in dem <tspan>-Elemente je nach @media (prefers-color-scheme)-Wert sichtbar werden.

Das HTML-Dokument steht im Beispielspace als Beispiel:Color-Scheme-Selectable.html.

[Ansehen] - [Ausprobieren]

Das HTML-Dokument verwendet ähnliches CSS zur Auswahl des color-scheme.

Wenn das color-scheme von HTML- und SVG-Dokument nicht übereinstimmen, erzeugt der Browser für das SVG einen weißen oder schwarzen Hintergrund, je nach color-scheme des SVG.

Ist im HTML kein color-scheme gesetzt, führt ein Default-Darkmode aus dem Betriebssystem nicht zur Auswahl der dunklen Seite der light-dark()-Macht, deshalb hat das SVG dann ebenfalls den dunklen Hintergrund.

Setzt man HTML und SVG beide auf light oder dark, wird der Hintergrund des SVG transparent. Setzt man das SVG auf color-scheme: light dark, folgt es dem color-scheme des HTML Dokuments. Das ist aber laut caniuse kein spezifiziertes Verhalten!

Allerdings ist das nicht ganz perfekt. Ich habe das Beispiel so konstruiert, dass das HTML zunächst KEIN color-scheme und das SVG zunächst color-scheme:dark hat. Setzt man nun HTML auf light, dann das SVG auf light und ändert DANN das HTML auf dark, sollte man erwarten, dass das SVG einen weißen Hintergrund bekommt. Das tut es in Firefox, aber nicht in Chrome. Erst, wenn man in Chrome das SVG einmal nach dark schaltet und dann nach light zurück, bekommt es den weißen Hintergrund. Das würde ich als Chrome-Bug sehen.

Oh Mann, oh Mann…

Spannende Frage ist nun, wie sich Safari damit verhält. Chrome und FF kann ich ja selbst probieren.

Rolf

[Bertie]

Vielen Dank Rolf für's Austesten, mir schwirrt nur schon vom Lesen der Kopf!

Ich habe Dein "Ausprobieren" mal auf dem Mac in Firefox und Safari nebeneinander geöffnet.

So sieht es auf dem Mac im Hellmodus aus:

Die Anzeige bleibt so, egal welche Options-Kombinationen der mit grünem Strich markierten Optionen ich anklicke. Safari rechts zeigt ein hellblaues Rechteck, Firefox nicht.

Mac im Dunkelmodus:

Die Anzeige bleibt so, egal welche Options-Kombinationen der mit grünem Strich markierten Optionen ich anklicke. Safari rechts zeigt ein dunkelblaues Rechteck, der Text darin wird leider nicht weiss.

Das SVG in Deinem Beispiel ist per object eingebunden, damit haben meine alten Tests in Safari funktioniert, nur per img nicht.

[Matthias Scharwies]

Guten Abend!

bekanntlich hat der Safari Probleme, in per <img src="..."> geladenen SVGs den Darkmode zu erkennen.

Die Lösung soll angeblich sein, SVGs nicht als img, sondern als object einzubinden.

Ich hatte jetzt ein paar Tage Ruhe und Muße, um mal zu überlegen, wo der Kasus Knaxus liegt.

Seit 2014 hatte ich SVGs erstellt, bei denen ich Grafik-Objekte und Text zu Infografiken kombiniert hatte.

Genial, dass SVG auch CSS versteht.

Genial, dass SVG sogar prefers-color-scheme versteht. So konnte man im Dunklen Mode die dunkle Schrift auf weiß ändern, damit sie auf dunklem Hintergrund wieder sichtbar ist.

Hier habe ich eine Sache vergessen: Woher weiß die Grafik, welche Hintergrundfarbe vorhanden ist?

---

Im Tutorial zur Textfarbe in CSS steht folgendes:

Es ist sinnvoll, neben der Farbzuweisung der Schriftfarbe mit color auch den Hintergrund mit background-color zu gestalten.

---

Und das gilt auch hier: Eine dunkle Textfarbe in SVGs erfordert einen weißen/hellen Hintergrund für :root/ oder svg.

Eine solche Grafik wird in einem img normal dargestellt; der alt-Text in einem Screenreader normal vorgelesen oder beim Nichtladen im Browser angezeigt.

Falls ein Browser nun Dark Mode erkennt, wird die Webseite, aber auch das SVG umgestellt, wenn es eine Medienabfrage von prefers-color-schemeenthält. Man kann - gerade auch bei einem heruntergeladenen Bild aber nicht von einer bestimmten Hintergrundfarbe ausgehen. Deshalb sollten immer Text- und Hintergrundfarbe festgelegt werden. Der Safari würde so das SVG laden und mit schwarzem Text und weißem Hintergrund darstellen; andere Browser würden in den Dark Mode umschalten. progressive enhancement

Irgendwann zieht der Safari schon nach!

Das erfordert bei einer Änderung der Hintergrundfarbe im Wiki zwar ein erneutes Handling, ist aber auch für heruntergeladene Bilder passend.

Ich hoffe, dass ich euch überzeugt habe, dass ein workaround mit object nicht nötig ist.

Herzliche Grüße
Matthias Scharwies

[Rolf B]

Hallo Matthias,

aus der Diskussion mit J.J. habe ich den Schluss gezogen, dass ein SVG-Replace mit <object> eine Katastrophe wäre.

Es ist aber auch so, dass prefers-color-scheme:dark nicht die einzige Möglichkeit ist. Ich nehme an, dass Safari das aus Datenschutzgründen verweigert, denn über diese Mediaquery kann man beliebige CSS Eigenschaften aktivieren und damit das Farbmodes des Hostdokuments exfiltrieren.

Bei :root { color-scheme: light dark; } ist es anders. Das wirkt sich nur auf die light-dark() Funktion aus und deren Ergebnis kann man - glaube ich - nicht exfiltrieren.

Man kann in einem img keine aktive Radiogruppe einbauen. Ich habe https://wiki.selfhtml.org/local/color-scheme-selectable.svg jetzt so geändert, dass der Default color-scheme: light dark; ist, und bitte jetzt die Mackies darum, das nochmal zu betrachten.

Testseite mit voreingestelltem light mode
Testseite mit voreingestelltem dark mode

Die Testseite bindet das SVG einmal als object und einmal als img ein. Umschalten des color-scheme während der Anzeige ist kein relevanter Usecase, darum habe ich zwei verschiedene HTML Seiten mit unterschiedlichem Default gemacht.

Rolf

[Bertie]

Salü Rolf

Hier Bildschirmfotos von Safari.

Jeweils links Deine Testseite mit light mode voreingestellt, rechts dark mode.

So sieht das auf einem Mac im hellen Modus aus:

… und so, wenn der Mac im Dunkelmodus läuft:

Jeweils unten wieder gut sichtbar: Safari schaltet per ìmg` eingebunden das SVG nicht um.

Also plädiere ich ebenfalls für die einfachere Herangehensweise:

• bei img bleiben
• bei Infografiken mit Text ausserhalb hinterlegter Flächen den Hintergrund zu stylen per svg { background-color: … } für hell und dunkel
• ob brutal weiss und schwarz hinterlegen oder z.B. hellgrau und dunkelblau wäre noch zu überlegen
• bei Text in abgeschlossenen eingefärbten Formen könnte das SVG wahrscheinlich transparent bleiben

[Rolf B]

Hallo Bertie,

vielen Dank.

Heißt also:

• Ein SVG als img bekommt im Safari vom Darkmode nichts mit, egal ob das System oder die Seite auf Darkmode eingestellt sind. Safari tut grundsätzlich so, als sei der Lightmode eingestellt.

Das ist in FF und Chromia anders. Ja, es ist eine Privacy-Lücke, ich kann auf diese Weise die Information exfiltrieren, dass der Benutzer Darkmode verwendet.

• Ein SVG als object bekommt im Safari die Darkmode-Einstellung des Systems mitgeteilt, nicht die Darkmode-Einstellung der Hostseite. Das ist nicht toll, aber Spec-Konform - Chromia halten sich nicht an die Spec und teilen dem SVG den Darkmode-Zustand der Hostseite mit. Was zu einer besseren Darstellung führt.

Konsequenz: Die Darstellung als img ist nicht Darkmode-tauglich. Die Darstellung als object taugt, solange die Seite im System-Darkmode ist

Dafür habe ich bei object das Problem, dass ich das Bild nicht so einfach als Image-Link verwenden kann, weil das object die Events verschluckt.

Ich muss jetzt was essen. Damit ich ausgiebig kotzen kann!

Rolf

[Bertie]

Salü Rolf

Ja, leider sehr traurig.

Hab' gerade die neue «Safari Technology Preview» 221 installiert und sehe, Apple hat in nächster Zeit wohl keine Pläne das Verhalten zu ändern.

Meine Testseite sieht damit immer noch gleich aus:

Meinen Beitrag oben kann ich nicht mehr ändern, hier zur Präzisierung von
"bei Infografiken mit Text ausserhalb hinterlegter Flächen den Hintergrund stylen per svg { background-color: … } für hell und dunkel"

… damit meine ich natürlich per CSS im SVG drin, nicht in der Seite.

[Rolf B]

Hallo Bertie,

eigentlich würde ich img bevorzugen, wegen besserer Verträglichkeit für Events und Bildgröße.

Für eine Einbindung über img könnte ich im SVG-Replacer #dark an die URL anhängen, wenn auf der Host-Seite der Darkmode aktiv ist. Das lässt sich im SVG per CSS abfragen.

:root {
   color-scheme: light dark;
}
:root:has(#dark:target) {
   color-scheme: dark;
}

Dann noch einen Eventhandler auf die MediaQueryList von matchMedia() zu hängen, der das #dark bei Bedarf hinzufügt oder entfernt, ist nicht mehr viel Arbeit.

Rolf

[Bertie]

Salü Rolf

Ja, auch ich bevorzuge die Verwendung von img.

Und einfach im SVG per CSS das svg-Element stylen für einen Hintergrund.

Hier eine Testseite:

https://www.macsimum.ch/SELF HTML/Test_SVG_mit_Hintergrund.html,

sieht so aus:

Ups, grad' fällt mir noch auf: Eigentlich bräuchten wir das svg-Element nur für den light mode als hellen Hintergrund im SVG zu stylen für den doofen Safari rechts im Bild. Sobald die guten Browser das SVG korrekt in den dark mode umschalten, dürfte es dort auch transparent auf der dark mode Seite angezeigt werden. Sieht man in diesem Beispiel nicht, weil ich den Hintergrund der Seite für den dark mode gleich gefärbt habe.

Also svg { background-color: hsl(202 16% 90%); } im SVG drin. Ich habe mal das helle grau --grey3 aus der Farbpalette verwendet.

[Rolf B]

Hallo Bertie,

Ups, grad' fällt mir noch auf:

Das fällt mir in die Augen und quillt aus den Ohren gleich wieder raus. Anders gesagt: hä?

Rolf

[Bertie]

Salü Rolf

Wenn Du Dir den Code der SVG-Datei

https://www.macsimum.ch/SELFHTML/Baum_xml-01_mit_Hintergrund.svg

anschaust, bekommt hier am Ende das SVG einen hellgrauen Hintergrund:

<svg id="Baum_XML" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 1339 662">
  <defs>
    <style type="text/css">
      svg {
        background-color: hsl(202 16% 90%);
      }
etc.

Weil Safari das SVG (per img) nicht in den dark mode umschaltet, bräuchten wir für den dark mode im SVG (den nur die guten Browser beherrschen) nicht unbedingt die weitere Stilanweisung für einen dunklen Hintergrund weiter unten

@media (prefers-color-scheme:dark) {
  svg {
    background-color: hsl(201 50% 13%);
  }
etc.

im SVG drin.

[Matthias Scharwies]

Mahlzeit!

Irgendwie drehen wir uns seit 4 Wochen im Kreis. Deshalb möchte ich jetzt festlegen, wie wir mit Bildern im Wiki umgehen.

Wir haben das Makeover geschafft, zu dem auch ein Dark Mode gehört. Vielen Dank an @Rolf B . Es gab zahlreiche Anpassungen, so hatten Tabellen, aber auch thumbnails einen hellgrauen Hintergrund, der mit weißer Schriftfarbe nicht harmonierte.

Ziel des Dark Mode ist imho aber, das Teiltransparenzen den Hintergrund durchscheinen lassen, so wie hier:

Links ist das Bild normal verlinkt ([[Datei:Beispiel.svg]])
rechts mit Thumbnail und thumbcaption: ([[Datei:Beispiel.svg|thumb|Grundformen in SVG]])

Der weiße Hintergrund war ein Bug, den ich auch gemeldet hatte. Umso erstaunter war ich, dass er heute als Feature eingebaut wurde:

Ich habe das in der der Mediawiki:Selfhtml.css korrigiert, damit die thumbcaption im Darkmode sichtbar ist und damit teiltransparente Grafiken den passenden Hintergrund durchscheinen lassen.

Wie kriegt man aber im Safari, der kein prefers-color-scheme beachtet, die passende Textfarbe hin?

Nur im Bild!

Hier habe ich die Ergebnisse unserer Versuche zusammengefasst:

Hilfe:Infografiken in SVG

Bsp. 1 prefers-color-scheme

Datei:Gruppenwechsel_Bahnreisender_Fahrplan.svg

Standard ist Light Mode (Schwarze Schrift auf weißem Grund), dann eine media query:

      svg {
        background-color: white;
      }
      text {
        font-family: Helvetica, Arial, sans-serif;
        font-size: 28px;
				fill: #333;
      }
      #Kreise {
        fill: #fff;
        stroke: #c82f04;
        stroke-width: 4;
      }

@media (prefers-color-scheme:dark) {
    svg {
        background-color: #112632;
    }

    text {
        fill: white;
    }
	
    circle {
        fill: pink;
    }
}

Ergebnis: auf dem iPhone ist die Schrift auch im Dark Mode dank weißem Hintergrund lesbar - in anderen Browsern wird umgeschaltet:

Bsp. 2 Blau geht immer!

Unser SELF-Blau steelBlue/ #337599 passt zu allem:

 #Zahlen {
		fill:white;
 }
#Kreise {
        fill: SteelBlue;
  }
#Kreise, #Verbindungen {
        stroke: steelBlue;
}

 @media (prefers-color-scheme:dark) {
 #Kreise {
          fill: #112632;
        }
 }

Hier gibt es keinen Hintergrund und die Schriftfarbe ändert sich nicht.
Das einzige was hier umschaltet, ist das fill für die Kreise.

@Bertie - vielen Dank für die SVGs.

Vorgehensweise

Ich bin gestern durch Spezial:Nicht_kategorisierte_Dateien und habe nicht benutzte Dateien, Dubletten und anderes gelöscht.

Übrig bleiben einige ToDos, von denen Bertie die meisten schon vektorisiert hat! Vielen Dank!

Jetzt müssen wir halt durch die Infografiken durch und schauen, wo sich dunkler Text auf dunklem Hintergrund befindet - ganz schön tricky, wenn man den gar nicht sieht.

Herzliche Grüße
Matthias Scharwies

[Rolf B]

Hallo Matthias,

Der weiße Hintergrund war ein Bug, den ich auch gemeldet hatte.

Nicht in meiner makeover-Todoliste. Oder ich identifiziere ihn dort nicht.

Wenn's anderswo steht, verliere ich den Überblick. Den verliere ich im Moment sowieso, bei mir geht so viel durcheinander, es ist schrecklich.

Umso erstaunter war ich, dass er heute als Feature eingebaut wurde:

Mit anderen Worten: Du kackst mich an, dass ich am Skin entgegen der Zielrichtung rumgeändert hätte. Du bist im Irrtum.

Bilder mit der Option thumb bekommen durch Mediawiki automatisch einen #F9F9F9 Hintergrund. Das ist schon ewig so, und das Makeover müsste hierfür noch eine Regel bekommen. Die fehlt, ja, und ich habe diesbezüglich nichts gemacht. Schon gar nicht heute, ich bin im Büro und habe auf die Skinfiles am Server keinen Zugriff.

Bilder ohne die Option thumb bekommen von Mediawiki keinen Extrahintergrund. Insofern hast du vielleicht bei Bildern auf anderen Seiten transparenten Hintergrund gesehen. Auf der XML/Regeln/Baumstruktur-Seite war der Hintergrund weißgrau und du hast es für eine Änderung gehalten?

Ich habe heute nur eins gemacht: Mir fiel der helle Hintergrund des Beispielbaums auf und ich habe in den DevTools gesehen, dass die thumb-Option den erzeugt. Da die Bildbreite ohnehin auf 200px gesetzt ist, hielt ich thumb für unnötig und habe es entfernt. Die Links halte ich bei Wiki-Illustrationen eh für unnötig, darum habe ich sie auch rausgenommen. Und die hast Du dann gleich wieder eingebaut… Juhu, Edit War!

Dass durch thumb auch die Bildunterschrift verschwunden ist, hatte ich nicht bemerkt. Das ist eine Eigenschaft von Mediawiki - Bildunterschriften gibt's nur mit der thumb-Option. Wenn diese Unterschrift wieder rein soll, dann muss auch thumb wieder rein. Und DANN wird deine CSS Änderung relevant. Ob aber transparent richtig ist? Die Mediawiki-Idee ist wohl, dass das Bild im light-Mode einen leicht grauen Hintergrund bekommt, um es vom weißen Seitenhintergrund abzusetzen. D.h. im Darkmode sollte es - wenn es ein thumb ist - ebenfalls einen leicht vom Hintergrund abweichenden Hintergrund erhalten.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Der weiße Hintergrund war ein Bug, den ich auch gemeldet hatte.

Nicht in meiner makeover-Todoliste. Oder ich identifiziere ihn dort nicht.

Mein/Unser Problem, dass wir die vielen Sachen nicht in einer Tabelle sammeln, sondern es eben über PNs, Mails etc, läuft.

Umso erstaunter war ich, dass er heute als Feature eingebaut wurde:

Mit anderen Worten: Du kackst mich an, dass ich am Skin entgegen der Zielrichtung rumgeändert hätte. Du bist im Irrtum.

Bilder mit der Option thumb bekommen durch Mediawiki automatisch einen #F9F9F9 Hintergrund. Das ist schon ewig so, und das Makeover müsste hierfür noch eine Regel bekommen.

Ja, das habe ich doch geschrieben. Aber es dient Euch als weißer Hintergrund, der angebl. Probleme löst, dabei aber neue schafft!

Die fehlt, ja, und ich habe diesbezüglich nichts gemacht. Schon gar nicht heute, ich bin im Büro und habe auf die Skinfiles am Server keinen Zugriff.

Deshalb schreib ich seit 2 Wochen in Mediawiki:Selfhtml.css.^[1] Wenn meine Änderungen sinnvoll sind, kannst du es da ins Skin übertragen oder wieder löschen.

Dass durch thumb auch die Bildunterschrift verschwunden ist, hatte ich nicht bemerkt. Das ist eine Eigenschaft von Mediawiki - Bildunterschriften gibt's nur mit der thumb-Option. Wenn diese Unterschrift wieder rein soll, dann muss auch thumb wieder rein.

Sie ist ja nicht verschwunden. Der helle Hintergrund der Standard-Mediawiki-Einstellung bleibt; die Schriftfarbe wird zentral in #content {color: var(--text-color);} auf weiß gesetzt und wird so unsichtbar.

Deshalb ist der in diesem Thread vielfach vorgeschlagene Weg, doch irgendwie einen weißen Hintergrund herzubringen, eben keine Lösung.

Und DANN wird deine CSS Änderung relevant. Ob aber transparent richtig ist? Die Mediawiki-Idee ist wohl, dass das Bild im light-Mode einen leicht grauen Hintergrund bekommt, um es vom weißen Seitenhintergrund abzusetzen. D.h. im Darkmode sollte es - wenn es ein thumb ist - ebenfalls einen leicht vom Hintergrund abweichenden Hintergrund erhalten.

Meinetwegen, aber so, dass der Kontrast ausreichend hoch ist.

Herzliche Grüße
Matthias Scharwies

Wenn wir jetzt heut Abend ein Feierabendbier zusammen genießen und das Wiki mal vergessen könnten.

---

1. @media print {} (Zeile 300);
   schwarze Textfarbe für badExample im Darkmode (weil Hintergrund hellrot bleibt!) ;
   transparenter Hintergund für div#thumbinner ↩︎

[Rolf B]

Hallo Matthias,

Wenn wir jetzt heut Abend ein Feierabendbier zusammen genießen und das Wiki mal vergessen könnten.

Nein, wir müssen über's Wiki reden, weil wir hier nur aneinander vorbei schreiben. Auch deine Antwort jetzt löst in mir wieder nur ein Hä? nach dem anderen aus.

Aber es dient Euch als weißer Hintergrund, der angebl. Probleme löst, dabei aber neue schafft!

Hä? Ich habe keinen weißen Hintergrund eingebaut. Ich habe

• optional eine Klasse light, um einen hellen Hintergrund durch den Autor, passend zum Bild, bestellen zu können
• bei den <object> Elementen bemerkt, dass der Browser bei color-scheme Inkongruenz einen Hintergrund einfügt

Bertie hat diverse Versuche gemacht, aber es ist nicht so, dass wir derzeit im direkten Gespräch wären und ich Dinge auf Berties „Anstiftung“ hin geändert hätte. Es gab nur meinen optionalen Ersatz des SVG-Replacers, bei dem ich dieses <object> Problem bemerkt habe.

Wenn diese Unterschrift wieder rein soll, dann muss auch thumb wieder rein. Sie ist ja nicht verschwunden.

Hä? Hast Du in die Historie geschaut? Da war vorher eine Bildunterschrift. Sie steht jetzt nicht mehr direkt da. Ohne "thumb" wird die Bildbeschreibung, die man im Bildlink festlegt, zum Tooltip.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Wenn wir jetzt heut Abend ein Feierabendbier zusammen genießen und das Wiki mal vergessen könnten.

Nein, wir müssen über's Wiki reden, weil wir hier nur aneinander vorbei schreiben. Auch deine Antwort jetzt löst in mir wieder nur ein Hä? nach dem anderen aus.

Aber es dient Euch als weißer Hintergrund, der angebl. Probleme löst, dabei aber neue schafft!

Hä? Ich habe keinen weißen Hintergrund eingebaut.

Das habe ich auch nicht behauptet, sondern hier geschrieben:

Es gab zahlreiche Anpassungen, so hatten Tabellen, aber auch thumbnails einen hellgrauen Hintergrund, der mit weißer Schriftfarbe nicht harmonierte.

Dass dies in den ursprünglichen Mediawiki-Einstellungen zu finden war, hatte ich jetzt als bekannt vorausgesetzt. So hatte sich damals @Der Martin mokiert, wer denn Tabellen eine feste Hintergrundfarbe gäbe. andererseits auch sinnvoll, wenn man eine Schriftfarbe festlegt, auch den Hintergrund zu berücksichtigen.

Ich habe

• optional eine Klasse light, um einen hellen Hintergrund durch den Autor, passend zum Bild, bestellen zu können
• bei den <object> Elementen bemerkt, dass der Browser bei color-scheme Inkongruenz einen Hintergrund einfügt

Ja, und ich habe immer wieder gesagt, dass wir keinen weißen Hintergrund brauchen, da er oft kontraproduktiv wirkt.

Bertie hat diverse Versuche gemacht, aber es ist nicht so, dass wir derzeit im direkten Gespräch wären und ich Dinge auf Berties „Anstiftung“ hin geändert hätte. Es gab nur meinen optionalen Ersatz des SVG-Replacers, bei dem ich dieses <object> Problem bemerkt habe.

Wenn diese Unterschrift wieder rein soll, dann muss auch thumb wieder rein. Sie ist ja nicht verschwunden.

Hä? Hast Du in die Historie geschaut? Da war vorher eine Bildunterschrift. Sie steht jetzt nicht mehr direkt da. Ohne "thumb" wird die Bildbeschreibung, die man im Bildlink festlegt, zum Tooltip.

Ah, du meinst auf dieser Seite! Ok, das besser' ich wieder aus. (Aber die |link=| lass ich weg!)

Mir geht es darum, dass wir nicht zu viel von Mediawiki abweichen.

Herzliche Grüße
Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

jetzt aktualisiert:

Style-Regeln für Infografiken

mit 3 Beispielen:

TL;DR

Ein Festlegen des Hintergrunds ist nur in wenigen Fällen notwendig. Da gehen wir jetzt durch.

Herzliche Grüße
Matthias Scharwies

[Auge]

Hallo

Irgendwie drehen wir uns seit 4 Wochen im Kreis. Deshalb möchte ich jetzt festlegen, wie wir mit Bildern im Wiki umgehen.

Aber was hat das mit mit der Execute Order 1606 zu tun ^[1]?

*scnr*

Tschö, Auge

---

1. Ich weiß, gestern war der 16.06., was wohl die Nummerierung erklären dürfte. Irgendwie triggerte es mich, dennoch nach „dem Original“ zu suchen. Es gibt ja aktuell nur wenige (wenn auch heftige) Nachrichten neben den täglichen Executive Orders des US-amerikanischen Quasi-Diktators. ↩︎

[Matthias Scharwies]

Guten Morgen,

Aber was hat das mit mit der Execute Order 1606 zu tun [^1]?

Wie du schon sagtest, nichts!

Das ist ja eines der Themen im Geschichtsunterricht der 9.Klasse: Wie Brünings Griff zu den Notverordnungen nach §48 der Rechsverfassung den Demokratie-Gedanken ausgehöhlt hatte.

Und die Analogie verblüfft: Was uns bei Trump empört, wurde aufgrund fehlender Mehrheiten schon seit ca. 2012 in den USA praktiziert, sodass die sich da gar nicht mehr aufregen. Irgendwo in einem Tom Clancy-Roman aus den 90ern galt das noch als Mega-Tabubruch für größte Krisenzeiten.

Herzliche Grüße
Matthias Scharwies