SVG 2 Status

4^th November, 2016

SVG 2 is on life support.

Background

About a month ago the W3C's SVG staff contact person (Doug Schepers) relayed some very alarming news... that the SVG Working Group charter was not going to be renewed when it expired at the end of October, 2016. This was quite shocking as the group had worked quite hard to get the SVG 2 specification to Candidate Recommendation status. If the charter is not renewed, it would mean an immediate end to SVG 2.

While shocking and unexpected, it didn't come out of left field. The active participation in the working group has dropped to just a handful of people, none representing any of the browser vendors. In fact, the last two "face-to-face" meetings had attendance of just three regular participants, one from Canon (which is dropping membership in the W3C as the end of the year) and two invited experts who are working for free. The weekly teleconferences were down to four or five participants (with representatives from KDDI and the W3C).

Recent Developments

The working group appealed to the browser vendors for support in renewing the charter. A teleconference was organized with multiple representatives from each of the major browser vendors as well as a number of other interested parties (Adobe, Canon, KDDI, etc.). The general consensus from the browser vendors is that SVG 2 should be finished but that it should be restricted to fixing the problems with SVG 1.1 2nd edition along with a few choice selected new features (like 'paint-order') which have already been implemented by multiple browsers. New features (meshes, hatches, etc.) should be removed and pushed into a WICG group. (Wrapped text was not discussed.) (See minutes.) A resolution was made to Re-charter SVG WG for one more year with a focus on moving SVG 2 to REC with only the features that have implementer experience. Note that this is a WG resolution and not a W3C agreement to continue the group.

With a focus on a limited SVG 2 specification, the W3C has agreed to extend the current SVG Working Group charter until the end of January in order to give the group a chance to sort out a new charter. Any new charter will focus on completing SVG 2 by developing a test suite and in pushing for implementations.

An additional discussion by the WG was that all joint CSS/SVG specifications will be completely taken over by CSS. This includes Transforms, Filters, Masking and Clipping, Compositing and Blending, etc. This completes the long process of CSS stealing absorbing the most interesting SVG features.

Future

The future is pretty cloudy at the moment. Here are some observations:

• There are only two browser implementations of importance: Blink (Chrome/Opera) and Gecko (Firefox). Of these, only Blink has the resources to fully implement new features quickly although Gecko has implemented more of SVG 2. Chrome commands a huge lead in browser market share (almost 75%). Google has a habit of unilaterally removing features it doesn't like from Blink, basically dictating that those features are removed from specifications.

  Two other significant browser implementations, WebKit (Safari) and Edge, are more followers than leaders and have relatively little market share (5% and 4% respectively). For example, Microsoft explicitly stated that they would not even look at SVG 2 until the specification was a Candidate Recommendation (while the other browser vendors have implemented a limited set of SVG 2 features such as 'paint-order', see SVG 2 Feature Support for current status of SVG 2 implementation).

• There seems to be a disconnect between the browser vendors and the content creators. Even Adobe has expressed frustrations with the current status (and they have significantly reduced their involvement with W3C as a result).

• Moving things into a WICG is not a viable strategy. Without browser vendor buy-in, things are likely to never emerge from a WICG group. In addition, a WICG group is intended to develop new ideas to the point where the browser vendors can have a look at them. Both meshes and hatches are already well developed with Inkscape supporting full rendering for several years. (Note that the browsers already have code to render meshes as they all support meshes in PDF.)

• Despite the large turnout for the SVG WG meeting where we discussed the future of SVG 2, we have received almost no feedback (after requesting it several times) from the browser vendors on which SVG 2 features they are likely to implement. This seems to be indicative of the low interest they have in implementing SVG 2.

• Even the CSS working group, which has a much larger active participation, is having trouble getting their specifications out. Both SVG and CSS seem to be passé. The new darling of the browser vendor set is Houdini which offers lower level access to browser internals. This is not unexpected as browsers continue on the path to being the new OS.

• The most important long term observation is that browser vendors respond to demand. I've been told SVG would never have been part of HTML5 if it wasn't for Inkscape which allowed the production of tons of SVG's used in the Wikipedia. Browser vendors keep track of the use of various features. Features with more use get more attention.

What should Inkscape do?

Given the above observations, if we really want mesh, hatches, etc. to remain part of SVG 2 and to be supported by browsers we must generate content that uses those features; content that gets people excited enough to put pressure on the browser vendors to implement them. We've already started to do this in a limited way by enabling the use of 'paint-order' which is supported by three of the four major browsers.

Of course this means that some artwork created using Inkscape won't be viewable directly on the web. We should accept this as a necessary (and hopefully temporary) step. We can provide warnings in Inkscape when artists use features that are not widely supported. We can advise artists of work-arounds, i.e. converting a mesh to an internal image when exporting. And we can provide polyfills that replace internal browser functionality with JavaScript implementations. (I've already started work on a mesh gradient polyfill.)

I've been working on improvements to the mesh gradient GUI. This work has been back-ported to 0.92. We plan on enabling mesh gradients by default in the 0.92 release. This will start generating public content that uses mesh gradients.