Grundsatzfrage zur Struktur von SVG-Grafiken

[Auge]

Hallo

Hier wird ja in den letzten Wochen fleißig an der Umstellung vieler Grafiken von Rastergrafiken auf SVG im SelfHTML-Wiki gearbeitet und über die dabei auftretenden Probleme diskutiert. Ich verfolge das Thema aufmerksam, auch wenn ich nicht bis in jede der diskutierten Ecken vorstoße. Dabei ist mir bei meinen eigenen Bildern etwas aufgefallen.

Zur bestimmung des Aussehens benutze ich aktuell eine Mischung aus SVG-Attributen und CSS. Den CSS-Block binde ich direkt im Dokument ein.

<?xml version="1.0" standalone="yes"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 264 264" width="264" height="264">
 <style type="text/css">
  <![CDATA[
  /* CSS-Angaben */
  ]]>
 </style>
 <g>
  <!-- die Bildelemente -->
 </g>
</svg>

Hier wird, so hatte ich das irgendwo erspäht, der CSS-Block innerhalb <defs> notiert.

<?xml version="1.0" standalone="yes"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 264 264" width="264" height="264">
 <defs>
  <style type="text/css">
  <![CDATA[
  /* CSS-Angaben */
  ]]>
  </style>
 </defs>
 <g>
  <!-- die Bildelemente -->
 </g>
</svg>

So habe ich das auch schon in Bildern aus anderen Quellen gefunden, das aber auch nicht durchgehend. Beides funktioniert. Gibt es da den einen richtigen Weg?

Weiterhin ist mir in den Diskussionen zum Dark-Mode aufgefallen, dass bei den Bildern für das Wiki svg { background: transparent; } verwendet wird. Ich habe den Bildhintergrund bisher mit svg { fill: transparent; } durchsichtig gemacht. Die Frage ist hier also ebenfalls, ob es dafür einen „richtigeren“ Weg gibt.

Tschö, Auge

[Matthias Scharwies]

Servus!

Hallo

Hier wird ja in den letzten Wochen fleißig an der Umstellung vieler Grafiken von Rastergrafiken auf SVG im SelfHTML-Wiki gearbeitet und über die dabei auftretenden Probleme diskutiert. Ich verfolge das Thema aufmerksam, auch wenn ich nicht bis in jede der diskutierten Ecken vorstoße. Dabei ist mir bei meinen eigenen Bildern etwas aufgefallen.

Zur bestimmung des Aussehens benutze ich aktuell eine Mischung aus SVG-Attributen und CSS. Den CSS-Block binde ich direkt im Dokument ein.

<?xml version="1.0" standalone="yes"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 264 264" width="264" height="264">
 <style type="text/css">
  <![CDATA[
  /* CSS-Angaben */
  ]]>
 </style>
 <g>
  <!-- die Bildelemente -->
 </g>
</svg>

Zuerst: Die Dokument-Deklaration kann weg! Auch wenn SVG2 noch nicht verabschiedet ist, halten sich alle Browser-Hersteller dran.

Hier wird, so hatte ich das irgendwo erspäht, der CSS-Block innerhalb <defs> notiert.

Geht, zusammen mit pattern, symbols und Verläufen. Häufig habe ich die aber gar nicht und deshalb lasse ich <defs> weg.

BTW: Die ganzen filter-Elemente sind vom Code her eine Pest. Die CSS-Eigenschaft filter ist einfacher zum Schreiben und verwendet die gleichen Algorithmen!

So habe ich das auch schon in Bildern aus anderen Quellen gefunden, das aber auch nicht durchgehend. Beides funktioniert. Gibt es da den einen richtigen Weg?

Ich glaube nicht.

Weiterhin ist mir in den Diskussionen zum Dark-Mode aufgefallen, dass bei den Bildern für das Wiki svg { background: transparent; } verwendet wird.

Nein, das wurde bisher nicht definiert und deshalb ist der weiße Hintergrund irgendwie selbstverständlich gewesen. Erst als wir die Textfarben änderten, musste auch ein Hintergrund zur Sicherstellung des Kontrasts angelegt werden.

Imho passt die Eigenschaft CSS/Eigenschaften/color-scheme dafür nicht, weil ja nicht klar ist, was der „Text“ bzw „Vordergrund“ ist.

Ich habe den Bildhintergrund bisher mit svg { fill: transparent; } durchsichtig gemacht. Die Frage ist hier also ebenfalls, ob es dafür einen „richtigeren“ Weg gibt.

Eigentlich fill, ich hab's aber grad ausprobiert und auch einen path mit background-coloreingefärbt. Das war aber ein Quadrat - da weiß ich nicht, wie sich das bei anderen Formen verhält. [EDIT] - nein geht nicht! [/EDIT]

Herzliche Grüße
Matthias Scharwies

[Rolf B]

Hallo,

background(-color) bezieht sich auf den Hintergrund des Elementrechtecks. Beim SVG-Element bezieht es sich auf den Hintergrund des SVG-Viewports. D.h. bei einem eigenständig angezeigten SVG-Element ist es das ganze Fenster, bei einem SVG in einem <img>-Element ist es das Rechteck des img Elements.

Aber das war's auch. Ich habe für background-color in SVG-Kindelementen keinen Effekt gesehen (von foreignObject mal abgesehen).

fill bewirkt nur etwas in SVG Grafikprimitiven, soweit sie füllbar sind. Also sowas wie rect, circle, polyline, path. Bei line bewirkt es vielleicht etwas, aber man sieht nichts davon, weil die füllbare Fläche 0 ist.

Das SVG Element ist kein Primitiv, darum wirkt fill dort nicht.

color-scheme legt das Farbschema fest, das vom HTML- oder SVG-Dokument unterstützt wird. light, dark oder beides. Gibt man nur eins an, dann wird auch nur das verwendet. Gibt man beide an, hängt es an den OS- oder Browsereinstellungen, welches verwendet wird.

Das verwendete Farbschema beeinflusst die Farbe der Scrollbars, die canvas-Grundfarbe, einige Form-Elemente und ein paar andere Sachen, z.B. die Unterkringelung der Rechtschreibprüfung. Die übrigen Farben muss die Webseite mit prefers-color-scheme oder der light-dark()-Farbfunktion eigenständig ans Farbschema anpassen.

Die Hintergrundfarbe eines SVG ist per Default transparent. Um das zu ändern, muss man es explizit angeben. Eine Sonderlocke haben wir bei <object>-Einbindung entdeckt, da generiert der Browser einen schwarzen oder weißen Hintergrund für das Object, auf dem dann das SVG dargestellt wird. Und das tut er dann, wenn das genutzte color-scheme von Dokument und SVG abweichend ist.

einen path mit background-coloreingefärbt.

Huh? Das schaff ich weder in Chrome noch Firefox, weder stand-alone noch als eingebettetes SVG. Hast Du ein Beispieldokument?

Rolf

[Matthias Scharwies]

Servus!

einen path mit background-coloreingefärbt.

Huh? Das schaff ich weder in Chrome noch Firefox, weder stand-alone noch als eingebettetes SVG. Hast Du ein Beispieldokument?

Nein, funzt nicht. Keine Ahnung was ich gemacht hatte - ich hatte das 649kb-Netzlogo offen und dort einmal das SVG und dann vermeintlich einen Pfad eingefärbt, der ein Viereck darstellen sollte. Jetzt im Minimalbeispiel bleiben beide Grundformen schwarz (Defaultwert für fill).

Herzliche Grüße
Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Zuerst: Die Dokument-Deklaration kann weg!

Du meinst die XML-Deklaration <?xml version="1.0" standalone="yes"?>? Ja, kann weg. Aber …

Auch wenn SVG2 noch nicht verabschiedet ist

… was hat das mit SVG2 zu tun? Ich hab in älteren Specs nichts gefunden, was darauf hindeuten würde, dass das mal anders gewesen wäre. Nur, dass SVG eine XML-Anwendung ist; und XML verlangt keine XML-Deklaration.^[1]

---

Hier wird, so hatte ich das irgendwo erspäht, der CSS-Block innerhalb <defs> notiert.

Geht, zusammen mit pattern, symbols und Verläufen. Häufig habe ich die aber gar nicht und deshalb lasse ich <defs> weg.

Die Spec empfiehlt die Verwendung von defs. Ich glaube aber auch nicht, dass die Welt untergeht, wenn man style nicht in defs packt.

---

BTW: Die ganzen filter-Elemente sind vom Code her eine Pest. Die CSS-Eigenschaft filter ist einfacher zum Schreiben und verwendet die gleichen Algorithmen!

Njein.

Es gibt einige Filter, die man einfach per CSS haben kann. Und es gibt andere, die man nur mit SVG zur Verfügung hat.

☞ TIL about filter

🖖 Live long and prosper

---

1. Es sei denn, man verwendet eine andere Zeichencodierung als UTF-8, was im Web sowieso nicht ratsam ist. AFAIS ist selbst bei UTF-16 (und UTF-32?) keine Angabe der Zeichencodierung in einer XML-Deklaration notwendig, weil die Zeichencodierung anhand des BOM erkannt wird. ↩︎

[Auge]

Hallo

Zuerst: Die Dokument-Deklaration kann weg!

Du meinst die XML-Deklaration <?xml version="1.0" standalone="yes"?>? Ja, kann weg. … XML verlangt keine XML-Deklaration.

Ok. Kann, muss aber nicht, oder? Da ich natürlich mit UTF-8 arbeite, gehe ich mal durch meine Bilderchen und lösche die Deklaration.

Hier wird, so hatte ich das irgendwo erspäht, der CSS-Block innerhalb <defs> notiert.

Geht, zusammen mit pattern, symbols und Verläufen. Häufig habe ich die aber gar nicht und deshalb lasse ich <defs> weg.

Die Spec empfiehlt die Verwendung von defs. Ich glaube aber auch nicht, dass die Welt untergeht, wenn man style nicht in defs packt.

Da ich in recht vielen der Bilder Gradienten habe und die sowieso in <defs> notiert sind, kann ich die Style-Blöcke auch dort hinein verschieben und <defs>, wo es fehlt, ergänzen. Wenn ich den von dir verlinkten Abschnitt der Spezifikation richtig interpretiere, kann ich auch die <symbol>s dort hinein packen.

Auch wenn's nicht verpflichtend ist, ist es für mich konsequent, das einheitlich zu bauen.

Danke auch an @Rolf B für die Erklärung dazu, auf welche Elementarten fill wirkt, dass es auf <svg> nicht wirkt und dass es das auch nicht muss.

Tschö, Auge