SVG 2 Status

4th 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.

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.