Frage zum Wiki-Artikel „SVG/Tutorials/Einstieg“

[ReiPar]

Hallo miteinander,

ich möchte lernen, skalierbare Vektorgrafiken (SVG) zu erstellen. Mit HTML und CSS habe ich mich bereits befasst. Nun suche ich nach einem Einstieg, SVGs zu stellen. Da Web-Browser SVGs anzeigen können, möchte ich auf HTML zunächst gänzlich verzichten. Die Einbindung in HTML ist für mich nicht die erste Frage, sondern eine weiterführende, die zwar nicht unwichtig ist, aber eben nicht an allererster Stelle steht.

Wo finde ich also einen allerersten Einstieg in das Erstellen von Standalone-SVG?

Freundliche Grüße

ReiPar

[Tabellenkalk]

Hallo,

es wurde da mal was vorbereitet: SVG im Wiki. Das ist die Übersichtsseite mit vielen weiterführenden Links, auch externe. Vielleicht findest du da das was du brauchst!?

Gruß
Kalk

[Gunnar Bittersmann]

@@Tabellenkalk

es wurde da mal was vorbereitet: SVG im Wiki. Das ist die Übersichtsseite

Für eine Übersichtsseite ist die ziemlich unübersichtlich.

mit vielen weiterführenden Links, auch externe. Vielleicht findest du da das was du brauchst!?

Der erste Link SVG/Tutorials/Einstieg/Grundformen scheint recht brauchbar zu sein, wenn auch schlecht betitelt. Unter Grundformen würde ich Linien, Rechtecke, Kreise/Ellipsen usw. verstehen, die im ersten Teil behandelt werden.

Pfade sind keine Grundformen, aber in einem Artikel zum Einstieg richtig aufgehoben. Das macht der Artikel schon ganz gut, beides gegenüberzustellen.

Was der Artikel richtig schlecht macht, ist von „Pixeln“ zu sprechen. Hat da jemand nicht verstanden, wofür das V in SVG steht? Der Begriff „Pixel“ ist dermaßen falsch, dass mir die Lust am Weiterlesen vergeht.

🖖 Живіть довго і процвітайте

[Matthias Scharwies]

Servus!

Der erste Link SVG/Tutorials/Einstieg/Grundformen scheint recht brauchbar zu sein, wenn auch schlecht betitelt. Unter Grundformen würde ich Linien, Rechtecke, Kreise/Ellipsen usw. verstehen, die im ersten Teil behandelt werden.

Pfade sind keine Grundformen, aber in einem Artikel zum Einstieg richtig aufgehoben. Das macht der Artikel schon ganz gut, beides gegenüberzustellen.

Die MDN macht's genauso, in der W3C wird nur zum Schluss auf die Pfade verwiesen.

Auch wenn hier der Begriff „Pixel“ verwendet wurde, rechnet SVG in Wirklichkeit mit dimensionslosen Größen (engl. unitless values). Dies ist sinnvoll, weil so fehleranfällige Umrechnungen von Einheiten vermieden werden.

Was der Artikel richtig schlecht macht, ist von „Pixeln“ zu sprechen. Hat da jemand nicht verstanden, wofür das V in SVG steht? Der Begriff „Pixel“ ist dermaßen falsch, dass mir die Lust am Weiterlesen vergeht.

Hatten wir mehrmals schon. Damit niemand jetzt denkt,, dass du recht hättest, habe ich die in deinen Augen problematische Stelle oben hinzugefügt.

Ich genieß jetzt das kühlere Wetter, nachdem hier gestern eine Sintflut mit Hagel für Abkühlung gesorgt hat.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Auch wenn hier der Begriff „Pixel“ verwendet wurde, rechnet SVG in Wirklichkeit mit dimensionslosen Größen (engl. unitless values). Dies ist sinnvoll, weil so fehleranfällige Umrechnungen von Einheiten vermieden werden.

Damit niemand jetzt denkt,, dass du recht hättest

??

habe ich die in deinen Augen problematische Stelle oben hinzugefügt.

Man sollte sich da nicht herauswinden und versuchen zu erklären, warum man einen völlig unpassenden Begriff verwendet, sondern ganz einfach den falschen Begriff nicht verwenden.

Was gemeint ist: Einheiten/Teile (im von viewBox bzw. width/height definierten Koordinatensystem).

🖖 Живіть довго і процвітайте

[ReiPar]

Vielen Dank, Gunnar Bittersmann, für diese Äußerung. Genau damit habe ich nämlich massive Verstehensprobleme.

Wo schreibt man bei SV-Grafiken als Einheit px, wo nicht?

Welchen Effekt hat es wo, wenn man px schreibt oder wenn man einheitenlos schreibt?

Insgesamt ist es für mich immer noch ein ungelöstes Rätsel, wozu man im svg-Tag width und height braucht und was die viewBox ist, die in den Beispielen oft völlig andere Zahlen hat als width und height (auch das Seitenverhältnis ist oft anders). Wozu brauche ich zwei unterschiedliche Koordinatensysteme?

Das sind viele Fragen. Ich möchte sie gar nicht unbedingt hier im Forum beantwortet haben. Wichtiger wäre mir, dass die entsprechenden Wiki-Seiten überarbeitet würden und mir dann jemand hier ins Forum schreibt, dass die Überarbeitung stattgefunden hat und ich mal drüberschauen möge. Das mache ich dann gerne und gebe Rückmeldung.

HTML habe ich mir ab den 90er-Jahren autodidaktisch beibringen können - auch mittels SELFHTML, CSS genauso. Die Dokumentation von Stefan Münz habe ich als exzellent erlebt. Das Wiki ist wirklich auch nicht schlecht, aber die didaktische Qualität ist durchwachsen (und auch Flüchtigkeitsfehler sind immer wieder drin). Ganz herzlichen Dank an alle Autoren!

Das positive Erlebnis bei HTML und CSS wiederholt sich bei SVG bisher nicht. Ich empfinde in SELFHTML den Einstieg in SVG als ziemlich schwierig, obwohl ich sehr IT-affin bin und gerne programmiere.

Gerne würde ich konkrete Tipps geben, an welcher Stelle man wie verbessern müsste, aber soweit bin ich noch nicht.

Meine konkrete Frage nach einem Einstieg in SVG ohne HTML (und ohne CSS, aber schon mal mit Grundform, Pfad und Text,) ist noch nicht zu meiner Zufriedenheit beantwortet. Selbstverständlich habe ich fleißig gesucht, bevor ich meine (erste) Frage (überhaupt im SELFHTML-Forum) gestellt habe. Die von Tabellenkalk (LibreOffice-Fan wie ich?) freundlicherweise verlinkte Seite kannte ich schon. Sie hilft mir aber nicht wirklich weiter. Vielleicht gibt es ja bisher gar keine solche Seite, wie ich sie suche.

[Rolf B]

Hallo ReiPar,

Gunnar ist gerne mal mit weißer Soutane und roten Schuhen unterwegs.

Prinzipiell hat er recht: SVG arbeitet in einem eigenen Koordinatensystem, das über die Viewbox definiert ist. Alle Angaben, die man in den Attributen von SVG Elementen macht, beziehen sich auf dieses Koordinatensystem und werden einheitenlos notiert.

<svg viewBox="0 0 200 200">
   <circle cx="50" cy="50" r="20" />
</svg>

Dieses Koordinatensystem wird dann an Hand der Breite und Höhe der SVG Elementbox auf Browserkoordinaten übertragen. Ob dabei das "aspect ratio" (Verhältnis Breite zu Höhe) erhalten bleibt, wird durch das SVG Attribut preserveAspectRatio bestimmt.

Um die Sache aber nicht zu einfach zu machen, kann man etliche Maße für SVG Elemente auch über CSS definieren. Breiten, Höhen, etc. Und an der Stelle kann ich eben auch px schreiben (muss man nicht, tatsächlich akzeptiert SVG CSS auch Zahlenwerte), was aber das Koordinatensystem der Viewbox meint

<svg viewBox="0 0 200 200">
   <style>
      circle {
         stroke: black;  
         stroke-width: 5;       /* geht beides! */
         stroke-width: 5px;
      }
   </stype>
   <circle cx="50" cy="50" r="20" />
</svg>

Ich bin aber gar nicht mehr sicher, ob das schon immer so war oder ob das eine Neuerung ist. Bislang war ich der Überzeugung, dass die Werte in den SVG Attributen immer Zahlenangaben (ohne Einheit) und die Werte in den CSS Eigenschaften immer Längenangaben (mit Einheit) sein müssten.

Rolf

[Matthias Scharwies]

Servus!

Insgesamt ist es für mich immer noch ein ungelöstes Rätsel, wozu man im svg-Tag width und height braucht und was die viewBox ist, die in den Beispielen oft völlig andere Zahlen hat als width und height (auch das Seitenverhältnis ist oft anders). Wozu brauche ich zwei unterschiedliche Koordinatensysteme?

Dann hattest Du im SELF-Wiki auf der Seite SVG/Elemente/svg bei ViewBox einen Link auf „Viewport“ gesetzt?

Damit ist aber nicht der Viewport des Anzeigegeräts gemeint. Ich habe den Link umgebogen. Wohin, kommt später!

Wann verwendet man width und height? Probier es aus!

<svg width="100" height="100" viewBox="0 0 200 200">
   <circle cx="50" cy="50" r="20" />
</svg>

… nimmt im Browserfenster eben nur 100 x 100 Einheiten ein. Du kannst aufgrund der viewBox-Angabe aber auch noch in x="200" und y="200" zeichnen, es wird entsprechend skaliert.

<svg viewBox="0 0 200 200">
   <circle cx="50" cy="50" r="20" />
</svg>

Diese Grafik wird ebenfalls auf einem Zeichenbrett von 200x 200 Einheiten gezeichnet, vom Browser auf die gesamte Größe skaliert.

Heutzutage gibt es eben fast keinen Anwendungsfall für SVG ohne Browser, deshalb lässt man die width und height-Angaben im Allgemeinen weg. Das wird dann im HTML-Dokument über CSS erledigt.

Prinzipiell hat er recht: SVG arbeitet in einem eigenen Koordinatensystem, das über die Viewbox definiert ist. Alle Angaben, die man in den Attributen von SVG Elementen macht, beziehen sich auf dieses Koordinatensystem und werden einheitenlos notiert.

Um die Sache aber nicht zu einfach zu machen, kann man etliche Maße für SVG Elemente auch über CSS definieren.

Das wird im SVG-Einstieg so gehandhabt:

1. Kapitel Grundformen mit XML-Attributen, da die Elemente alle anders gefärbt werden.

2. Kapitel SVG mit CSS stylen Hier wird eben die Möglichkeit mit CSS erklärt. Für jemanden, der sich als IT-affin bezeichnet, sollte der Sprung zum schon bekannten CSS nicht zu schwierig sein.

Breiten, Höhen, etc. Und an der Stelle kann ich eben auch px schreiben (muss man nicht, tatsächlich akzeptiert SVG CSS auch Zahlenwerte), was aber das Koordinatensystem der Viewbox meint

<svg viewBox="0 0 200 200">
   <style>
      circle {
         stroke: black;  
         stroke-width: 5;       /* geht beides! */
         stroke-width: 5px;
      }
   </stype>
   <circle cx="50" cy="50" r="20" />
</svg>

Ich bin aber gar nicht mehr sicher, ob das schon immer so war oder ob das eine Neuerung ist. Bislang war ich der Überzeugung, dass die Werte in den SVG Attributen immer Zahlenangaben (ohne Einheit) und die Werte in den CSS Eigenschaften immer Längenangaben (mit Einheit) sein müssten.

Ja, aber im SELF-Wiki verwendet man auch im CSS nur dimensionslose Einheiten, mit einer Ausnahme:

Das wird im Abschnitt Geometrie-Attribute beschrieben:

Beachten Sie: Als XML-Attribut benötigt r keine Einheit; innerhalb des style-Elements ist eine Angabe von px erforderlich, da Firefox dies sonst nicht rendert.

---

Ich habe das Tutorial so aufgebaut, dass in jedem Kapitel Schritt für Schritt etwas neues erklärt wird - von Einfachen hin zum Komplexeren.

Die von Dir angesprochene „Problematik“ von viewBox wird im 5. Kapitel SVG in responsiven Webseiten angesprochen, besonders im Abschnitt „SVG als Leinwand“.

Im Normalfall willst du mit SVG ein Icon oder ein Diagramm zeichnen; eine animierte Kamerafahrt kommt eben erst später.

Stell Dir einmal vor, wenn ich damit angefangen hätte und jemand nach 30min Lektüre fragen würde, wann denn endlich die erste Grafik käme?

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Beachten Sie: Als XML-Attribut benötigt r keine Einheit; innerhalb des style-Elements ist eine Angabe von px erforderlich, da Firefox dies sonst nicht rendert.

Ah, gut zu wissen. In Safari ist das übrigens auch so: Codepen

Gleich mal Tickets aufgemacht: Firefox, Safari

🖖 Живіть довго і процвітайте

[ThomasM]

Hallo Gunnar,

@@Matthias Scharwies

Beachten Sie: Als XML-Attribut benötigt r keine Einheit; innerhalb des style-Elements ist eine Angabe von px erforderlich, da Firefox dies sonst nicht rendert.

Ah, gut zu wissen. In Safari ist das übrigens auch so: Codepen

Gleich mal Tickets aufgemacht: Firefox, Safari

Lese aus den Specs nicht heraus, dass Geometry Properties via CSS als length-percentage keine Einheit haben dürfen (außer bei 0-Werten).

Grüße,
Thomas

[ThomasM]

Nachtrag:

Wobei in den Chromium-Browsern Geometriewerte ohne Einheit im CSS akzeptiert werden.

<defs>
  <style>
    circle { cx: 100; cy: 100; r: 40; fill: #F00; }
    rect   { x: 60; y: 200; width: 400px; height: 100px; fill: #00F; }
  </style>
</defs>
<rect/>
<circle/>

Grüße,
Thomas

[Gunnar Bittersmann]

@@ThomasM

Lese aus den Specs nicht heraus, dass Geometry Properties via CSS als length-percentage keine Einheit haben dürfen (außer bei 0-Werten).

Autsch, ja. Das Firefox-Ticket wurde aus dem Grund auch schon geschlossen.

Dann ist der Weg also, zunächst einmal ein Ticket gegen die Spec zu erstellen. Vorher aber nachforschen, warum das so spezifiziert wurde.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

Vorher aber nachforschen, warum das so spezifiziert wurde.

Aus meiner Sicht ist das eine Sache der Konsistenz. Positionen und Radien sind überall im CSS als Längenangaben definiert. Und einen Datentyp length-percentage-number - gibt's den im CSS irgendwo?

Es ist ja nett, dass die Chromia hier das Verhalten von SVG Geometrieattributen und von Geometrieangaben im CSS gleichziehen möchten. Aber dafür kommt dann CSS-intern die Frage hoch, warum man für CSS das "px" weglassen kann.

Man könnte aber auch andersum die Frage stellen, warum man für SVG Geometrie überhaupt Längen verwendet. Ist es sinnvoll, in einem SVG ein Element mit einer Breite von "10vw" zu definieren, womit ich ein Element habe, das sich den Teufel um die Viewbox des SVG Elements schert?

By the way - kann mir jemand erklären, was die Tilde in den EBNF-Definitionen bedeutet, die die CSS 2.1 Spec und auch MDN verwenden? Hier zum Beispiel. Das mag eine Spezialität von FLEX sein, dem Lexer mit dem CSS definiert ist, aber ich kenne ihn nicht und finde auch nichts, was ein ~ im Kontext von FLEX definiert.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Aus meiner Sicht ist das eine Sache der Konsistenz. Positionen und Radien sind überall im CSS als Längenangaben definiert.

In CSS für HTML. Da würden einheitenlose Angaben ja wenig Sinn machen.

(Bei line-height gehen einheitenlose Angaben. 1.4 tut dasselbe wie 1.4em und 140%.)

Nicht hingegen bei CSS für SVG. Da machen einheitenlose Angaben Sinn – wie sie ja auch in den SVG-Attributen verwendet werden.

Und einen Datentyp length-percentage-number - gibt's den im CSS irgendwo?

Nicht dass ich wüsste. Es gibt aber die Veroderung <number> | <length-percentage> – wie eben bei line-height.

Es ist ja nett, dass die Chromia hier das Verhalten von SVG Geometrieattributen und von Geometrieangaben im CSS gleichziehen möchten.

Ja, finde ich auch.

Aber dafür kommt dann CSS-intern die Frage hoch, warum man für CSS das "px" weglassen kann.

Ich hätte das so erwartet. Wusste gar nicht, dass man für Nicht-Chromia das px hinzufügen muss.

Man könnte aber auch andersum die Frage stellen, warum man für SVG Geometrie überhaupt Längen verwendet.

Sehr gute Frage.

Ist es sinnvoll, in einem SVG ein Element mit einer Breite von "10vw" zu definieren, womit ich ein Element habe, das sich den Teufel um die Viewbox des SVG Elements schert?

IMHO nicht. Ich versuche mal herauszufinden, was der Gedanke dahinter war.

In diesem Beispiel hat der Radius ziemlich wenig mit 10 Zoll gemein (was dasselbe ist wie 960px). Der Radius ist 960 im durch viewBox bestimmten Koordinatensystem.

---

By the way - kann mir jemand erklären, was die Tilde in den EBNF-Definitionen bedeutet, die die CSS 2.1 Spec und auch MDN verwenden?

Case-insensitive.

🖖 Живіть довго і процвітайте

[Der Martin]

Hallo,

Ich genieß jetzt das kühlere Wetter

naja, das ist alles relativ. Kühler als gestern ist es bestimmt. Donnerstag und Freitag hatten wir hier am Nachmittag etwa 35°C, die amtliche Wetterstation am Stuttgarter Flughafen registrierte "nur" 30°C. Heute sind es in der Tat etwa 10° weniger.
Soll mir recht sein - ich bin gerade mit der Kehrwoche dran. Einschließlich Außenbereich.

Ärgerlich nur, dass sich die Wände um mich in den letzten Tagen derart aufgeheizt haben, dass Lüften die Innentemperatur auch nur kurzzeitig mal unter 25°C drückt.

nachdem hier gestern eine Sintflut mit Hagel für Abkühlung gesorgt hat.

Sowas hatten wir hier vor ein paar Tagen. Gewitter, Starkregen und ein bisschen Hagel. Ein paar Minuten lang prasselte der Regen so laut, dass ich den Fernsehton nicht mehr verstanden habe. Lautstärke hochdrehen wollte ich aber auch nicht.

Gestern war nur etwas Grummeln in der Atmosphäre und drei Regentropfen oder so.

Einen schönen Tag noch
 Martin

[Matthias Scharwies]

Servus!

@@Tabellenkalk

es wurde da mal was vorbereitet: SVG im Wiki. Das ist die Übersichtsseite

Für eine Übersichtsseite ist die ziemlich unübersichtlich.

Wir hatten ja mal angedacht, die Linklisten mit Cards zu ergänzen:

Wie fange ich an? (im Test-Wiki)

Sollten wir das auch für die SVG-Portalseite so machen? Und wenn ja, für welche Tutorials?

Oops - grad gemerkt; hier gibt's ja schon Entwürfe: Benutzer:MScharwies/cards

Herzliche Grüße

Matthias Scharwies

PS: Es wird Zeit, dass wir MediaWiki 1.35 und die NativeSvgHandler-Extension bekommen. Hier in der png-Vorschau ist nur ein Pfad zu erkennen; im Original auch Text.

[ReiPar]

Hallo Tabellenkalk,

vielen Dank für deine Mühe, mir zu antworten und vorher eine Seite herauszusuchen. Diese Seite kenne ich schon. Sie enthält aber nicht das, was ich suche.

An alle,

ich habe eine ganze Reihe von Seiten zu SVG gelesen. Meine Fragen resultieren also nicht aus Uninformiertheit. Ich habe auch schon auf Weiteres geantwortet und neue Fragen gestellt, was ich aber zunächst mal noch ruhen lassen will: ein Schritt nach dem anderen.

Meine Frage steht weiterhin unbeantwortet im Raum/Forum:

Wo finde ich einen allerersten Einstieg in das Erstellen von SVG, die noch auf eine Einbindung in HTML und zunächst auch auf CSS verzichtet?

Freundliche Grüße

ReiPar

[Rolf B]

Hallo ReiPar,

unser Wiki enthält ein paar Zeilen über Standalone SVGs. Eine gute anderweitige Quelle kenne ich gar nicht.

https://wiki.selfhtml.org/wiki/SVG/Elemente/svg#Standalone_SVG-Dokumente

Die Angabe eines DOCTYPE ist allerdings umstritten. Angeblich hat das mehr verwirrt als genützt, und bisher habe ich noch nie ein SVG Bild mit DOCTYPE gemacht. Mozilla verlinkt auf diesen Artikel von Jonathan Watt, der generell von DOCTYPEs abrät, auch in SVG 1.0 und 1.1.

Die Namespace-Angaben sind in einem Standalone-SVG aber relevant.

Einen Hinweis habe ich gerade noch nachgetragen: Inline-SVG ist kein XML und deshalb case-insensitive. Eine standalone-SVG achtet dagegen strikt auf Groß- und Kleinschreibung (z.B. viewbox ≠ viewBox).

Ich glaube, weitere Hinweise zu Standalone SVGs braucht es gar nicht. Oder hast Du konkrete Fragen, die spezifisch zu standalone SVGs sind?

Rolf

[Matthias Scharwies]

Servus!

@Samuel fiedler hatte vor Weihnachten dieses Tutorial geschrieben:

• SVG/Tutorials/Laterne,_Sonne,_Mond_und_Sterne

unser Wiki enthält ein paar Zeilen über Standalone SVGs.

https://wiki.selfhtml.org/wiki/SVG/Elemente/svg#Standalone_SVG-Dokumente

Ich hatte schon überlegt, dieses „Anhängsel“ an die Referenzseite dort unterzubringen, weiß aber auch nicht, ob das so sinnvoll ist.

Aber selbst dort werden Farbfestlegungen mit Klassen und einem style-Abschnitt realisiert.

Einen Hinweis habe ich gerade noch nachgetragen: Inline-SVG ist kein XML und deshalb case-insensitive. Eine standalone-SVG achtet dagegen strikt auf Groß- und Kleinschreibung (z.B. viewbox ≠ viewBox).

@Rolf B Danke

Herzliche Grüße

Matthias Scharwies

[ReiPar]

Hallo @Rolf B,

dein Beitrag in Verbindung mit Jonathan Watts Artikel hat mich, meine ich, auf die richtige Spur gebracht. Ich meine jetzt, verstanden zu haben, was mir vorher unklar war.

Auf der Seite SVG/Elemente/svg habe ich mich jetzt auch nicht mehr von den inhaltlichen »Störimpulsen« irritieren lassen. Wenn ich es jetzt richtig sehe, dann gilt Folgendes:

1. Der Abschnitt »XML-Deklaration« gehört nicht hierher, weil es mit vorangestellter XML-Deklaration keine Standalone-SVG-Datei ist, sondern eine XML-Datei, in die SVG eingebunden ist.
2. Da eine DTD laut Jonathan Watt entfallen sollte (nicht nur für SVG 2), ist dieser Abschnitt an dieser Stelle überflüssig. Allenfalls könnte man schreiben, dass man eine DTD voranstellen kann, aber nicht muss.
3. Der Abschnitt »Einbindung externer Stylesheets« gehört ebenfalls nicht unter die Überschrift »Standalone SVG-Dokumente« (Oops, da fehlt noch ein Bindestrich), denn die Einbindung erfolgt laut Text in eingebundenes SVG.

Meine neuen Erkenntnisse habe ich – zusammen mit rein sprachlicher/redaktioneller Überarbeitung – gleich mal eingebaut, allerdings ohne Abschnitte zu löschen. Schaut euch bitte mal folgendes Diff an und gebt mir Rückmeldung, ob ich das richtig gemacht habe: SVG/Elemente/svg: Unterschied zwischen den Versionen

Wie gesagt: Da müsste man meiner Ansicht nach mal aufräumen und manche Abschnitte unter eine andere Überschrift verschieben (evtl. auf derselben Seite).

Was meint ihr?

Grüße

ReiPar

[ThomasM]

Hallo ReiPar,

1. Der Abschnitt »XML-Deklaration« gehört nicht hierher, weil es mit vorangestellter XML-Deklaration keine Standalone-SVG-Datei ist, sondern eine XML-Datei, in die SVG eingebunden ist.

Ein SVG-Dokument <svg …>…</svg> ohne <?xml … ?>-Deklaration bleibt ein XML-Dokument, da ja die Deklaration optional ist und dann UTF-8 als Default-Zeichenkodierung gilt.

Von daher gehört die XML-Deklaration durchaus an eine solche Tutorial-Stelle mit dem Hinweis, dass man diese weglassen kann.

Grüße,
Thomas

[Gunnar Bittersmann]

@@ReiPar

1. Der Abschnitt »XML-Deklaration« gehört nicht hierher, weil es mit vorangestellter XML-Deklaration keine Standalone-SVG-Datei ist, sondern eine XML-Datei, in die SVG eingebunden ist.

Ich verstehe den ganzen Abschnitt nicht.

„Wenn Sie SVG in XML einbinden wollen“ Hä? Was soll ich wollen? Sowas wie SVG in XHTML einbinden? Warum sollte ich das wollen? Wenn jemand einen solchen Usecase hat, wird sie wissen, was sie tut – und dann nicht SELFHTML als Nachschlagewerk brauchen. Für die Leserschaft des SELFHTML-Wikis ist das absolut kein Usecase.

„Sie benötigen dann aber im Prolog eine XML-Deklaration“ Nein, benötige ich nicht, wenn ich nicht eine andere Zeichencodierung als UTF-8 (sollte ebenfalls kein Usecase sein) oder standalone="yes" angeben will. „Empfehlung: Beide Attribute können im Regelfall weggelassen werden“ sollte wohl heißen: Eine XML-Deklaration kann im Regelfall weggelassen werden.

Aber anstatt den Text zu verändern kann wohl der gesamte Abschnitt entsorgt werden.

🖖 Живіть довго і процвітайте

[MudGuard]

Hi,

„Wenn Sie SVG in XML einbinden wollen“ Hä? Was soll ich wollen?

z.B. sowas:

<stvo>
  <verkehrszeichenliste>
    <verkehrszeichen>
      <name>Stopschild</name>
      <bedeutung>hier erst mal anhalten</bedeutung>
      <aussehen>
        <svg ...>
          <octagon fill='red' width='10' height='10'/>
          <text fill='white' font-size='4' y='0' x='4' width='10' text-align='center'>STOP</text>
        </svg>
      </aussehen>
    </verkehrszeichen>
    <!-- ... -->
  </verkehrszeichenliste>
</stvo>

(ja, ich weiß, octagon gibt's nicht usw., ist ja nur als grobe Idee gedacht)

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

„Wenn Sie SVG in XML einbinden wollen“ Hä? Was soll ich wollen?

z.B. sowas:

Ja, sowas fällt unter „Für die Leserschaft des SELFHTML-Wikis ist das absolut kein Usecase.“

Es ist nichts, was ins Kapitel SVG gehört. Weil das niemanden, der gerade SVG erstellt, interessiert. Wenn schon, dann gehört sowas ins Kapitel zu XML.

---

        <svg ...>
          <octagon fill='red' width='10' height='10'/>
          <text fill='white' font-size='4' y='0' x='4' width='10' text-align='center'>STOP</text>
        </svg>

(ja, ich weiß, octagon gibt's nicht usw., ist ja nur als grobe Idee gedacht)

Aber im Artikel steht doch geschrieben: „Dabei müssen dann in einer Dokumenttyp-Deklaration (kurz: DTD) Definitionen und Einstellungen zur Verarbeitung des Dokuments festgelegt werden.“

Also frisch ans Werk:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [
  …
]>

(Adding private elements and attributes to the DTD) 😉

---

Aber mal im Ernst: Was will uns der Autor mit dem Satz im Wiki eigentlich sagen?

Man muss in einer SVG-Datei keine Definitionen und Einstellungen zur Verarbeitung des Dokuments in einer DTD festlegen.

Wurde da ein völlig falscher Begriff verwendet und es ist nicht die DTD, sondern die XML-Deklaration gemeint?

(Und nein, man muss in einer SVG-Datei auch keine Definitionen und Einstellungen zur Verarbeitung des Dokuments in einer XML-Deklaration festlegen.)

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

Man muss in einer SVG-Datei keine Definitionen und Einstellungen zur Verarbeitung des Dokuments in einer DTD festlegen.

Das ist ja das, was ich aus dem Artikel von Jonathan Watts zitiert hatte. Die DOCTYPE Angabe ist eher störend.

Die XML Deklaration - hm - TIL: Sie ist in einer XML Datei optional. Ich dachte immer, das wäre eine Pflichtzeile.

Heißt also: Man kann eine SVG Datei einfach mit <svg xmlns="..."> beginnen lassen, muss sie dann aber zwingend als Unicode speichern (und mit einem passenden BOM starten, damit er die UTF-Variante erkennt). Ob das auch ohne BOM mit UTF-8 klappt? Keine Ahnung, die Spec war mir dafür zu verklausuliert. Und der Browser ist ja auch nicht das einzige Programm, das damit dann zurecht kommen muss.

Wären wir jetzt soweit, dass wir den Wiki-Artikel geradeziehen können?

Rolf

[Gunnar Bittersmann]

@@Rolf B

muss sie dann aber zwingend als Unicode speichern

Als was, bitte?

Beim Speichern kommt die Zeichencodierung ins Spiel. Man kann ebensowenig etwas „als Unicode speichern“ wie es „UFT-8-Zeichen“ gibt. Ich muss wohl mal nachschauen, ob ich von What a charset! einen Mitschnitt finde und den so bearbeitet bekomme, dass ich ihn veröffentlichen kann.

(und mit einem passenden BOM starten, damit er die UTF-Variante erkennt).

Bei UTF-8 braucht man kein BOM.

(Bei UTF-16 braucht man eins. Aber UTF-16 im Web ist wohl keine so gute Idee.)

Keine Ahnung, die Spec war mir dafür zu verklausuliert.

??

“Entities encoded in UTF-16 MUST and entities encoded in UTF-8 MAY begin with the Byte Order Mark” [XML §4.3.3]

🖖 Живіть довго і процвітайте

[JürgenB]

Hallo Gunnar,

(und mit einem passenden BOM starten, damit er die UTF-Variante erkennt).

Bei UTF-8 braucht man kein BOM.

man muss oder kann es aber angeben. Im Notepad++ sieht es so aus:

Gruß
Jürgen

[Rolf B]

Hallo Gunnar,

Als was, bitte?

Als Unicode. Also mit entsprechend gewählten Codepoints. Als Abgrenzung zu ASCII oder „klassischen“ 256-er Zeichensatz Codepoints. Die Festlegung eines konkreten Encodings wäre der nächste Schritt.

“Entities encoded in UTF-16 MUST and entities encoded in UTF-8 MAY begin with the Byte Order Mark” [XML §4.3.3]

Ja, und gleich darauf steht

If the replacement text of an external entity is to begin with the character U+FEFF, and no text declaration is present, then a Byte Order Mark MUST be present, whether the entity is encoded in UTF-8 or UTF-16.

Ich hab's nicht verstanden; ich stecke auch nicht in den XML Fachbegriffen drin. Ich weiß nicht mal, was die mit "Replacement Text" oder "Entity" meinen. Und ich habe keine Lust auf mehrere Stunden Spec-Studium, um alle Querbezüge zu verstehen. Deswegen habe ich das ja als Frage aufgeschrieben.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Als Unicode. Also mit entsprechend gewählten Codepoints. Als Abgrenzung zu ASCII oder „klassischen“ 256-er Zeichensatz Codepoints.

Ach das meinst du. Die Abgrenzung erübrigt sich aber, da der Zeichensatz von XML-Dokumenten (wie auch von HTML-Dokumenten) immer Unicode ist.

If the replacement text of an external entity is to begin with the character U+FEFF, and no text declaration is present, then a Byte Order Mark MUST be present, whether the entity is encoded in UTF-8 or UTF-16.

Ich hab's nicht verstanden

Wie ich das verstehe, ist gemeint: Wenn das Dokument mit dem Zeichen U+FEFF ZERO WIDTH NO-BREAK SPACE beginnt, dann muss ein BOM vorangestellt werden, andernfalls würde ja das U+FEFF als BOM gewertet werden und das Zeichen ZWNBSP nicht mehr vorhanden sein.

Allerdings ist die Verwendung von U+FEFF als ZWNBSP deprecated; für diesen Zweck sollte man stattdessen U+2060 WORD JOINER verwenden. U+FEFF sollte man nur noch als BOM verwenden.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

da der Zeichensatz von XML-Dokumenten (wie auch von HTML-Dokumenten) immer Unicode ist

Sein sollte. Leider treffen sich da Anspruch und Wirklichkeit nicht.

Zumindest habe ich schon genug XML Dokumente mit einem Einbyte Encoding gesehen

Edit: in der Spec steht

Although an XML processor is required to read only entities in the UTF-8 and UTF-16 encodings, it is recognized that other encodings are used around the world, and it may be desired for XML processors to read entities that use them

Rolf

[Der Martin]

Hallo Rolf,

da der Zeichensatz von XML-Dokumenten (wie auch von HTML-Dokumenten) immer Unicode ist

Sein sollte. Leider treffen sich da Anspruch und Wirklichkeit nicht.

Zumindest habe ich schon genug XML Dokumente mit einem Einbyte Encoding gesehen

das ist kein Widerspruch. Du schmeißt immer noch Zeichensatz und Zeichencodierung durcheinander. Ich habe auch Jahre gebraucht, um endlich den Unterschied zu begreifen.

Angenommen, du hast ein Dokument in ISO-8859-1. Das ist immer noch Unicode (bzw. eine Untermenge davon). Die Zeichencodierung ISO-8859-1 legt für insgesamt 256 Zeichen aus dem Unicode-Zeichensatz eine Codierung fest, die vielen tausend anderen Unicode-Zeichen werden nicht behandelt.

Edit: in der Spec steht

Although an XML processor is required to read only entities in the UTF-8 and UTF-16 encodings, it is recognized that other encodings are used around the world, and it may be desired for XML processors to read entities that use them

Also mit anderen Worten: Die Spec gibt eigentlich vor, dass nur UTF-8 oder UTF-16 verwendet werden sollte. XML-Parser sollten dennoch in der Lage sein, auch andere Codierungen zu verarbeiten.

Einen schönen Tag noch
 Martin

[Gunnar Bittersmann]

@@Rolf B

da der Zeichensatz von XML-Dokumenten (wie auch von HTML-Dokumenten) immer Unicode ist

Sein sollte.

Nein, ist.

Zumindest habe ich schon genug XML Dokumente mit einem Einbyte Encoding gesehen

Du verwechselst Zeichensatz und Zeichencodierung.

Der Zeichensatz von XML/HTML-Dokumenten ist Unicode. Immer. Das heißt, man kann in XML/HTML-Dokumenten alle Unicode-Zeichen verwenden.

Wenn man ein XML/HTML-Dokument speichern/übertragen will, werden die Zeichen codiert (in Bytesequenzen). Bei einer Unicode-Codierung (UTF-8, UTF-16) geht das problemlos.

Bei anderen Codierungen (ASCII, ISO 8859) müssen damit nicht codierbare Zeichen (wie bspw. ein Anführungszeichen „ in ISO-8859-1) escapet werden („ bspw. als „. Der XML/HTML-Prozessor löst die Escapes wieder zu den Unicode-Zeichen auf.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

Du verwechselst Zeichensatz und Zeichencodierung.

Ja, scheint so. Der Name Rolf scheint anfällig für sowas zu sein 😢

Rolf

[Gunnar Bittersmann]

@@Rolf B

Du verwechselst Zeichensatz und Zeichencodierung.

Ja, scheint so. Der Name Rolf scheint anfällig für sowas zu sein 😢

ROLF, äh ROFL. 🤣

🖖 Живіть довго і процвітайте

[Matthias Scharwies]

Servus!

Hallo Gunnar,

Man muss in einer SVG-Datei keine Definitionen und Einstellungen zur Verarbeitung des Dokuments in einer DTD festlegen.

Das ist ja das, was ich aus dem Artikel von Jonathan Watts zitiert hatte. Die DOCTYPE Angabe ist eher störend.

Die XML Deklaration - hm - TIL: Sie ist in einer XML Datei optional. Ich dachte immer, das wäre eine Pflichtzeile.

Heißt also: Man kann eine SVG Datei einfach mit <svg xmlns="..."> beginnen lassen,

Man kann ja mal einen Kreis mit Inkscape zeichnen und als svg abspeichern. (So sehen viele SVGs bei Wikimedia Commons aus.)

Unter diesen Code kommt dann was eigentlich nötig ist. Hier habe ich das schon mal erwähnt: SVG/Tutorials/Icons#SVGs_optimieren

Wären wir jetzt soweit, dass wir den Wiki-Artikel geradeziehen können?

So halb hoffe ich, dass das jemand übernimmt.

Was noch fehlt:

• {{Empfehlung|Da das Frickl nur für HTML-Dokumente vorgesehen ist, kopieren Sie das SVG-Markup in ihren [[Editor]] und testen dort!}}

• Hinweis darauf, dass fehlerhaftes Markup, Umlaute ohne utf-8 das Rendern verhindern, da XML (und seine Dialekte) da streng sind.

• Bonus-Points: Diese Seite (SVG/Grafiken_erstellen) irgendwie ans Ende packen / integrieren.

Vielen Dank im Voraus

Matthias Scharwies

[Matthias Scharwies]

Servus!

Meine Frage steht weiterhin unbeantwortet im Raum/Forum:

Wo finde ich einen allerersten Einstieg in das Erstellen von SVG, die noch auf eine Einbindung in HTML und zunächst auch auf CSS verzichtet?

Eine Alternative wäre das schon etwas ältere svg.tutorial.aptico.de

Ich kann das aber nicht uneingeschränkt empfehlen;

• die verwendeten XML-DTDs sind heute nicht mehr nötig;
• ab Kapitel Vier fängt es richtig an, aber selbst dort werden gleich style-Attribute verwendet:

<rect x="310" y="60" width="90" height="40" style="fill:#33cc33; stroke:rgb(0,0,0);" />

Die von Dir postulierte „reine Form“ des SVG ohne HTML & CSS gibt es so nicht.

Ich habe nochmal in die MDN geschaut: developer.mozilla.org/.../SVG/Tutorial

Dort wird ein Minimalbeispiel <rect x="0" y="0" width="100" height="100" /> erklärt und dann erst auf <svg width="200" height="200" viewBox="0 0 100 100"> eingegangen. Sollte man das auch in unserem Einstieg so erklären?

(Oops, die verwenden ja böse Begriffe wie Pixel - gleich mal Google Bescheid sagen, dass die denen die Unterstützung entziehen!)

Zur ViewBox gibt es den sehr guten Artikel von Sara Soueidan:

• Understanding SVG Coordinate Systems and Transformations (Part 1) — The viewport, viewBox, and preserveAspectRatio

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

Die von Dir postulierte „reine Form“ des SVG ohne HTML & CSS gibt es so nicht.

Hold by beer - wäre ich jetzt zu sagen versucht. Aber mein Bierkasten ist eh leer nach dem Wochenende…

Eine SVG Datei mit Styles und JavaScript darin kann schon eine ganze Menge anrichten. Ob das sinnvoll ist, ist natürlich eine andere Frage.

Ob es heutzutage noch ein Anwendungsfeld von SVG außerhalb eines Browsers gibt, auch.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

Die von Dir postulierte „reine Form“ des SVG ohne HTML & CSS gibt es so nicht.

Eine SVG Datei mit Styles und JavaScript darin kann schon eine ganze Menge anrichten. Ob das sinnvoll ist, ist natürlich eine andere Frage.

Ja, das wäre eher etwas für einen Blog-Artikel.

Viele Standalone SVGs von David Dailey oder auch @Thomas M ((datenverdrahten.de) aus den frühen 2000ern bauten z. B. Navigationen mit SVG-Grundformen und bildeten dann :hover-Effekte mit JavaScript nach.

Das ist ja mit ein Grund, warum CMSse (und MediaWiki) so zögerlich sind SVGs durch Nutzer hochladen zu lassen. Andererseits kann man diese Script-Elemente beim Hochladen einfach rauslöschen.

Andererseits sind viele der XML-Attribute heute eben zu Präsentationseigenschaften geworden und einige SVG-Sachen wie Masken und Beschneidungen sind jetzt als CSS-Modul zu finden.

Bei SVG2 haben die Browser-Hersteller nur die Sachen implementiert, die SVG HTML-ähnlicher machen und Spezialsachen wie hatch, die eben nur für Inkscape wichtig waren, einfach ignoriert.

Ob es heutzutage noch ein Anwendungsfeld von SVG außerhalb eines Browsers gibt, auch.

Herzliche Grüße

Matthias Scharwies

[ReiPar]

Hallo Rolf B und Matthias Scharwies,

ich weiß gar nicht so recht, auf was ich hier antworten soll. Wieder habe ich mit einer einzigen kleinen Frage eine Diskussion losgetreten, was ich gar nicht wollte. Danke für eure Antworten!

Die von Dir postulierte „reine Form“ des SVG ohne HTML & CSS gibt es so nicht.

So etwas wollte ich gar nicht postulieren. Aber ich halte es aus didaktischen Gründen für interessant und relevant, zunächst mal reines SVG zu lehren und dann – nach nur ganz kurzer Zeit –, CSS mit einzubinden. Denn ich halte eine Trennung von Inhalt und Darstellung für sehr hilfreich.

Das Einbinden in HTML ist für mich ein Thema, das didaktisch davon getrennt behandelt werden und vor allem nicht an erster Stelle stehen sollte. Auf der Seite SVG/Tutorials/Einstieg/Einbindung wird das auch recht gut gemacht. Ein entsprechendes Beispiel gibt es zwar schon recht bald (zu bald?) im SVG-Tutorial im SELFHTML-Wiki, aber es hilft, vermute ich, niemandem weiter, der noch kein oder nur sehr wenig HTML kann. Das Beispiel müsste aus meiner Sicht vollständig und regelkonform sein, allerdings ohne Codebestandteile, die kein neuerer Browser braucht: kleine, vollständige HTML-Seite ohne jeden Schnickschnack und vollständige SVG (mit einigen grafischen Elementen: z. B. Text, Rechteck und Pfad). Dabei ist aus meiner Sicht aber nur darauf näher einzugehen, was die SVG ohne HTML-Einbindung in HTML von einer SVG mit Einbindung unterscheidet. Alles andere sollte zwar im vollständigen Beispiel enthalten sein, wird aber expressis verbis an dieser Stelle nicht erläutert. Wie ich schon andeutete, meine ich, dass dieses Beispiel im Tutorial erst etwas später erscheinen sollte. Und so lange könnte man ohne Not mit Solo-SVG-Dateien arbeiten.

Vielleicht habe ich mich missverständlich ausgedrückt. Ich wollte nicht nach einem ganzen Tutorial über SVG ohne CSS und ohne Einbindung in HTML fragen. Deshalb verwendete ich die Formulierung »allerersten Einstieg« und habe den Wortbestandteil »aller« auch noch kursiv gesetzt. Allerdings habe ich in der zweiten Formulierung meiner Frage einen wichtigen Zusatz vergessen: »im SELFHTML-Wiki«. Trotzdem vielen Dank für das Heraussuchen und Verlinken externer Informationsquellen. Die können im weiteren Verlauf noch interessant werden.

Inzwischen habe ich herausgefunden, dass mein Browser Firefox einen entscheidenenden Unterschied braucht, um Solo-SVG-Dateien darzustellen. Im SVG-Tag muss notiert sein: xmlns="http://www.w3.org/2000/svg"

Meine Solo-SVG-Datei zum Ausprobieren beginnt mit folgender Zeile:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">

Lasse ich das hier fett Dargestellte weg, stellt mein Browser die SVG-Datei nicht dar. Mit <svg viewBox="0 0 100 100"> stellt der Browser nichts dar. Für mich war das der wichtige Unterschied. Denn warum soll ich eine HTML-Seite um die SVG herumbauen, wenn ich sie gar nicht brauche? Und wozu sollte jemand, der - aus welchen Gründen auch immer - zwar SVG erstellen, sie aber nicht in HTML-Seiten einbinden soll, minimales HTML lernen?

Ob dieser einzige Zusatz bereits eine regelkonforme SVG-Datei ausmacht, weiß ich nicht. Browser sind ja manchmal recht gnädig beim Darstellen von HTML, das nicht regelkonform ist. Aber der Browser muss in solchen Fällen Annahmen treffen. Die müssen nicht immer stimmen. So ist es vielleicht auch bei SVG. Zudem kann es sein, dass unterschiedliche Browser Unterschiedliches brauchen, um eine Solo-SVG-Datei darzustellen.

Soweit mal.

Viele Grüße

ReiPar

[Gunnar Bittersmann]

@@ReiPar

Dabei ist aus meiner Sicht aber nur darauf näher einzugehen, was die SVG ohne HTML-Einbindung in HTML von einer SVG mit Einbindung unterscheidet.

Man hätte es ja einfach haben können und es bei der Antwort „nichts“ belassen können.

Aber nein, die HTML5-Entwickler (oder sollte man sagen: der HTML5-Entwickler) hat sich halt gedacht: ‚XML hab ich noch nie verstanden/gemocht, also machen wir aus SVG-in-HTML mal was anderes als SVG: kein XML, sondern einfach nur Tagsuppe, so wie es HTML ja auch ist. Case-sensisitiv ist Teufelszeug! Namensräume sind Teufelszeug!‘ (Kurz darauf …)

Inzwischen habe ich herausgefunden, dass mein Browser Firefox einen entscheidenenden Unterschied braucht, um Solo-SVG-Dateien darzustellen. Im SVG-Tag muss notiert sein: xmlns="http://www.w3.org/2000/svg" […] Lasse ich das hier fett Dargestellte weg, stellt mein Browser die SVG-Datei nicht dar.

Ja, das kommt davon, wenn einfache Sachen kompliziert gemacht werden.

🖖 Живіть довго і процвітайте

[ThomasM]

Hallo ReiPar,

Ob dieser einzige Zusatz bereits eine regelkonforme SVG-Datei ausmacht, weiß ich nicht. Browser sind ja manchmal recht gnädig beim Darstellen von HTML, das nicht regelkonform ist. Aber der Browser muss in solchen Fällen Annahmen treffen. Die müssen nicht immer stimmen. So ist es vielleicht auch bei SVG. Zudem kann es sein, dass unterschiedliche Browser Unterschiedliches brauchen, um eine Solo-SVG-Datei darzustellen.

Standalone-SVG-Dateien sind für Browser an sich kein Problem. Das zeigt z. B. meine mittlerweile 20 Jahre alte Ur-Demo zum Thema. Darin kann man auch die bereits erwähnte viewBox in Aktion sehen: viewBox="0 0 950 630". Hintergrund war meine damalige Auflösung von 1024 x 768 mit Berücksichtigung von Browserfensterumgebung und Taskleiste vom OS. Passt sich durch 100% bei height und width entsprechend an.

Und ja, SVG-Dateien spielen auch heute noch eine Rolle, man kann diese ja auch via object oder iframe in HTML laden (auch mit img, aber dann verliert man den skriptbaren DOM-Kontext).

Den 20. Jahrestag der ersten Spezifikation 2001 habe ich im letzten Jahr gewürdigt und mit Videomaterial aus den Onlinesemestern untersetzt. Die Ur-Demo wird auch erläutert und ich habe diese gerade heute wieder in einem Präsenzkurs eingesetzt. 😉

Grüße,
Thomas

[Matthias Scharwies]

Hallo ReiPar,

Inzwischen habe ich herausgefunden, dass mein Browser Firefox einen entscheidenenden Unterschied braucht, um Solo-SVG-Dateien darzustellen. Im SVG-Tag muss notiert sein: xmlns="http://www.w3.org/2000/svg"

Meine Solo-SVG-Datei zum Ausprobieren beginnt mit folgender Zeile:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">

Ich habe mal den Abschnitt zu Standalone-Tags und das "Laterne, Sonne Mond und Sterne"-Tutorial von @Samuel fiedler zusammenkopiert:

• SVG/Tutorials/Standalone-SVGs

Dort findet sich im 3. Abschnitt etwas zur Namensraumangabe und zur Einbindung von XLink:

xmlns:xlink="http://www.w3.org/1999/xlink"

Das wird nötig, wenn Du innerhalb des SVG-Dokuments referenzieren willst; z.B. mit einem use-Element.

Lasse ich das hier fett Dargestellte weg, stellt mein Browser die SVG-Datei nicht dar. Mit <svg viewBox="0 0 100 100"> stellt der Browser nichts dar. Für mich war das der wichtige Unterschied. Denn warum soll ich eine HTML-Seite um die SVG herumbauen, wenn ich sie gar nicht brauche? Und wozu sollte jemand, der - aus welchen Gründen auch immer - zwar SVG erstellen, sie aber nicht in HTML-Seiten einbinden soll, minimales HTML lernen?

Ob dieser einzige Zusatz bereits eine regelkonforme SVG-Datei ausmacht, weiß ich nicht. Browser sind ja manchmal recht gnädig beim Darstellen von HTML, das nicht regelkonform ist. Aber der Browser muss in solchen Fällen Annahmen treffen. Die müssen nicht immer stimmen. So ist es vielleicht auch bei SVG.

Nein, wie oben bereits kurz erwähnt, zerschießt fehlerhaftes XML die Grafik. Deshalb ist es ganz gut, dass Du uns darauf gestoßen hast!

Soweit mal.

Könntest Du das durchlesen und dein Feedback geben?

Herzliche Grüße

Matthias Scharwies

[ReiPar]

Hallo @@Matthias Scharwies,

oben habe ich Rolf B geantwortet und auch ein Diff verlinkt. Wir beide, du und ich, haben etwa zeitgleich auf zwei unterschiedlichen Seiten parallel gearbeitet. In meinem obigen Beitrag erfährst du schon mal, was mir an deiner Änderung nicht gefällt und warum. Aber deine Änderung geht grundsätzlich m. E. in eine gute Richtung.

Wahrscheinlich ist es effizienter, erst hier im Forum unsere Gedanken auszudiskutieren als gleich im Wiki Änderungen vorzunehmen. Das betrifft auch meine heutige Arbeitsweise. 😉

Reicht dir das als Antwort erst mal?

Viele Grüße

ReiPar

[Matthias Scharwies]

Servus!

Hallo @@Matthias Scharwies,

Reicht dir das als Antwort erst mal?

😀 ja

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Herzlichen Glückwunsch zum Tag der richtigen Berufswahl!

Ich habe mal den Abschnitt zu Standalone-Tags und das "Laterne, Sonne Mond und Sterne"-Tutorial von @Samuel fiedler zusammenkopiert:

• SVG/Tutorials/Standalone-SVGs

Ich habe in den letzten Wochen gehirnt und immer wieder an Formulierungen gearbeitet:

1. Namensraumangabe

Dort findet sich im 3. Abschnitt etwas zur Namensraumangabe und zur Einbindung von XLink:

xmlns:xlink="http://www.w3.org/1999/xlink"

Das wird nötig, wenn Du innerhalb des SVG-Dokuments referenzieren willst; z.B. mit einem use-Element.

Grundgerüst mit Namensraumangabe knackiger formuliert.

2. Laterne, Sonne, Mond und Sterne ^[1]

ist jetzt mit „Screenshots“ visualisiert. Dabei habe ich die Laterne zu einer Kerze verändert. Das ganze Tutorial ist kontextualisiert, d.h. unser Weihnachtsbaum zieht sich durch's ganze Tutorial.

Es gibt eine Mischung aus kurzen Code-Snippets (ohne Beispiel-Vorlage!) und den SVGs rechts. Mit Klick auf das SVG und dann auf Original-Datei kann man das Markup untersuchen oder kopieren. Umständlich? - Dazu später mehr!

3. Viewport und Viewbox

Hier gibt's wieder ein SVG mit Blick durch's Schlüsselloch und eine Infografik, die Viewport und viewBox erklärt und dann eine viewBox-Animation.

In diesem SVG ist bei der png-Vorschau der Text verschoben.

Sowohl bei der viewBox-Animation und der CSS-Animation ist die png-Vorschau eben nicht animiert. (Die CSS-Animation bleibt ganz schwarz! 😟 ) Deshalb habe ich die Original-Datei direkt in der Bildbeschreibung verlinkt.

@Der Martin @Camping_RIDER Wir müssen unbedingt das Wiki-Makeover durchziehen und die NativeSVGHandler-Extension installieren.

4. Animation mit JavaScript

ist noch ne Baustelle

5. Programme

Zum Schluss habe ich die ehemals schlecht verlinkte Seite "SVG/Grafiken erstellen" hier integriert und die externen Links überprüft.

@Samuel fiedler Könntest Du das mal durchlesen und dein Feedback geben? @all Was meint ihr?

Herzliche Grüße

Matthias Scharwies

---

1. Sollte man den Kapitelnamen anpassen? Wenn ja, wie? ↩︎