<h2>Neuerungen und Änderungen</h2> <p>Eine große Vereinfachung bildet der Wegfall der DTDs und Namensraum-Angaben. In HTML5 eingebundene SVG-Fragmente werden ohne weitere Angaben erkannt und fehlerfrei ausgeführt.</p> <p>Bisher wurde in SVG mit dem XML-Dialekt XLink <a href="https://wiki.selfhtml.org/wiki/SVG/Element/a#Referenzieren_in_SVG">referenziert</a>. SVG 2 sieht auch hier eine Vereinfachung durch die Übernahme des <code>href</code>-Attributs aus der HTML-Welt. In den meisten Browsern funktioniert dies bereits; wenn Firefox im Januar 2017 nachzieht, fehlt nur noch Safari.</p> <p>Präsentationsattribute konnten schon immer auch im CSS festgelegt werden. Neu in SVG 2 ist, dass zu diesen Präsentationsattributen auch alle Koordinaten wie <code>width, height</code> oder <code>x, y</code> und <code>r</code> gehören und so im Stylesheet festgelegt, aber auch z.B. bei <code>:hover</code> verändert werden können.</p> <p>So einfach die Einbindung von SVG in HTML ist, so umständlich ist die Integration von HTML-Code in SVG. Zwar gibt es mit dem <code><a href="https://wiki.selfhtml.org/wiki/ForeignObject">foreignObject</a></code>-Element ein Werkzeug dafür, dies wird jedoch von älteren Versionen des Internet Explorer nicht unterstützt. In SVG 1.0 kann mehrzeiliger Text nur mit mehreren <code>tspan</code>-Elementen realisiert werden. SVG 2 schafft hier Abhilfe, da man dem <code>text</code>-Element nun eine feste Breite und Höhe geben kann, um längere Texte unzubrechen.</p> <p>Neu hinzukommen sollen netzartige Verlaufsgitter (<a href="http://wiki.selfhtml.org/wiki/SVG/Element/mesh"><code>mesh</code></a>) und Schraffuren (<a href="http://wiki.selfhtml.org/wiki/SVG/Element/hatch"><code>hatch</code></a>).</p> <p>Aus dem Standard entfernt wurden neben wenig sinnvollen Attributen wie <code>enable-background</code> und <code>externalResourcesRequired</code> auch der gesamte <code>font</code>- und <code>glyph</code>-Bereich, der von Anfang an unter der schlechten Browserunterstützung litt. 2001 war die Einbindung fremder Schriften mit der CSS-Eigenschaft <code>font-face</code> so noch nicht absehbar; mittlerweile hat sich dies auch in der SVG-Welt durchgesetzt.</p> <p>Trotz dieser eigentlich machbar erscheinenden Aufgabenbeschreibung verzögert sich die neue Version. Dies ist nur verständlich, wenn man sich die Hintergründe der Arbeit an der Spezifikation ansieht.</p> <h2>Interessenkonflikte</h2> <p>Für die tägliche Arbeit der Webdesigner waren die Browserkriege der Vergangenheit Gift, tatsächlich ermöglichte aber das Vorpreschen einzelner Hersteller die Implementation vieler heute aus dem Alltag nicht mehr wegzudenkender Features wie <code>canvas</code>, <code>audio</code> und <code>video</code>. Das W3C standardisierte viele dieser proprietären Lösungen in den HTML5-Standard, die dann von den anderen Browserherstellern übernommen wurden.</p> <p>Bei SVG ist die Lage viel komplexer. Während SVG im Web ein Schattendasein führte, wurde es Grundlage für Software wie Inkscape, Adobe Illustrator, Sketch und andere, die den Standard um eigene Funktionen erweiterten. In der SVG Working Group gibt es 15 Editoren aus den unterschiedlichsten Bereichen.<a id="a1" href="#f1">^[1]</a><br> So nehmen neben den blink-Browserherstellern Chrome und Opera sowie Mozilla mit Firefox auch Firmen wie Kodak, Canon, KDDI und Adobe teil. Dagegen hält sich Microsoft bis zum Abschluss der Empfehlung mit Vorschlägen und Implementationen zurück. Auch Safari hat eher die Rolle des Beobachters eingenommen.</p> <p>Beispielsweise wäre beim Zeichnen der Konturen von Objekten eine Positionierung mit einer <a href="https://wiki.selfhtml.org/wiki/SVG/Farben/Kontur#stroke-align">stroke-alignment</a>-Eigenschaft sehr wünschenswert. Sie ist auch in Illustrator und Sketch bereits implementiert. Beim Versuch vorhandene Features in einer Spezifikation festzulegen, kam es jedoch zu so vielen vorher nicht absehbaren Grenzfällen, dass diese Eigenschaft in ein späteres CSS3-Modul <em>stroking</em> verschoben wurde.<a id="a2" href="#f2">^[2]</a></p> <p>Diese Schwierigkeiten bei relativ einfach anmutenden Problemen scheint einer der Gründe zu sein, warum die Bereitschaft zur Mitarbeit in der <em>working group</em> immer geringer wurde. Nachdem an den regelmäßigen Telefonkonferenzen nur noch vier bis fünf Personen teilnahmen, löste der W3C die <em>working group</em> im Oktober 2016 auf. Bei einer Krisensitzung wurde eine letzte Frist bis Januar 2017 gewährt, wobei der weitere Fahrplan im Ungewissen liegt.<a id="a3" href="#f3">^[3]</a> <a id="a4" href="#f4">^[4]</a></p> <h2>eine abgespeckte Spec?</h2> <p>Mittlerweile scheint als Minimalziel nur die Verabschiedung einer abgespeckten Version erwogen zu werden. Konische Verläufe und netzartige Verlaufsgitter (<code>mesh</code>) sowie Schraffuren (<code>hatch</code>) sind "<em>at risk!</em>" und sollen vorerst im <a href="https://wicg.io/"> Web Incubator</a> zurückgestellt werden. Als Brutkasten für neue Ideen geplant, vermuten einige darin aber doch eher einen Sterbeplatz für Ideen ohne Lebenskraft.</p> <p>Es ist in der Diskussion, alle Spezifikationen, die sowohl CSS als auch SVG betreffen, wie z.B. <a href="https://drafts.csswg.org/css-transforms/">Transforms</a>, <a href="https://drafts.fxtf.org/filters/">Filters</a>, <a href="https://drafts.fxtf.org/css-masking-1/">Masking and Clipping</a>, <a href="https://drafts.fxtf.org/compositing-1/">Compositing and Blending</a> in CSS-Modulen zu spezifizieren. Unter dem Aspekt der <em>Separation of Concerns </em>würde dies sinnvoll sein, für SVG an sich würde es jedoch einen Aderlass bedeuten, der von Vertretern der Software-Industrie wie Tavmjong Bah kritisch gesehen wird.</p> <h2>Fazit</h2> <p>Während sich die erste Version von SVG gegenüber proprietären Lösungen wie VML als richtungsweisend erwies, litt sie doch jahrelang unter der mangelnden Browserunterstützung. Im Gegensatz dazu wirkt gerade die heute mittlerweile gute Unterstützung als Hemmschuh bei der Verabschiedung neuer Eigenschaften, die erst bei einer wahrscheinlichen Implementierung in die Spezifikationen aufgenommen werden - ein Teufelskreis, der die Weiterentwicklung ausbremst.</p> <h2>Quellen</h2> <ol> <li>W3C: <a id="f1" href="https://www.w3.org/TR/2016/CR-SVG2-20160915/">Scalable Vector Graphics (SVG) 2</a> W3C Candidate Recommendation vom 15.09.2016<a href="#a1">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f2" href="http://tavmjong.free.fr/blog/?p=1257">Paths: Stroking and Offsetting: It's not as eays as it looks.</a> vom 13.04.2015<a href="#a2">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f3" href="http://tavmjong.free.fr/svg2_status.html">SVG Status: "SVG 2 is on life support"</a>4th November, 2016 <a href="#a3">↩</a></li> <li>CSS-tricks.com: <a id="f4" href="https://css-tricks.com/svg-2-conundrum/">The SVG 2 Conundrum</a> vom 11.11.2016<a href="#a4">↩</a></li> </ol> <h2>SVG-Serie</h2> <ul> <li>Teil 1: <a href="https://blog.selfhtml.org/2016/11/23/svg-ein-format-fuer-alle-faelle/">SVG – ein Format für alle Fälle</a></li> <li>Teil 2: <a href="https://blog.selfhtml.org/2016/11/25/svg 2">SVG 2: Was lange währt</a> <li>Teil 3: <a href="https://blog.selfhtml.org/2017/04/15/svg-animationen-zum-leben-erwecken/">Animationen: SVG zum Leben erwecken</a></li> <li>Teil 4: ein Bild sagt mehr als 1000 Worte: Infografiken mit SVG</li> <li>Teil 5: Datenvisualisierung mit SVG <em>(geplant für Juli 2023)</em></li> </ul>

<h2>Neuerungen und Änderungen</h2> <p>Eine große Vereinfachung bildet der Wegfall der DTDs und Namensraum-Angaben. In HTML5 eingebundene SVG-Fragmente werden ohne weitere Angaben erkannt und fehlerfrei ausgeführt.</p> <p>Bisher wurde in SVG mit dem XML-Dialekt XLink <a href="https://wiki.selfhtml.org/wiki/SVG/Element/a#Referenzieren_in_SVG">referenziert</a>. SVG 2 sieht auch hier eine Vereinfachung durch die Übernahme des <code>href</code>-Attributs aus der HTML-Welt. In den meisten Browsern funktioniert dies bereits; wenn Firefox im Januar 2017 nachzieht, fehlt nur noch Safari.</p> <p>Präsentationsattribute konnten schon immer auch im CSS festgelegt werden. Neu in SVG 2 ist, dass zu diesen Präsentationsattributen auch alle Koordinaten wie <code>width, height</code> oder <code>x, y</code> und <code>r</code> gehören und so im Stylesheet festgelegt, aber auch z.B. bei <code>:hover</code> verändert werden können.</p> <p>So einfach die Einbindung von SVG in HTML ist, so umständlich ist die Integration von HTML-Code in SVG. Zwar gibt es mit dem <code><a href="https://wiki.selfhtml.org/wiki/ForeignObject">foreignObject</a></code>-Element ein Werkzeug dafür, dies wird jedoch von älteren Versionen des Internet Explorer nicht unterstützt. In SVG 1.0 kann mehrzeiliger Text nur mit mehreren <code>tspan</code>-Elementen realisiert werden. SVG 2 schafft hier Abhilfe, da man dem <code>text</code>-Element nun eine feste Breite und Höhe geben kann, um längere Texte unzubrechen.</p> <p>Neu hinzukommen sollen netzartige Verlaufsgitter (<a href="http://wiki.selfhtml.org/wiki/SVG/Farben/Verlaufsgitter"><code>mesh</code></a>) und Schraffuren (<a href="http://wiki.selfhtml.org/wiki/SVG/Farben/Schraffuren"><code>hatch</code></a>).</p> <p>Aus dem Standard entfernt wurden neben wenig sinnvollen Attributen wie <code>enable-background</code> und <code>externalResourcesRequired</code> auch der gesamte <code>font</code>- und <code>glyph</code>-Bereich, der von Anfang an unter der schlechten Browserunterstützung litt. 2001 war die Einbindung fremder Schriften mit der CSS-Eigenschaft <code>font-face</code> so noch nicht absehbar; mittlerweile hat sich dies auch in der SVG-Welt durchgesetzt.</p> <p>Trotz dieser eigentlich machbar erscheinenden Aufgabenbeschreibung verzögert sich die neue Version. Dies ist nur verständlich, wenn man sich die Hintergründe der Arbeit an der Spezifikation ansieht.</p> <h2>Interessenkonflikte</h2> <p>Für die tägliche Arbeit der Webdesigner waren die Browserkriege der Vergangenheit Gift, tatsächlich ermöglichte aber das Vorpreschen einzelner Hersteller die Implementation vieler heute aus dem Alltag nicht mehr wegzudenkender Features wie <code>canvas</code>, <code>audio</code> und <code>video</code>. Das W3C standardisierte viele dieser proprietären Lösungen in den HTML5-Standard, die dann von den anderen Browserherstellern übernommen wurden.</p> <p>Bei SVG ist die Lage viel komplexer. Während SVG im Web ein Schattendasein führte, wurde es Grundlage für Software wie Inkscape, Adobe Illustrator, Sketch und andere, die den Standard um eigene Funktionen erweiterten. In der SVG Working Group gibt es 15 Editoren aus den unterschiedlichsten Bereichen.<a id="a1" href="#f1">^[1]</a><br> So nehmen neben den blink-Browserherstellern Chrome und Opera sowie Mozilla mit Firefox auch Firmen wie Kodak, Canon, KDDI und Adobe teil. Dagegen hält sich Microsoft bis zum Abschluss der Empfehlung mit Vorschlägen und Implementationen zurück. Auch Safari hat eher die Rolle des Beobachters eingenommen.</p> <p>Beispielsweise wäre beim Zeichnen der Konturen von Objekten eine Positionierung mit einer [stroke-alignment](https://wiki.selfhtml.org/wiki/SVG/Farben/Kontur#stroke-align)-Eigenschaft sehr wünschenswert. Sie ist auch in Illustrator und Sketch bereits implementiert. Beim Versuch vorhandene Features in einer Spezifikation festzulegen, kam es jedoch zu so vielen vorher nicht absehbaren Grenzfällen, dass diese Eigenschaft in ein späteres CSS3-Modul <em>stroking</em> verschoben wurde.<a id="a2" href="#f2">^[2]</a></p> <p>Diese Schwierigkeiten bei relativ einfach anmutenden Problemen scheint einer der Gründe zu sein, warum die Bereitschaft zur Mitarbeit in der <em>working group</em> immer geringer wurde. Nachdem an den regelmäßigen Telefonkonferenzen nur noch vier bis fünf Personen teilnahmen, löste der W3C die <em>working group</em> im Oktober 2016 auf. Bei einer Krisensitzung wurde eine letzte Frist bis Januar 2017 gewährt, wobei der weitere Fahrplan im Ungewissen liegt.<a id="a3" href="#f3">^[3]</a> <a id="a4" href="#f4">^[4]</a></p> <h2>eine abgespeckte Spec?</h2> <p>Mittlerweile scheint als Minimalziel nur die Verabschiedung einer abgespeckten Version erwogen zu werden. Konische Verläufe und netzartige Verlaufsgitter (<code>mesh</code>) sowie Schraffuren (<code>hatch</code>) sind "<em>at risk!</em>" und sollen vorerst im <a href="https://wicg.io/"> Web Incubator</a> zurückgestellt werden. Als Brutkasten für neue Ideen geplant, vermuten einige darin aber doch eher einen Sterbeplatz für Ideen ohne Lebenskraft.</p> <p>Es ist in der Diskussion, alle Spezifikationen, die sowohl CSS als auch SVG betreffen, wie z.B. <a href="https://drafts.csswg.org/css-transforms/">Transforms</a>, <a href="https://drafts.fxtf.org/filters/">Filters</a>, <a href="https://drafts.fxtf.org/css-masking-1/">Masking and Clipping</a>, <a href="https://drafts.fxtf.org/compositing-1/">Compositing and Blending</a> in CSS-Modulen zu spezifizieren. Unter dem Aspekt der <em>Separation of Concerns </em>würde dies sinnvoll sein, für SVG an sich würde es jedoch einen Aderlass bedeuten, der von Vertretern der Software-Industrie wie Tavmjong Bah kritisch gesehen wird.</p> <h2>Fazit</h2> <p>Während sich die erste Version von SVG gegenüber proprietären Lösungen wie VML als richtungsweisend erwies, litt sie doch jahrelang unter der mangelnden Browserunterstützung. Im Gegensatz dazu wirkt gerade die heute mittlerweile gute Unterstützung als Hemmschuh bei der Verabschiedung neuer Eigenschaften, die erst bei einer wahrscheinlichen Implementierung in die Spezifikationen aufgenommen werden - ein Teufelskreis, der die Weiterentwicklung ausbremst.</p> <h2>Quellen</h2> <ol> <li>W3C: <a id="f1" href="https://www.w3.org/TR/2016/CR-SVG2-20160915/">Scalable Vector Graphics (SVG) 2</a> W3C Candidate Recommendation vom 15.09.2016<a href="#a1">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f2" href="http://tavmjong.free.fr/blog/?p=1257">Paths: Stroking and Offsetting: It's not as eays as it looks.</a> vom 13.04.2015<a href="#a2">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f3" href="http://tavmjong.free.fr/svg2_status.html">SVG Status: "SVG 2 is on life support"</a> <a href="#a3">↩</a></li> <li>CSS-tricks.com: <a id="f4" href="https://css-tricks.com/svg-2-conundrum/">The SVG 2 Conundrum</a> vom 11.11.2016<a href="#a4">↩</a></li> </ol> <h2>SVG-Serie</h2> <ul> <li>Teil 1: <a href="https://blog.selfhtml.org/2016/11/23/svg-ein-format-fuer-alle-faelle/">SVG – ein Format für alle Fälle</a></li> <li>Teil 2: <a href="https://blog.selfhtml.org/2016/11/25/svg 2">SVG 2: Was lange währt</a> <li>Teil 3: <a href="https://blog.selfhtml.org/2017/04/15/svg-animationen-zum-leben-erwecken/">Animationen: SVG zum Leben erwecken</a></li> <li>Teil 4: <a href="https://forum.selfhtml.org/weblog/2017/apr/15/svg-animationen-zum-leben-erwecken/1782834#m1782834">SVG - Grafiken mit Animationen zum Leben erwecken</a></li> <li>Teil 5: Datenvisualisierung mit SVG <em>(geplant für Juli 2023)</em></li> </ul>

<p>Im <a href="https://blog.selfhtml.org/2016/11/23/svg-ein-format-fuer-alle-faelle/">ersten Teil</a> unserer Miniserie wurde schon kurz erwähnt, dass SVG seit 15 Jahren vom W3C standardisiert ist. Seit dem Versuch SVG 1.1 und SVG Tiny aus dem Jahre 2003 zu einer Version 1.2 zu verschmelzen, hat es keine Überarbeitung der Spezifikation gegeben.</p> <p>SVG-Enthusiasten wünschten sich die Aufnahme neuer Grundformen wie z.B. einem star-Element, Eigenschaften wie variabler Randstärken und Grafikeffekten wie konischen Verläufen oder Netzstrukturen. Im Kernpunkt der neuen Spezifikation soll aber nicht die Erweiterung durch eine Vielzahl neuer Features, sondern die bessere Integration von SVG in HTML, CSS und DOM und die Entfernung nicht unterstützer Eigenschaften stehen.</p> <p><!--more--></p> <h2>Neuerungen und Änderungen</h2> <p>Eine große Vereinfachung bildet der Wegfall der DTDs und Namensraum-Angaben. In HTML5 eingebundene SVG-Fragmente werden ohne weitere Angaben erkannt und fehlerfrei ausgeführt.</p> <p>Bisher wurde in SVG mit dem XML-Dialekt XLink <a href="http://wiki.selfhtml.org/wiki/SVG/Elemente/Verweise#Referenzieren_in_SVG">referenziert</a>. SVG 2 sieht auch hier eine Vereinfachung durch die Übernahme des <code>href</code>-Attributs aus der HTML-Welt. In den meisten Browsern funktioniert dies bereits; wenn Firefox im Januar 2017 nachzieht, fehlt nur noch Safari.</p> <p>Präsentationsattribute konnten schon immer auch im CSS festgelegt werden. Neu in SVG 2 ist, dass zu diesen Präsentationsattributen auch alle Koordinaten wie <code>width, height</code> oder <code>x, y</code> und <code>r</code> gehören und so im Stylesheet festgelegt, aber auch z.B. bei <code>:hover</code> verändert werden können.</p> <p>So einfach die Einbindung von SVG in HTML ist, so umständlich ist die Integration von HTML-Code in SVG. Zwar gibt es mit dem <code><a href="https://wiki.selfhtml.org/wiki/ForeignObject">foreignObject</a></code>-Element ein Werkzeug dafür, dies wird jedoch von älteren Versionen des Internet Explorer nicht unterstützt. In SVG 1.0 kann mehrzeiliger Text nur mit mehreren <code>tspan</code>-Elementen realisiert werden. SVG 2 schafft hier Abhilfe, da man dem <code>text</code>-Element nun eine feste Breite und Höhe geben kann, um längere Texte unzubrechen.</p> <p>Neu hinzukommen sollen netzartige Verlaufsgitter (<a href="http://wiki.selfhtml.org/wiki/SVG/Farben/Verlaufsgitter"><code>mesh</code></a>) und Schraffuren (<a href="http://wiki.selfhtml.org/wiki/SVG/Farben/Schraffuren"><code>hatch</code></a>).</p> <p>Aus dem Standard entfernt wurden neben wenig sinnvollen Attributen wie <code>enable-background</code> und <code>externalResourcesRequired</code> auch der gesamte <code>font</code>- und <code>glyph</code>-Bereich, der von Anfang an unter der schlechten Browserunterstützung litt. 2001 war die Einbindung fremder Schriften mit der CSS-Eigenschaft <code>font-face</code> so noch nicht absehbar; mittlerweile hat sich dies auch in der SVG-Welt durchgesetzt.</p> <p>Trotz dieser eigentlich machbar erscheinenden Aufgabenbeschreibung verzögert sich die neue Version. Dies ist nur verständlich, wenn man sich die Hintergründe der Arbeit an der Spezifikation ansieht.</p> <h2>Interessenkonflikte</h2> <p>Für die tägliche Arbeit der Webdesigner waren die Browserkriege der Vergangenheit Gift, tatsächlich ermöglichte aber das Vorpreschen einzelner Hersteller die Implementation vieler heute aus dem Alltag nicht mehr wegzudenkender Features wie <code>canvas</code>, <code>audio</code> und <code>video</code>. Das W3C standardisierte viele dieser proprietären Lösungen in den HTML5-Standard, die dann von den anderen Browserherstellern übernommen wurden.</p> <p>Bei SVG ist die Lage viel komplexer. Während SVG im Web ein Schattendasein führte, wurde es Grundlage für Software wie Inkscape, Adobe Illustrator, Sketch und andere, die den Standard um eigene Funktionen erweiterten. In der SVG Working Group gibt es 15 Editoren aus den unterschiedlichsten Bereichen.<a id="a1" href="#f1">^[1]</a><br> So nehmen neben den blink-Browserherstellern Chrome und Opera sowie Mozilla mit Firefox auch Firmen wie Kodak, Canon, KDDI und Adobe teil. Dagegen hält sich Microsoft bis zum Abschluss der Empfehlung mit Vorschlägen und Implementationen zurück. Auch Safari hat eher die Rolle des Beobachters eingenommen.</p> <p>Beispielsweise wäre beim Zeichnen der Konturen von Objekten eine Positionierung mit einer <code>stroke-alignment</code>-Eigenschaft sehr wünschenswert. Sie ist auch in Illustrator und Sketch bereits implementiert. Beim Versuch vorhandene Features in einer Spezifikation festzulegen, kam es jedoch zu so vielen vorher nicht absehbaren Grenzfällen, dass diese Eigenschaft in ein späteres CSS3-Modul <em>stroking</em> verschoben wurde.<a id="a2" href="#f2">^[2]</a></p> <p>Diese Schwierigkeiten bei relativ einfach anmutenden Problemen scheint einer der Gründe zu sein, warum die Bereitschaft zur Mitarbeit in der <em>working group</em> immer geringer wurde. Nachdem an den regelmäßigen Telefonkonferenzen nur noch vier bis fünf Personen teilnahmen, löste der W3C die <em>working group</em> im Oktober 2016 auf. Bei einer Krisensitzung wurde eine letzte Frist bis Januar 2017 gewährt, wobei der weitere Fahrplan im Ungewissen liegt.<a id="a3" href="#f3">^[3]</a> <a id="a4" href="#f4">^[4]</a></p> <h2>eine abgespeckte Spec?</h2> <p>Mittlerweile scheint als Minimalziel nur die Verabschiedung einer abgespeckten Version erwogen zu werden. Konische Verläufe und netzartige Verlaufsgitter (<code>mesh</code>) sowie Schraffuren (<code>hatch</code>) sind "<em>at risk!</em>" und sollen vorerst im <a href="https://wicg.io/"> Web Incubator</a> zurückgestellt werden. Als Brutkasten für neue Ideen geplant, vermuten einige darin aber doch eher einen Sterbeplatz für Ideen ohne Lebenskraft.</p> <p>Es ist in der Diskussion, alle Spezifikationen, die sowohl CSS als auch SVG betreffen, wie z.B. <a href="https://drafts.csswg.org/css-transforms/">Transforms</a>, <a href="https://drafts.fxtf.org/filters/">Filters</a>, <a href="https://drafts.fxtf.org/css-masking-1/">Masking and Clipping</a>, <a href="https://drafts.fxtf.org/compositing-1/">Compositing and Blending</a> in CSS-Modulen zu spezifizieren. Unter dem Aspekt der <em>Separation of Concerns </em>würde dies sinnvoll sein, für SVG an sich würde es jedoch einen Aderlass bedeuten, der von Vertretern der Software-Industrie wie Tavmjong Bah kritisch gesehen wird.</p> <h2>Fazit</h2> <p>Während sich die erste Version von SVG gegenüber proprietären Lösungen wie VML als richtungsweisend erwies, litt sie doch jahrelang unter der mangelnden Browserunterstützung. Im Gegensatz dazu wirkt gerade die heute mittlerweile gute Unterstützung als Hemmschuh bei der Verabschiedung neuer Eigenschaften, die erst bei einer wahrscheinlichen Implementierung in die Spezifikationen aufgenommen werden - ein Teufelskreis, der die Weiterentwicklung ausbremst.</p> <h2>Quellen</h2> <ol> <li>W3C: <a id="f1" href="https://www.w3.org/TR/2016/CR-SVG2-20160915/">Scalable Vector Graphics (SVG) 2</a> W3C Candidate Recommendation vom 15.09.2016<a href="#a1">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f2" href="http://tavmjong.free.fr/blog/?p=1257">Paths: Stroking and Offsetting: It's not as eays as it looks.</a> vom 13.04.2015<a href="#a2">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f3" href="http://tavmjong.free.fr/svg2_status.html">SVG Status: "SVG 2 is on life support"</a> <a href="#a3">↩</a></li> <li>CSS-tricks.com: <a id="f4" href="https://css-tricks.com/svg-2-conundrum/">The SVG 2 Conundrum</a> vom 11.11.2016<a href="#a4">↩</a></li> </ol> <h2>SVG-Serie</h2> <ul> <li>Teil 1: <a href="https://blog.selfhtml.org/2016/11/23/svg-ein-format-fuer-alle-faelle/">SVG – ein Format für alle Fälle</a></li> <li>Teil 2: <a href="https://blog.selfhtml.org/2016/11/25/svg 2">SVG 2: Was lange währt</a> <li>Teil 3: <a href="https://blog.selfhtml.org/2017/04/15/svg-animationen-zum-leben-erwecken/">Animationen: SVG zum Leben erwecken</a></li> <li>Teil 4: ein Bild sagt mehr als 1000 Worte: Infografiken mit SVG <em>(geplant für Mai 2017)</em></li> <li>Teil 5: Datenvisualiserung mit SVG <em>(geplant für Juni 2017)</em></li> </ul>

<p>Im <a href="https://blog.selfhtml.org/2016/11/23/svg-ein-format-fuer-alle-faelle/">ersten Teil</a> unserer Miniserie wurde schon kurz erwähnt, dass SVG seit 15 Jahren vom W3C standardisiert ist. Seit dem Versuch SVG 1.1 und SVG Tiny aus dem Jahre 2003 zu einer Version 1.2 zu verschmelzen, hat es keine Überarbeitung der Spezifikation gegeben.</p> <p>SVG-Enthusiasten wünschten sich die Aufnahme neuer Grundformen wie z.B. einem star-Element, Eigenschaften wie variabler Randstärken und Grafikeffekten wie konischen Verläufen oder Netzstrukturen. Im Kernpunkt der neuen Spezifikation soll aber nicht die Erweiterung durch eine Vielzahl neuer Features, sondern die bessere Integration von SVG in HTML, CSS und DOM und die Entfernung nicht unterstützer Eigenschaften stehen.</p> <p><!--more--></p> <h2>Neuerungen und Änderungen</h2> <p>Eine große Vereinfachung bildet der Wegfall der DTDs und Namensraum-Angaben. In HTML5 eingebundene SVG-Fragmente werden ohne weitere Angaben erkannt und fehlerfrei ausgeführt.</p> <p>Bisher wurde in SVG mit dem XML-Dialekt XLink <a href="http://wiki.selfhtml.org/wiki/SVG/Elemente/Verweise#Referenzieren_in_SVG">referenziert</a>. SVG 2 sieht auch hier eine Vereinfachung durch die Übernahme des <code>href</code>-Attributs aus der HTML-Welt. In den meisten Browsern funktioniert dies bereits; wenn Firefox im Januar 2017 nachzieht, fehlt nur noch Safari.</p> <p>Präsentationsattribute konnten schon immer auch im CSS festgelegt werden. Neu in SVG 2 ist, dass zu diesen Präsentationsattributen auch alle Koordinaten wie <code>width, height</code> oder <code>x, y</code> und <code>r</code> gehören und so im Stylesheet festgelegt, aber auch z.B. bei <code>:hover</code> verändert werden können.</p> <p>So einfach die Einbindung von SVG in HTML ist, so umständlich ist die Integration von HTML-Code in SVG. Zwar gibt es mit dem <code><a href="https://wiki.selfhtml.org/wiki/ForeignObject">foreignObject</a></code>-Element ein Werkzeug dafür, dies wird jedoch von älteren Versionen des Internet Explorer nicht unterstützt. In SVG 1.0 kann mehrzeiliger Text nur mit mehreren <code>tspan</code>-Elementen realisiert werden. SVG 2 schafft hier Abhilfe, da man dem <code>text</code>-Element nun eine feste Breite und Höhe geben kann, um längere Texte unzubrechen.</p> <p>Neu hinzukommen sollen netzartige Verlaufsgitter (<a href="http://wiki.selfhtml.org/wiki/SVG/Farben/Verlaufsgitter"><code>mesh</code></a>) und Schraffuren (<a href="http://wiki.selfhtml.org/wiki/SVG/Farben/Schraffuren"><code>hatch</code></a>).</p> <p>Aus dem Standard entfernt wurden neben wenig sinnvollen Attributen wie <code>enable-background</code> und <code>externalResourcesRequired</code> auch der gesamte <code>font</code>- und <code>glyph</code>-Bereich, der von Anfang an unter der schlechten Browserunterstützung litt. 2001 war die Einbindung fremder Schriften mit der CSS-Eigenschaft <code>font-face</code> so noch nicht absehbar; mittlerweile hat sich dies auch in der SVG-Welt durchgesetzt.</p> <p>Trotz dieser eigentlich machbar erscheinenden Aufgabenbeschreibung verzögert sich die neue Version. Dies ist nur verständlich, wenn man sich die Hintergründe der Arbeit an der Spezifikation ansieht.</p> <h2>Interessenkonflikte</h2> <p>Für die tägliche Arbeit der Webdesigner waren die Browserkriege der Vergangenheit Gift, tatsächlich ermöglichte aber das Vorpreschen einzelner Hersteller die Implementation vieler heute aus dem Alltag nicht mehr wegzudenkender Features wie <code>canvas</code>, <code>audio</code> und <code>video</code>. Das W3C standardisierte viele dieser proprietären Lösungen in den HTML5-Standard, die dann von den anderen Browserherstellern übernommen wurden.</p> <p>Bei SVG ist die Lage viel komplexer. Während SVG im Web ein Schattendasein führte, wurde es Grundlage für Software wie Inkscape, Adobe Illustrator, Sketch und andere, die den Standard um eigene Funktionen erweiterten. In der SVG Working Group gibt es 15 Editoren aus den unterschiedlichsten Bereichen.<a id="a1" href="#f1">^[1]</a><br> So nehmen neben den blink-Browserherstellern Chrome und Opera sowie Mozilla mit Firefox auch Firmen wie Kodak, Canon, KDDI und Adobe teil. Dagegen hält sich Microsoft bis zum Abschluss der Empfehlung mit Vorschlägen und Implementationen zurück. Auch Safari hat eher die Rolle des Beobachters eingenommen.</p> <p>Beispielsweise wäre beim Zeichnen der Konturen von Objekten eine Positionierung mit einer <code>stroke-alignment</code>-Eigenschaft sehr wünschenswert. Sie ist auch in Illustrator und Sketch bereits implementiert. Beim Versuch vorhandene Features in einer Spezifikation festzulegen, kam es jedoch zu so vielen vorher nicht absehbaren Grenzfällen, dass diese Eigenschaft in ein späteres CSS3-Modul <em>stroking</em> verschoben wurde.<a id="a2" href="#f2">^[2]</a></p> <p>Diese Schwierigkeiten bei relativ einfach anmutenden Problemen scheint einer der Gründe zu sein, warum die Bereitschaft zur Mitarbeit in der <em>working group</em> immer geringer wurde. Nachdem an den regelmäßigen Telefonkonferenzen nur noch vier bis fünf Personen teilnahmen, löste der W3C die <em>working group</em> im Oktober 2016 auf. Bei einer Krisensitzung wurde eine letzte Frist bis Januar 2017 gewährt, wobei der weitere Fahrplan im Ungewissen liegt.<a id="a3" href="#f3">^[3]</a> <a id="a4" href="#f4">^[4]</a></p> <h2>eine abgespeckte Spec?</h2> <p>Mittlerweile scheint als Minimalziel nur die Verabschiedung einer abgespeckten Version erwogen zu werden. Konische Verläufe und netzartige Verlaufsgitter (<code>mesh</code>) sowie Schraffuren (<code>hatch</code>) sind "<em>at risk!</em>" und sollen vorerst im <a href="https://wicg.io/"> Web Incubator</a> zurückgestellt werden. Als Brutkasten für neue Ideen geplant, vermuten einige darin aber doch eher einen Sterbeplatz für Ideen ohne Lebenskraft.</p> <p>Es ist in der Diskussion, alle Spezifikationen, die sowohl CSS als auch SVG betreffen, wie z.B. <a href="https://drafts.csswg.org/css-transforms/">Transforms</a>, <a href="https://drafts.fxtf.org/filters/">Filters</a>, <a href="https://drafts.fxtf.org/css-masking-1/">Masking and Clipping</a>, <a href="https://drafts.fxtf.org/compositing-1/">Compositing and Blending</a> in CSS-Modulen zu spezifizieren. Unter dem Apsekt der <em>Separation of Concerns </em>würde dies sinnvoll sein, für SVG an sich würde es jedoch einen Aderlass bedeuten, der von Vertretern der Software-Industrie wie Tavmjong Bah kritisch gesehen wird.</p> <h2>Fazit</h2> <p>Während sich die erste Version von SVG gegenüber proprietären Lösungen wie VML als richtungsweisend erwies, litt sie doch jahrelang unter der mangelnden Browserunterstützung. Im Gegensatz dazu wirkt gerade die heute mittlerweile gute Unterstützung als Hemmschuh bei der Verabschiedung neuer Eigenschaften, die erst bei einer wahrscheinlichen Implementierung in die Spezifikationen aufgenommen werden - ein Teufelskreis, der die Weiterentwicklung ausbremst.</p> <h2>Quellen</h2> <ol> <li>W3C: <a id="f1" href="https://www.w3.org/TR/2016/CR-SVG2-20160915/">Scalable Vector Graphics (SVG) 2</a> W3C Candidate Recommendation vom 15.09.2016<a href="#a1">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f2" href="http://tavmjong.free.fr/blog/?p=1257">Paths: Stroking and Offsetting: It's not as eays as it looks.</a> vom 13.04.2015<a href="#a2">↩</a></li> <li>Tavmjong Bah's Blog: <a id="f3" href="http://tavmjong.free.fr/svg2_status.html">SVG Status: "SVG 2 is on life support"</a> <a href="#a3">↩</a></li> <li>CSS-tricks.com: <a id="f4" href="https://css-tricks.com/svg-2-conundrum/">The SVG 2 Conundrum</a> vom 11.11.2016<a href="#a4">↩</a></li> </ol> <h2>SVG-Serie</h2> <ul> <li>Teil 1: <a href="https://blog.selfhtml.org/2016/11/23/svg-ein-format-fuer-alle-faelle/">SVG – ein Format für alle Fälle</a></li> <li>Teil 2: <a href="https://blog.selfhtml.org/2016/11/25/svg 2">SVG 2: Was lange währt</a> <li>Teil 3: <a href="https://blog.selfhtml.org/2017/04/15/svg-animationen-zum-leben-erwecken/">Animationen: SVG zum Leben erwecken</a></li> <li>Teil 4: ein Bild sagt mehr als 1000 Worte: Infografiken mit SVG <em>(geplant für Mai 2017)</em></li> <li>Teil 5: Datenvisualiserung mit SVG <em>(geplant für Juni 2017)</em></li> </ul>