SELFHTML Weblog - Ergänzung zur Dokumentation Übersicht

Neuerungen und Änderungen

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.

Bisher wurde in SVG mit dem XML-Dialekt XLink referenziert. SVG 2 sieht auch hier eine Vereinfachung durch die Übernahme des href-Attributs aus der HTML-Welt. In den meisten Browsern funktioniert dies bereits; wenn Firefox im Januar 2017 nachzieht, fehlt nur noch Safari.

Präsentationsattribute konnten schon immer auch im CSS festgelegt werden. Neu in SVG 2 ist, dass zu diesen Präsentationsattributen auch alle Koordinaten wie width, height oder x, y und r gehören und so im Stylesheet festgelegt, aber auch z.B. bei :hover verändert werden können.

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 foreignObject-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 tspan-Elementen realisiert werden. SVG 2 schafft hier Abhilfe, da man dem text-Element nun eine feste Breite und Höhe geben kann, um längere Texte unzubrechen.

Neu hinzukommen sollen netzartige Verlaufsgitter (mesh) und Schraffuren (hatch).

Aus dem Standard entfernt wurden neben wenig sinnvollen Attributen wie enable-background und externalResourcesRequired auch der gesamte font- und glyph-Bereich, der von Anfang an unter der schlechten Browserunterstützung litt. 2001 war die Einbindung fremder Schriften mit der CSS-Eigenschaft font-face so noch nicht absehbar; mittlerweile hat sich dies auch in der SVG-Welt durchgesetzt.

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.

Interessenkonflikte

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 canvas, audio und video. Das W3C standardisierte viele dieser proprietären Lösungen in den HTML5-Standard, die dann von den anderen Browserherstellern übernommen wurden.

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.^[1]
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.

Beispielsweise wäre beim Zeichnen der Konturen von Objekten eine Positionierung mit einer stroke-alignment-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 stroking verschoben wurde.^[2]

Diese Schwierigkeiten bei relativ einfach anmutenden Problemen scheint einer der Gründe zu sein, warum die Bereitschaft zur Mitarbeit in der working group immer geringer wurde. Nachdem an den regelmäßigen Telefonkonferenzen nur noch vier bis fünf Personen teilnahmen, löste der W3C die working group im Oktober 2016 auf. Bei einer Krisensitzung wurde eine letzte Frist bis Januar 2017 gewährt, wobei der weitere Fahrplan im Ungewissen liegt.^{[3] [4]}

eine abgespeckte Spec?

Mittlerweile scheint als Minimalziel nur die Verabschiedung einer abgespeckten Version erwogen zu werden. Konische Verläufe und netzartige Verlaufsgitter (mesh) sowie Schraffuren (hatch) sind "at risk!" und sollen vorerst im Web Incubator zurückgestellt werden. Als Brutkasten für neue Ideen geplant, vermuten einige darin aber doch eher einen Sterbeplatz für Ideen ohne Lebenskraft.

Es ist in der Diskussion, alle Spezifikationen, die sowohl CSS als auch SVG betreffen, wie z.B. Transforms, Filters, Masking and Clipping, Compositing and Blending in CSS-Modulen zu spezifizieren. Unter dem Aspekt der Separation of Concerns 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.

Fazit

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.

Quellen

1. W3C: Scalable Vector Graphics (SVG) 2 W3C Candidate Recommendation vom 15.09.2016↩
2. Tavmjong Bah's Blog: Paths: Stroking and Offsetting: It's not as eays as it looks. vom 13.04.2015↩
3. Tavmjong Bah's Blog: SVG Status: "SVG 2 is on life support"4th November, 2016 ↩
4. CSS-tricks.com: The SVG 2 Conundrum vom 11.11.2016↩

SVG-Serie

• Teil 1: SVG – ein Format für alle Fälle
• Teil 2: SVG 2: Was lange währt
• Teil 3: Animationen: SVG zum Leben erwecken
• Teil 4: ein Bild sagt mehr als 1000 Worte: Infografiken mit SVG
• Teil 5: Datenvisualisierung mit SVG (geplant für Juli 2023)