Transparente Grafiken im neuen dark mode und Problem mit Apple Safari Browser

[Bertie]

Nach dem Austausch mit Matthias Scharwies und Rolf B gibt es dazu einige Pendenzen.

Mit dem neuen dark mode im wiki gibt es noch Probleme mit transparenten Grafiken (SVG und PNG). Der Safari Browser schaltet leider SVG's mit intern gestyltem dark mode nicht um, wenn das SVG mit dem img Tag eingebunden ist.

[Bertie]

Problem mit transparenten SVG Dateien im dark mode:

Safari schaltet per img Tag eingebundene SVG-Dateien nicht um (in den im SVG per CSS gestylten dark mode), sondern zeigt auf der dark mode Seite die light mode Variante der Grafik an.

Ohne Hintergrund im SVG bliebe ein weiterer Nebeneffekt, dass die grossen Browser auf dem Mac beim direkt Aufruf eines SVG auch im dark mode die Grafik in einem weissen Fenster zeigen. Klickt man z.B. bei diesem Upload: https://wiki.selfhtml.org/wiki/Datei:Node.chat_logo.svg … auf die Grafik, wird dieses SVG alleine im Fenster geöffnet: https://wiki.selfhtml.org/images/a/a0/Node.chat_logo.svg

Ist das auch auf anderen Betriebssystemen auch so?

[Bertie]

Von Bertie gefundener Hack für eine CSS Browserweiche ist keine gangbare Lösung:

/* Safari-spezifische Styles für hellen Hintergrund bei SVGs im dark mode,
   weil Safari beim Einbinden per img das SVG intern nicht in den dark mode
   umschaltet */
@supports (hanging-punctuation: first)
      and (font: -apple-system-body) 
      and (-webkit-appearance: none) {
  /* nur fuer img, wenn der Dateiname auf .svg endet */
  img[src$=".svg"] {
    background-color: white;
  }
}

Edit Rolf B: CSS als Code markiert und Zeilenumbrüche eingefügt

Prüfung durch Rolf:

Dein Vorschlag mit @supports hat einen Nachteil. Damit fragen wir nach den Features A,B,C, um daraus zu schließen, dass wir einen Workaround für Feature X brauchen, das aber logisch von A, B und C komplett unabhängig ist. Die einzige Abhängigkeit ist, dass A, B und C aktuell nur von Safari erfüllt werden.

Und das heißt: Es ist keine Feature-Query, sondern eine CSS Browserweiche. Feature A ist dazu noch instabil, weil hanging-punctuation jederzeit von anderen Browsern eingebaut werden kann. Ein Apple-Systemfont ist schon etwas besser.

Grundsätzlich ist die Idee gut, einen Mechanismus zu haben, der zentral wirkt und nicht bei jedem Bild extra gesetzt werden muss. Ich fürchte nur, es wird noch Jahre dauern, bis Apple das fixt und wir den Workaround herausnehmen können.

kleiner Test: @supports (font: irgendwas) schlägt auf meinem Chrome unter Windows immer fehl, ganz gleich, ob ich für irgendwas -apple-system-body oder Arial hinschreibe. Das liegt ziemlich sicher daran, dass die font-Eigenschaft eine Sammeleigenschaft ist, in der font-size und font-family Pflicht sind.

Eine @support-Abfrage auf (font-family:Arial) meldet hingegen Erfolg. Die Abfrage (font-family: NotInstalledFont) aber leider auch. Und (-webkit-appearance:none) ebenfalls - die webkit-Präfixe gibt es in Safari und in Chrome. Heißt also: hanging-punctuation ist das einzige, was Chrome daran hindern würde, einen weißen Hintergrund zu setzen. Bis zu dem Tag, wo er dieses Feature unterstützt - und der ist absehbar, denn caniuse.com schreibt, dass alle Hersteller an der Implementierung arbeiten würden.

Also, leider, auch als Workaround ist das kein gangbarer Weg.

Vorschlag Rolf: Meine Idee war einmal, im SVG Replacer auf Darkmode abzufragen und dann der Bild-URL ein #dark anzuhängen. Das könnte man im SVG als zweiten Darkmode-Schalter nutzen (via #dark:target). Das mache ich jetzt schon für die Icons am rechten Rand.

[Bertie]

Vorschlag Bertie: SVG intern für dark mode stylen, aber ohne Hintergrundrechteck

Anstatt in jedes transparente SVG hinten noch ein Rechteck zu zeichnen funktioniert bei mir auch, direkt das Element <svg> zu stylen. Ein hübscher Nebeneffekt ist (in Firefox / Safari / Chrome auf dem Mac), dass beim Öffnen des SVG’s alleine nicht nur die SVG Viewbox, sondern das gesamte Browser-Fenster die Hintergrundfarbe erhält, erscheint dann wie in angehängtem Bildschirmfoto links.

Wir könnten damit auch Code sparen, der rote auf der rechten Seite würde durch den grünen auf der linken Seite ersetzt. Das für den dark mode, für den light mode würde "#Hintergrund {fill: white;}" ersetzt durch "svg {background: white;}“, also etwa gleich viel Code.

Online habe ich allerdings nichts zum direkten Stylen von <svg> gefunden, vielleicht ist das nicht standardkonform und kommt daher für SELFHTML nicht in Frage?

[Bertie]

Transparente PNG

Für alte transparente Bilder im PNG Format sehe ich ein verwandtes Problem:

Im dark mode bleiben die PNG wie sie halt sind, da können wir auch in der Datei selbst nichts programmieren.

Idee für einen Workaround: Wenn in diesem Beispiel https://wiki.selfhtml.org/wiki/Hilfe:SELFHTML-Logos

… die schwarze Box ein PNG enthält, könnte man in der zentralen CSS-Datei vielleicht dem img eine helle background-color geben?

[Rolf B]

Hallo Bertie,

danke für das Übertragen der Mail-Diskussion ins Forum.

Hinweis: schau bitte hier, wie im Forum Code als solcher markiert wird, so dass er passend dargestellt wird.

Für alte transparente Bilder im PNG Format

hilft leider auch meine Workaround-Idee mit #dark in der URL nicht. Mist. Und wenn ich foo.svg durch foo.svg#dark ersetze, dann sind auch CSS Regeln wie [href$=.svg] unwirksam - das ist alles ein schreckliches Gefummel.

Für Einzelbilder habe ich im Makeover eine Klasse vorgesehen, die man auf eingebundenen Bildern setzen kann - was dann der Wiki-Autor tun muss - und die im Darkmode für Bilder einen hellen Hintergrund setzt. Allerdings wird das Setzen einer Klasse vom <gallery>-Element (einem Pseudo-HTML Tag von Mediawiki) nicht unterstützt, d.h. man müsste die Galerie dafür anders erzeugen.

Es gibt aber auch noch die <object>-Variante. Das hatte ich schon mal entdeckt, aber wieder vergessen, und das ist etwas, das ich einmal ausprobieren möchte. Wenn diese Form der SVG-Einbindung in allen Browsern funktioniert, könnte der SVG-Replacer die <img> Elemente durch <object> ersetzen. Ich weiß nur noch nicht, welche Folgeprobleme wir uns damit aufhalsen. Bei transparenten PNGs nützt es natürlich nichts, aber ich hoffe, das ist ein marginales Problem.

Rolf

[Bertie]

Salü Rolf

Danke für den Tipp zur Code-Formatierung, versuche ich gleich hier.

Wäre es zu brutal, im zentralen CSS einfach für alle per img eingebundenen PNG's im dark mode einen Hintergrund zu generieren?

So etwa:

/* Hintergrund fuer transparente PNG Dateien im dark mode */
@media (prefers-color-scheme:dark) {
  img[src$=".png"] {
    background-color: white;
  }
}

[Bertie]

oder Alternative: Wenn IRGENDWO ".png" vorkommt, egal ob noch von "#dark" gefolgt. Und vielleicht statt weiss dass hellste grey3 aus der SELFHTML Farbpalette:

/* Hintergrund fuer transparente PNG Dateien im dark mode */
@media (prefers-color-scheme:dark) {
  img[src*=".png"] {
    background-color: hsl(202 16% 90%);
  }
}

[Matthias Scharwies]

Servus!

Ich finde, dass es technisch kein Problem wäre, dem svg-Element ein

style="background-color: white" zu geben - dann hätte man aber helle Flecken auf dem dunklen Hintergrund.

Bei DOM2.svg wäre evtl. eine blaue Linienfarbe anstelle des Wechsels von Schwarz auf weiß ein gangbarer Weg.

oder Alternative: Wenn IRGENDWO ".png" vorkommt, egal ob noch von "#dark" gefolgt. Und vielleicht statt weiss dass hellste grey3 aus der SELFHTML Farbpalette:

/* Hintergrund fuer transparente PNG Dateien im dark mode */
@media (prefers-color-scheme:dark) {
  img[src*=".png"] {
    background-color: hsl(202 16% 90%);
  }
}

Wäre möglich. Ich gucke mal, wie viele pngs/gifs das überhaupt sind.

Herzliche Grüße

Matthias Scharwies

[Bertie]

Salü zusammen

PNG's und GIF's können wir für den dark mode nicht intern anders stylen wie die SVG's.

Ich habe mit der Seite

https://wiki.selfhtml.org/wiki/Hilfe:SELFHTML-Logos#Archiv

experimentiert und in Chrome im Inspector eine CSS-Anweisung hinzugefügt. Damit man die Auswirkungen im Bildschirmfoto besser sieht, habe ich den zusätzlichen img background rot eingefärbt:

Vorschlag: Im zentralen CSS folgende Anweisung ergänzen für alle Dateien, bei denen im Dateinamen irgendwo der Ausdruck «.png» oder «.gif» vorkommt, etwa so:

@media (prefers-color-scheme:dark) {
  img[src*=".png"], img[src*=".gif"] {
    background-color: white;
  }
}

Bei PNG's und GIF's ohne Transparenz (2. Beispiel im Bildschirmfoto) hätte das keinen Effekt.

[Matthias Scharwies]

Guten Morgen,

Bis auf die Grafik von 2004 ganz links sehen die anderen doch ok aus! Häufig ist es doch grade beabsichtigt, dass ein png einen transparenten Hintergrund hat.

Vorschlag: Im zentralen CSS folgende Anweisung ergänzen für alle Dateien, bei denen im Dateinamen irgendwo der Ausdruck «.png» oder «.gif» vorkommt, etwa so:

Würde ich nicht machen. Ich kann der einen Grafik einen weißen Hintergrund geben, wenn ihr wollt.

Herzliche Grüße
Matthias Scharwies

[Matthias Scharwies]

Mahlzeit,

Vorschlag: Im zentralen CSS folgende Anweisung ergänzen für alle Dateien, bei denen im Dateinamen irgendwo der Ausdruck «.png» oder «.gif» vorkommt, etwa so:

Würde ich nicht machen. Ich kann der einen Grafik einen weißen Hintergrund geben, wenn ihr wollt.

So sieht's jetzt aus:

Einerseits wollte ich immer mal eine gute Version des Netz-Logos haben,
andererseits widerstrebt es mir ein Logo von 1996 umzugestalten,
damit es in's 2025er Konzept passt - damals hatte Grafiken eben 69x103 Pixel und waren unscharf.

Herzliche Grüße
Matthias Scharwies

[Auge]

Hallo

Einerseits wollte ich immer mal eine gute Version des Netz-Logos haben,
andererseits widerstrebt es mir ein Logo von 1996 umzugestalten,
damit es in's 2025er Konzept passt - damals hatte Grafiken eben 69x103 Pixel und waren unscharf.

Das ist aber nur die eine Seite. Die alten Logos waren für die Anzeige auf einem hellen/weißen Hintergrund hin entworfen. Jetzt sollen sie aber auch auf einem dunklen Hintergrund angezeigt werden. Meiner Meinung nach ist das Einfügen eines weißen Hintergrunds in die Bilder gerechtfertigt, da somit ein Eindruck der für die Bilder einstmals vorgesehenen „Umgebung“ hergestellt wird.

Tschö, Auge

[Bertie]

Salü Matthias

Der weisse Saum der transparenten PNG's im dark mode ist aber schon nicht schön, wenn man genauer hin schaut (anklicken für grosse Version):

Und die 4 Bilder unten sehen nur sauber aus, weil sie in einer weissen Box div.thumbinner eingebettet sind. Wenn man eines davon anklickt (oben im Bild) das selbe auf dunklem Hintergrund, dann verschwindet der Text "Die Energie des Verstehens":

P.S. bei der grünen Markierung "Text?" zeigt sich das alte Problem mit weissem Text in weisser Box.

[Rolf B]

Hallo,

aaalso - ich habe beim Makeover-Skin ausdrücklich eine Regel für die Galerie eingefügt:

:root {
    /* Auszug aus dem Skin-CSS */
    --blue-dark3: hsl(201 50% 7%);
    --blue1: hsl(201 50% 60%);
    --grey4: hsl(26 22% 95%);
    --bgdarker: light-dark(var(--grey4),var(--blue-dark3));

    --prefs-bg: light-dark(#f9f9f9,var(--bgdarker));
    --prefs-border: light-dark(#cccccc,var(--blue1));
}

li.gallerybox div.thumb {
    border: 1px solid var(--prefs-border);
    background-color: var(--prefs-bg);
}

D.h. ich verwende die Rahmen- und Hintergrundfarbe, die auch der Einstellungen-Dialog nutzt.

Die Farbpalette an sich ist so eine Sache. Einerseits möchte Matthias die Farbpalette vorgeben, andererseits fehlen dort Pastellabstufungen, um das Look-And-Feel des Wiki beizubehalten. Die Farben #f9f9f9 und #cccccc sind aus Vector übernommen, dafür hab ich noch keine Selfhtml-Entsprechung eingesetzt. #f9f9f9 ist heller als das aktuelle --grey4, #cccccc liegt zwischen --grey2 und --grey3.

Dass es bei transparenten Bildern für das Mediawiki-Element <gallery> nicht passt, einfach dunklen Hintergrund einzusetzen, sehe ich ein. Das kann man ändern - aber wehe, man setzt in diese Galerie dann ein SVG ein, das auf Darkmode reagiert. Wie zum Beispiel die Neuinterpretation des Netz-Logos.

Die Frage ist auch, ob man eine Methode braucht, um für Pixelbilder eine Darkmode-Version bereitzustellen. Im JavaScript weiß ich nicht, ob sowas existiert. Bei Einzelbildern könnte man wieder mit class operieren. In der <gallery> gibt es allerdings keine Möglichkeit, einzelnen Bildern eine Merkmal für die Darstellungsart zuzuordnen. Und ich möchte eigentlich auch nicht die Gallery-Extension auseinandernehmen, um zu schauen, ob sie Hooks anbietet. Das einzige, was geht, ist <gallery class="light"> - das setzt die Klasse light auf dem ul Element, das Mediawiki aus <gallery> macht. Das kann ich nutzen, um die Galerie generell mit hellem Hintergrund zu versehen.

Bei Einzelbildern, die irgendwo im Wikitext als [[Datei:xyz.png|...]] eingebunden werden, kann eine Klasse gesetzt werden. Hier ist class=light bereits vorgesehen. Würde man class=light-dark zuordnen, könnte der SVG-Replacer mithelfen und das img Element durch ein picture-Element ersetzen, worin per source Medienabfragen auf light- und darkmode abgefragt wird. Die Darkmode-Version des Bildes muss dann per Namenskonvention gefunden werden (also beispielsweise foo.png und foo-dark.png).

Ich tue mich gerade schwer damit, eine Anforderungsliste "Bilddarstellung" zusammen zu bekommen. Mit Einzelbildern und Galeriebildern, mit intransparenten Pixelbildern, mit transparenzhaltigen Pixelbildern, mit SVGs, die auf Darkmode reagieren oder auch nicht, je nach SVG und je nach Browser.

Rolf

[Matthias Scharwies]

Guten Abend,

Ich tue mich gerade schwer damit, eine Anforderungsliste "Bilddarstellung" zusammen zu bekommen. Mit Einzelbildern und Galeriebildern, mit intransparenten Pixelbildern, mit transparenzhaltigen Pixelbildern, mit SVGs, die auf Darkmode reagieren oder auch nicht, je nach SVG und je nach Browser.

Ja! Ich auch! Und deshalb glaube ich auch nicht, dass wir da etwas SELF-Spezifisches entwerfen müssen.

Das Beispiel für die gallery sind die 20 Jahre alten Logos, wo ich wie gesagt nicht weiß, ob es überhaupt legitim ist, sie für den Einsatz in den 2030er Jahren fit zu machen. Wie viele galleries haben wir denn überhaupt?

Das gleiche gilt für pngs mit teiltransparenten Hintergründen. Viel ist durch SVGs ersetzt worden.

Die letzten hochgeladenen pngs sind:

• Mosaic-Browser
• Wikipedia- Logo
• Tabellen

Bei den ersten beiden würde ein weißer Hintergrund doch bescheuert aussehen. Ihr könnte das bei den Dateiversionen beobachten.

Beim Schichtenmodell (oops - ist ein SVG!) hat @Bertie einen weißen Hintergrund eingebaut. Imho passt das auch im Dark Mode.

Aber nicht bei allen SVGs, so auch nicht hier:

Wir sollten nicht zu viel feintunen, vor allem wenn es so viel Ausnahmen gibt.

Es warten so viele Baustellen: Frickl 2, Webhosting, etc. …

Herzliche Grüße
Matthias Scharwies

[Rolf B]

Hallo Matthias,

Wie viele galleries haben wir denn überhaupt?

SELECT title FROM `get_currentpages` where text like '%<gallery%'

(get_currentpages ist eine View, die ich erzeugt habe und die mir alle aktiven Seiten liefert - manuell muss man dazu über die Page, Revision und Text-Tabelle turnen)

fixed - Blue_Beanie_Day
works - CSS/Tutorials/Vermischen_mit_Blend-Modes
works - Grundlagen/Was_ist_das_Internet?
works - HTML/Attribute/inputmode
fixed - Hilfe:SELFHTML-Logos
fixed - Verein/Protokolle/virtuelle_Mitgliederversammlung_2016/Tagesordnung
works - Verein/Treffen_2004
works - Wiki/MediaWiki/Bilder
works - Zeichencodierung/Emojis_und_Emoticons

Was kann <gallery>

Rolf

[Gunnar Bittersmann]

@@Bertie

Mal unabhängig davon, ob man picture in MediaWiki verwenden könnte, wundere ich mich, dass das in keinem Browser funktioniert, verschiedene Bilder für light und dark mode zu verwenden:

<picture>
  <source
    src="https://bittersmann.de/test/assets/moon.svg"
    media="(prefers-color-scheme: dark)"
  />
  <img
    src="https://bittersmann.de/test/assets/sun.svg"
    alt="Sun/Moon"
  />
</picture>

☞ Beispielseite (edit: nachträglich ausgebessert)

Oder mach ich da was falsch?

🖖 Live long and prosper

[Tabellenkalk]

Hallo,

Oder mach ich da was falsch?

klappt's wenn du im Source-Element srcset statt src verwendest?

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

Oder mach ich da was falsch?

klappt's wenn du im Source-Element srcset statt src verwendest?

Ähm, ja. 🤦‍♂️

Dann klappt’s auch im Safari.

(Beispielseite ausgebessert. Oder s.a. Codepen)

Wenn also picture in Mediawiki geht, könnte das die Lösung sein.

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar,

man braucht dann

• zwei Bilder
• einen Mechanismus für Wiki-Autoren, ein Bildgruppe light/dark angeben zu können
• und dabei die diversen Features der Bildeinbindung zu erhalten

Ob sich das besser im SVG Replacer oder in einer Parser-Extension löst, muss man schauen.

Auf jeden Fall ist picture besser als ein URL Umschalter in JavaScript. Danke.

Rolf

[Bertie]

Salü Gunnar

Per <object> einbinden würde in Safari auch funktionieren, wäre kürzer und bräuchte nur 1 SVG mit eingebautem dark mode. Hier ein Beispiel online: https://www.macsimum.ch/SELFHTML/Test_SVG_transparent_img_object.html

Gemäss Spezifikation von object muss mindestens entweder data oder type definiert sein, folgendes wäre also auch ohne type="image/svg+xml" regelkonform:

<object data="Neue-Responsivitat_ohne_Hintergrund.svg">Schema neue Responsivität</object>

Ob das allerdings barrierefrei ist, habe ich leider nicht herausgefunden, z.B. ob Screenreader den Text "Schema neue Responsivität" sehen können.

Das für img übliche alt Tag ist offiziell für objekt nicht als Möglichkeit aufgeführt.

[Bertie]

Die Testseite habe mal vom iPhone im dark mode vorlesen lassen, hier die Video-Aufnahme: https://www.macsimum.ch/SELFHTML/Test_SVG_transparent_img_object_vorlesen.mp4

Erkenntnisse zur Barrierefreihet:

• Bei img wird das alt Tag wie erwartet vorgelesen.
• Bei object wird der Text zwischen öffnendem und schliessendem Tag leider NICHT vorgelesen.

Aber: Die im SVG enthaltenen text-Elemente werden dafür vorgelesen, was eine Art erweiterte Barrierefreiheit wäre.

[Gunnar Bittersmann]

@@Bertie

• Bei object wird der Text zwischen öffnendem und schliessendem Tag leider NICHT vorgelesen.

Oh, ich esse meine Worte.

Danke fürs Testen. (Ja, das sollte man besser immer tun. Nicht erzählen, wie es eigentlich sein sollte, aber nicht ist.)

🖖 Live long and prosper

[Gunnar Bittersmann]

@@Bertie

Aber: Die im SVG enthaltenen text-Elemente werden dafür vorgelesen, was eine Art erweiterte Barrierefreiheit wäre.

Dafür sollte doch eigentlich das title-Element da sein.

Dumm nur (d.h. unerwünscht), dass das (ebenso wie das title-Attribut in HMTL) als Tooltip angezeigt wird.

🖖 Live long and prosper

[Bertie]

Salü Gunnar

Ich habe das mit title mal in meinem Test ausprobiert. https://www.macsimum.ch/SELFHTML/Test_SVG_transparent_img_object.html

Dafür steht oben im per object eingebundenen SVG jetzt:

<svg id="Schema_Neue_Responsivitaet" role="img" aria-labelledby="svgtitel" xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 910 610">
  <title id="svgtitel">Schemazeichnung zur Veranschaulichung der neuen Responsivität</title>

Also:

• Für mehr Barrierefreiheit von SVG's kann role="img" ergänzt werden.
• Für Screenreader muss man 2 Dinge machen und verknüpfen:
  • <title id="svgtitel">Schemazeichnung …</title> ergänzen
  • und dann oben über diese ID verknüpfen mit aria-labelledby="svgtitel"

Damit liest mindestens der Screenreader vom iPhone (analog zum alt Attribut bei img) nur noch den Titel vor: "Schemazeichnung zur Veranschaulichung der neuen Responsivität".

Und Du hast recht: Das erscheint als Tootltip beim drüber hovern, würde mich nicht stören.

[Gunnar Bittersmann]

@@Bertie

Per <object> einbinden würde in Safari auch funktionieren, wäre kürzer und bräuchte nur 1 SVG mit eingebautem dark mode.

Ah, fein. Das ist natürlich besser.

Gemäss Spezifikation von object muss mindestens entweder data oder type definiert sein

Beides schadet aber auch nicht:

<object data="Neue-Responsivitat_ohne_Hintergrund.svg" type="image/svg+xml">
  Schema neue Responsivität
</object>

Ob das allerdings barrierefrei ist, habe ich leider nicht herausgefunden, z.B. ob Screenreader den Text "Schema neue Responsivität" sehen können.

Ja, das sollten sie können.

Das für img übliche alt Tag …

alt-Attribut. Du meinst „Attribut“.^[1]

… ist offiziell für objekt nicht als Möglichkeit aufgeführt.

Und das ist auch gut so. Die Alternative ist da, wo sie hingehört: im Elementinhalt, nicht in einem Attribut. Dass es bei img andreesen anders ist, ist ein Sprachdesignfehler von HTML, der sich nicht mehr korrigieren lässt. (s. dieses Posting und auch die Ergänzung dazu)

Bei object u.a. wurde es dann richtig gemacht.

Und eigentlich ist es andersrum: der Text ist die Grundlage, das Bild (bzw. anderes Media-Objekt) ist die Alternative, die Verbesserung, die verwendet wird, wenn der Client das unterstützt (bei Bildern tun das so gut wie alle Browser). Progressive enhancement.

Nun sind Screenreader keine Clients, sie sagen aber die Grundlage an: den Text. (edit: siehe @Bertie’s Erkenntnis)

🖖 Live long and prosper

---

1. Anstatt tag name würde ich heute eher element type sagen. ↩︎

[Rolf B]

Hallo Gunnar und Bertie,

Vielen Dank, dss ihr beide das durchanalysiert.

Ich hoffe, dieses Wochenende einen alternativen SVG Replacer erstellen zu können, der object verwendet.

Und ich werde mir was ausdenken, womit man solche Module durch individuelle Experimentierversionen ersetzen kann (durch Schalter in localStorage). Dadurch kann jeder was ausprobieren ohne Adminrechte zu haben.

Rolf