Frage zum Wiki-Artikel „SVG_in_responsiven_Webseiten“

[Robert B.]

Hallo Forum und Wiki,

auf der verlinkten Wiki-Seite wird das viewBox-Attribut mehrfach als viewbox geschrieben. SVG ist doch case-sensitive oder habe ich etwas verpasst?

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

auf der verlinkten Wiki-Seite wird das viewBox-Attribut mehrfach als viewbox geschrieben. SVG ist doch case-sensitive oder habe ich etwas verpasst?

Nein, du hast recht.

Dass die Beispiele trotzdem funktionieren, liegt daran, dass SVG-in-HTML nicht case-sensitiv ist (weil kein XML, sondern tag soup).

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

[Robert B.]

Hallo Gunnar,

dann werde ich mal den @Matthias Scharwies bitten die Beispiele zu korrigieren.

Vielen Dank und viele Grüße
Robert

[JürgenB]

Hallo,

ich hab das mal korrigiert, und hoffentlich nchts übersehen.

Gruß
Jürgen

[Robert B.]

Hallo Jürgen,

vielen Dank dafür!

Viele Grüße
Robert

[Raketenwilli]

Abgesehen vom persönlichen Empfinden ist es nicht falsch, im Begleittext „viewbox“ zu notieren, denn das ist menschliche Sprache, zudem englisch. Und Nachfahren von angelnden Sachsen, Normannen und Briten schreiben Substantive klein.

Falsch wäre es allenfalls innerhalb von Skripten/SVG (und in diesen außerhalb von Kommentaren) selbst.

[Robert B.]

Moin,

es steht so im Quellcode einiger Beispiele.

Viele Grüße
Robert

[Raketenwilli]

es steht so im Quellcode einiger Beispiele.

Dann gilt mein Satz 2 …

Falsch wäre es allenfalls innerhalb von Skripten/SVG (und in diesen außerhalb von Kommentaren) selbst.

… für das Wiki auch dann, wenn die Beispiele (wie von Gunnar ausgeführt) funktionieren, weil deren SVG in HTML eingebettet ist.

Für mich persönlich ist sowas (wunderhaft wechselnde case-sensitivity) ein Horror: Kopiert man das Zeug raus und verwendet es als „stand-alone-SVG“, geht es plötzlich nicht mehr.

(Und da behaupten manche, dieses oder jenes sei ein „Hirnfurz“ des Erfinders von PHP …)

[Rolf B]

Hallo Raketenwilli,

PHP und SVG sind ja sowas von orthogonal zueinander... da kann man Lerdorf vieles vorwerfen, aber dass er SVG verunstaltet habe, eher nicht 😉

Die Frage wäre auch, wo genau es stinkt. Bei der case-sensitivity von XML (wovon SVG ein Dialekt ist) oder bei der case-insensitivity von HTML?

Einen Sonderdialekt iSVG (case insensitive SVG) zur Verwendung in HTML Seiten mag ich jetzt auch nicht anregen. Aber vielleicht wäre das sinnvoll. Oder auch nicht, Apple würde wegen des i-Präfixes eine Markenrechtsverletzung einklagen…

Rolf

[Der Martin]

Hallo,

Die Frage wäre auch, wo genau es stinkt. Bei der case-sensitivity von XML (wovon SVG ein Dialekt ist) oder bei der case-insensitivity von HTML?

oder bei der Spezifikation von SVG? Denn in den XML-Derivaten, die ich kenne, gilt die konsequente Kleinschreibung - und in HTML und CSS ist sie zumindest auch empfohlen.

Einen Sonderdialekt iSVG (case insensitive SVG) zur Verwendung in HTML Seiten mag ich jetzt auch nicht anregen. Aber vielleicht wäre das sinnvoll. Oder auch nicht, Apple würde wegen des i-Präfixes eine Markenrechtsverletzung einklagen…

Genau, sobald ein iDiot in Cupertino das mitkriegt. 😉

Einen schönen Tag noch
 Martin

[ThomasM]

Hallo Martin,

Die Frage wäre auch, wo genau es stinkt. Bei der case-sensitivity von XML (wovon SVG ein Dialekt ist) oder bei der case-insensitivity von HTML?

oder bei der Spezifikation von SVG? Denn in den XML-Derivaten, die ich kenne, gilt die konsequente Kleinschreibung - und in HTML und CSS ist sie zumindest auch empfohlen.

XML ist halt so spezifiziert und es gibt viele unterschiedliche Ausprägungen mit kleiner, großer und gemischter Schreibweise. Letztere ist bereits im Modellierungsstandard XML Schema angelegt (etwa xs:simpleType und xs:complexType).

Das XML-Periodensystem von data2type zeigt die existierende Vielfalt und wer Spaß am XPathle hat, wird dort auch fündig. 😉

Bei SVG sollte man auch im HTML-Bereich konsequent auf die Schreibweise achten. Grafikinhalte könnten mal Bestandteil von E-Books werden und dort ist XHTML 1.1 (EPUB 2) bzw. XHTML5 (EPUB 3) angesagt.

Grüße,
Thomas

[Matthias Scharwies]

Servus!

Die Frage wäre auch, wo genau es stinkt. Bei der case-sensitivity von XML (wovon SVG ein Dialekt ist) oder bei der case-insensitivity von HTML?

oder bei der Spezifikation von SVG? Denn in den XML-Derivaten, die ich kenne, gilt die konsequente Kleinschreibung - und in HTML und CSS ist sie zumindest auch empfohlen.

XML ist halt so spezifiziert [...]

Bei SVG sollte man auch im HTML-Bereich konsequent auf die Schreibweise achten. Grafikinhalte könnten mal Bestandteil von E-Books werden und dort ist XHTML 1.1 (EPUB 2) bzw. XHTML5 (EPUB 3) angesagt.

Ich habe jetzt das Wochenende über gehirnt:

Ja, es ist besser, wenn wir SVG XML-Konform schreiben, das aber auch erklären. (Das angesprochene Tutorial ist eben das fünfte der Einstiegskapitel und die Erklärung muss schon vorher erfolgen.)

---

Meine Formulierung:

{{Beachten| Inline-SVG innerhalb von HTML-Dokumenten ist case-insensitive, das bedeutet, dass die Groß- und Kleinschreibung keine Rolle spielt. In Standalone-SVGs gelten die Regeln von XML.

So wird das viewbox-Attribut in einem SVG-Dokument ignoriert, da es das viewBox-Attribut in CamelCase-Schreibweise erwartet.

SELFHTML verwendet die XML-Schreibweise, damit Markup bequem kopiert werden kann. }}

---

Was haltet ihr davon?

Dieser Text soll als Vorlage z.B. diesen Hinweis (ganz unten) ersetzen. Den (vor)-letzen Satz könnte man evtl. als Parameter übergeben - ich dachte an eine Formulierung nur mit dem Attributsnamen, aber da könnte es bei gleichlautenden Namen wie TabIndex/Tabindex zu Problemen kommen.

In der Erklärung zu CamelCase folgt:

Im Wiki gibt es oft Beispiele von inline-SVG in HTML5-Dokumenten. Hier sind alle SVG-Attribute klein geschrieben. Wenn Sie diese Codebeispiele aber in SVG-Dokumenten verwenden, müssen diese Attribute XML-konform geschrieben werden.

Das muss dann natürlich raus.

---

Ich bin die SVG-Beispiele mal durchgegangen (@Robert B. - das hättest du auch tun können, du bist Beispiele-Moderator!) und hab generell alles durchgeschaut, was sich seit März 2015 angesammelt hat:

• HTML(5)

  • Link-Tag ohne End-Slash (durch das Frickl ist das Beispiel-Layout eh in den Hintergrund getreten)
  • main entfernt - war halt nur ein zusätzliches Element, wird im Frickl eh nicht gebraucht

• CSS

  • nur einmal im HTML oder im SVG, sonst wird es im Frickl überschrieben
  • stroke-width ohne px
  • 1x font-size in pt auf px
  • -webkit- bei animation entfernt (an die Jüngeren - das brauchte man damals!)

• SVG

  • viewBox anstelle viewbox, tabIndex, wobei das Durchtabben halt nur in Inline-SVG oder mit einer Einbindung in object, nicht jedoch in img geht. Der Rest war schon CamelCase
  • keine Namensraumangabe in Inline-SVG
  • Xlink:href ersetzt, das ist echt eine Vereinfachung, Allerdings werden so keine png-Vorschauen im Mediawiki erzeugt.

• sonstiges

  • 1x Blog-URL korrigiert
  • 2x Typos, davon eine sogar in der h1
  • Anpassung an neue Farbtabelle

Herzliche Grüße

Matthias Scharwies

[ThomasM]

Hallo Matthias,

ich würde nicht mögliche Ausnahmen oder Alternativen in den Vordergrund rücken, sondern vorab erklären:

Zu HTML5 gehörende Elemente und Attribute sowie CSS-Eigenschaften werden konsequent klein geschrieben, während sich die Schreibweise der adoptierten Standards MathML und SVG an deren Spezifikationen orientiert.

Grüße,
Thomas

[Matthias Scharwies]

Servus!

Hallo Matthias,

ich würde nicht mögliche Ausnahmen oder Alternativen in den Vordergrund rücken, sondern vorab erklären:

Zu HTML5 gehörende Elemente und Attribute sowie CSS-Eigenschaften werden konsequent klein geschrieben, während sich die Schreibweise der adoptierten Standards MathML und SVG an deren Spezifikationen orientiert.

@all

Das würde ich gerne morgen am Mittwochs-Stammtisch (Ich weiß: Zwischentermin) gerne zusammen formulieren.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Der Martin

Denn in den XML-Derivaten, die ich kenne, gilt die konsequente Kleinschreibung

Du kennst SVG nicht. Da gibt es einige Elementbezeichner (bspw. feGaussianBlur), Attributbezeichner (bspw. eben viewBox) und Schlüsselwörter (bspw. currentColor) in CamelCase.

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

[MudGuard]

Hi,

Aber vielleicht wäre das sinnvoll. Oder auch nicht, Apple würde wegen des i-Präfixes eine Markenrechtsverletzung einklagen…

Vielleicht hilft es ja, das i magenta-farbig zu machen 😉

cu,
Andreas a/k/a MudGuard

[Raketenwilli]

Hi,

Aber vielleicht wäre das sinnvoll. Oder auch nicht, Apple würde wegen des i-Präfixes eine Markenrechtsverletzung einklagen…

Vielleicht hilft es ja, das i magenta-farbig zu machen 😉

Das ist weniger witzig als mancher denkt. Man könnte als Verklagter nämlich sodann die „Aktivlegitimation“ bestreiten, weil ja die Rechte eines anderen als der Klägerin verletzt sind - und ich halte es erfahrungsgemäß für möglich und wahrscheinlich, dass (teutogermanische) Richter auf solchen Unfug hineinfallen. Immerhin haben die dann den Prozess vom Tisch und wegen der kurzen Begründung (Unzulässigkeit der Klage) viel Arbeit gespart.