Das SVG 2 Konundrum

Das SVG, das wir heute kennen und lieben, ist „SVG 1.1 2. Edition“. SVG 2 befindet sich beim W3C im Status eines Editor's Draft und es besteht die ernste Gefahr, dass es diesen nie verlassen wird, da sein Mandat möglicherweise nicht verlängert wird, bevor es den Empfehlungsstatus erreicht.

Tavmjong Bah über einen Teil des Grundes

Obwohl schockierend und unerwartet, kam es nicht aus heiterem Himmel. Die aktive Beteiligung in der Arbeitsgruppe ist auf nur eine Handvoll Leute gesunken, von denen keiner die Browser-Anbieter vertritt. Tatsächlich hatten die letzten beiden „persönlichen“ Treffen nur drei reguläre Teilnehmer, einer von Canon (das seine Mitgliedschaft im W3C Ende des Jahres beendet) und zwei eingeladene Experten, die kostenlos arbeiten.

Wie Tavmjong sprach ich kürzlich auch mit Doug Schepers über SVG 2. Er nannte mir die meisten neuen Hauptfunktionen. Diese Seite ist gut, um eine Liste davon zusammen mit ihrem Status zu sehen. Meine sofortige Meinung danach

• Es gibt nicht sehr viele Killer-Features für den gewöhnlichen Webentwickler, und es ist für mich nicht allzu überraschend, dass das Interesse insgesamt schwindet.
• Einige der wirklich nützlichen Dinge, die technisch SVG 2 sind, werden bereits ordentlich unterstützt (z. B. non-scaling-stroke).
• Ich liege normalerweise mit Dingen falsch. Es besteht eine gute Chance, dass SVG 2-Features erstaunliche Dinge freischalten, die ich mir im Moment noch nicht einmal vorstellen kann.

Es *gibt* ein paar Features, die ziemlich offensichtlich nützlich sind. Hier ist eines: z-index. Derzeit gibt es keine Möglichkeit, die Stapelreihenfolge von SVG-Elementen außer der Quellreihenfolge zu steuern. SVG 2 unterstützt z-index, und es wird *einfach funktionieren*, was nützlich sein wird. Kein Browser unterstützt es bisher, und es gilt als „gefährdet“.

Der Drei-Wege-Tanz

Normalerweise denke ich bei neuen Features im Web an einen Drei-Wege-Tanz zwischen

• Entwickler. Sie nutzen die Features. Sie sind die Stimme dessen, was gewünscht wird. Sie sind der Maßstab dafür, was tatsächlich genutzt wird.
• Browser. Sie implementieren die Features. Sie sind die Gatekeeper. Sie haben ihre eigenen Vorstellungen davon, was benötigt wird. Sie sind Unternehmen.
• Spezifikationen. Sie dokumentieren, wie Features funktionieren sollen. Browser sehen sie an, um zu sehen, wie Features implementiert werden sollen, da es einen Anreiz gibt, Features zur Interoperabilität zu implementieren. Sie sind Vermittler. Sie haben auch ihre eigenen Vorstellungen davon, was benötigt wird.

Jeder von ihnen kann Druck ausüben und Features vorantreiben, obwohl letztendlich jeder zustimmen muss. Entwickler können sehr lautstark auf ein Bedürfnis aufmerksam machen, was Browser dazu anregen könnte, es liefern zu wollen, oder Spezifikationsautoren dazu bringen, sich einzuschalten und zu definieren, wie es funktionieren würde. Spezifikationsautoren haben möglicherweise den starken Wunsch, eine Sprache und ihre APIs zu verfeinern und weiterzuentwickeln und Dinge selbst voranzutreiben. Ein Browser könnte stark das Gefühl haben, dass seine Kunden etwas wollen (oder es aus geschäftlicher Sicht sinnvoll ist, etwas bereitzustellen) und mit einer frühen Implementierung fortfahren.

Es gibt auch viele Überschneidungen. Leute von Browseranbietern können als Spezifikationsleute arbeiten. Entwickler sind überall verstreut.

SVG 2 fühlt sich größtenteils wie ein von Spezifikationen getriebenes Unterfangen an. Es gibt einiges Interesse an SVG bei Entwicklern, aber vielleicht nicht viel Gebrüll über SVG-Mängel. Ich finde, Entwickler versuchen hauptsächlich, das, was bereits vorhanden ist, zu verstehen. Aber dieser neu gewonnene Enthusiasmus ist vielleicht das, was langjährige SVG-Spezifikationsbeteiligte dazu gebracht hat, mit SVG 2 fortzufahren.

Als von Spezifikationen getriebenes Unterfangen liegt es an ihnen, die anderen Parteien zum Handeln zu bewegen. Das ist der Teil, der bisher nicht gut läuft. Aus Entwicklersicht sehe ich es als diesen *Mangel an Killer-Features*. Aus Browsersicht, hier ist Bah wieder

Es gibt nur zwei Browser-Implementierungen von Bedeutung: Blink (Chrome/Opera) und Gecko (Firefox). Von diesen hat nur Blink die Ressourcen, um neue Features schnell vollständig zu implementieren, obwohl Gecko mehr von SVG 2 implementiert hat. Chrome hat einen riesigen Vorsprung bei Marktanteilen (fast 75 %). Google hat die Angewohnheit, Features, die es nicht mag, einseitig aus Blink zu entfernen und damit im Grunde zu diktieren, dass diese Features aus Spezifikationen entfernt werden.

Zwei weitere bedeutende Browser-Implementierungen, WebKit (Safari) und Edge, sind eher Nachfolger als Vorreiter und haben relativ geringe Marktanteile (jeweils 5 % und 4 %). Microsoft hat beispielsweise ausdrücklich erklärt, dass sie sich SVG 2 erst ansehen werden, wenn die Spezifikation eine Candidate Recommendation ist.

Lesen: Blink macht, was es will; Gecko ist langsam; Edge wird es nicht anfassen; WebKit wird abwarten.

Es wird ein wenig schlimmer.

Der Drei-Vier-Wege-Tanz

Für SVG 2 ist ein wichtiger vierter Akteur beteiligt: **Software**.

Meiner Einschätzung nach wurde die überwiegende Mehrheit des im Web verwendeten SVG nicht direkt von Entwicklern erstellt, sondern von Software ausgegeben. Inkscape, Adobe Illustrator, Sketch, Affinity Designer… Es gibt jede Menge Software, die SVG exportiert.

Nehmen wir ein weiteres SVG 2-Feature, den Befehl b oder B als Teil der Pfadsyntax. Es sieht so aus, als ob er eine effizientere Pfadausgabe ermöglicht, indem er es erlaubt, den Richtungswechsel für nachfolgende Pfadbefehle zu ändern.

Das ist alles schön und gut, aber warum sollte ein Unternehmen wie Adobe sich damit befassen? Wenn sie es implementieren, riskieren sie, SVG auszugeben, das kein Browser unterstützt, was nicht nützlich ist und Kunden sicherlich verärgern würde. Sie müssen fast sicher auf eine sehr solide Browserunterstützung warten, bevor sie sich mit etwas wie diesem befassen. Das beginnt einen Teufelskreis: Warum sollten Browser etwas implementieren, das niemand zu nutzen bereit ist?

Selbst *wenn* die Spezifikation einen gewissen Fertigstellungsgrad erreicht *und* die Browser sich dafür entscheiden, sind wir immer noch auf die Gnade der Software angewiesen, die diese Features ebenfalls nutzt.

Aus dem Bauchgefühl heraus

Ohne mehr zu wissen, neige ich dazu, den Browseranbietern zuzustimmen. Bah berichtet

Der allgemeine Konsens der Browseranbieter ist, dass SVG 2 fertiggestellt werden sollte, aber auf die Behebung der Probleme mit SVG 1.1 2. Edition beschränkt sein und nur wenige ausgewählte neue Features (wie 'paint-order') enthalten sollte, die bereits von mehreren Browsern implementiert wurden. Neue Features (Meshes, Schraffuren etc.) sollten entfernt werden.

Es klingt so, als wäre das Entfernen neuer Features schmerzhaft, aber es könnte die Schatztruhe sein, die man vom Wagen werfen muss, um den Pass zu überqueren.