Is SVG 2 really on life support?

by Alexandre Prokoudine
Filed under: Design, Interviews,
SVG / Inkscape / W3C

Between SVG 1.1 W3C Recommendation and SVG 2 in its current form, people have raised kids and sent them off to the college. And yet SVG 2 might arrive sometime in the future without quite a few useful features that have been already developed and tested. What’s up with that?

During the Inkscape’s board meeting, Tavmjong Bah shared a write-up on the status of SVG 2 based on recent happenings around the SVG Charter. While we encourage you to read it in its entirety, for the record, here is a quick summary:

  • Very few people actually contribute to the evolution of the SVG specification; entire companies dropped off de facto or are about to drop off the charter de jure.
  • There are not enough implementations of SVG 2 to test proposed new features.
  • So there is not enough content using those features to justify implementation in browsers.
  • Therefore browser vendors are not spending their resources on adding those features.
  • Which means features like gradient meshes and hatches would be axed from SVG 2 and moved to Web Incubator Community Group (WICG).
  • All in all, there is a substanical possibility that SVG Working Group charter will not be renewed.

For Inkscape users this means that a handful of new features in upcoming v0.92 may become unsupported in SVG 2.

This topic clearly involves multiple parties. We are starting with Tavmjong Bah (Inkscape developer, invited expert in the SVG working group) and hope to hear from browser vendors and other charter members to get the full picture.

Tavmjong, how did the SVG WG end up in this situation with regards to SVG 2? Is it “death by committee”?

SVG is a huge specification with a small group working on it. Some of the most active members focused on joint CSS/SVG specs like Compositing and Blending, Transforms, Filters, Masking and Clipping. There wasn’t much time left over for working on SVG 2 directly but still we plugged away. Most of the work was on things of little interest to Inkscape but of importance to browsers (like the DOM interface).

The SVG 2 group had their differences, but nothing major (being very pragmatic about things like SVG Fonts). Two major browser vendors provided the co-chairs until the past year. One co-chair was laid off (from Opera) and another changed positions (from Mozilla) and no longer works on SVG. Neither were replaced.

You mention that “there seems to be a disconnect between the browser vendors and the content creators. Even Adobe has expressed frustrations with the current status…”. Would you say that SVG prior to v2 as we know it now lacked certain features that appealed to content creators? Or are there more significant factors at play here?

I’m not sure I understand your question. As I see it, from Inkscape’s perspective SVG 2 is missing:

  • mesh gradients, supported in PostScript/PDF/Illustrator/etc. and very important to illustrators;
  • hatches, supported by any CAD program and important for technical drawings and for people who use SVG as input for engravers, embroidery, and plotters;
  • solid colors which are part of SVG 1.2 and a far better way to handle “swatches” than using single stop gradients;
  • and of course, text in a shape.

There are a lot of other improvements in SVG 2 such as enabling the automatic matching of an arrow head fill color to the path’s stroke color, the paint-order property, and better closing path syntax.

What are the exact implications of moving all new features to WICG? Who would be working on new features in WICG given how little participation there is at the moment?

The idea of WICG is that community (i.e. not the browser vendors) develop new ideas that the browser vendors can then have a look at and say yea or nay.

I don’t see this as a viable alternative for several reasons including lack of browser buy-in. And it is also not appropriate for SVG 2 features since they have already been developed and tested.

To me it looks like SVG is pretty much at the mercy of browser vendors who don’t exactly contribute to its evolution.

Yes. It wasn’t always that way. In the early days there were many different SVG renderers so one could find multiple implementations of most features. It was sufficient for something to remain in the spec, if there were two independent implementations.

The idea was that eventually all browsers would support all features if not right away. Of course it took IE many years to support SVG.

Now with just a handful of renderers in browsers it becomes harder to find two implementations, and even if there are two, it does not guarantee something staying in the spec. If one browser comes out adamantly against something, then it gets removed (e.g. SVG fonts, etc.).

Would you say that the existing process gives the specification developers a fair chance to get new useful features included into the final recommendation?

If you had asked me three months ago I would have said yes. Now I would say no.

From what I can see in telecon logs, it looks like browser vendors are OK with new features as long as implementations exist, and accessibility is taken care of.

Inkscape has fully working rendering implementations of meshes (for four years) and hatches (for two or three years). So existing proof-of-implementability is not enough. Accessibility in this context is not an issue.

If the charter isn’t renewed, who will be there to sort out whatever comes out of the incubator?

The CSS working group? Or nobody. By the way, The HTML canvas element is suffering the same problem in that there is no group to maintain it.

As a principal author of quite a few new features in SVG 2, do you have an idea of a solution to getting major incomplete and missing features done? (stroke positioning, pages etc. — all the recently discussed axed features and more).

I am afraid I don’t see the browser vendors spending much effort on them given the discussion last month. The only spec that has had any interest from CSS is the strokes spec (they want to be able to stroke bounding boxes).

Notably, in your write-up, you mostly mention the charter, Inkscape, and browser vendors. What is your understanding of where SVG (1.1 and/or 2) currently stands with regards to authoring applications? Moreover, some features appear to lack the “second implementation”. Would it be correct to assume that Inkscape is the only authoring app project actively involved with SVG currently?

Adobe Illustrator supports export to SVG 1.1. I don’t know of any SVG 2 features they have implemented (since I don’t use it). They did have very strong interest in the things that got removed from SVG and put into joint CSS/SVG specs, so I am sure they support those in their web design programs.

During WG telecon in early October this year, Dirk Schulze said this: “Adobe have a strong interest in getting more features — e.g. mesh gradients, stroke features, variable width stroke, etc which do not neccessarily need to live in the SVG WG, but we do want to see them proceed”. So it looks like Inkscape’s interests align with those of Adobe. Do you see this as a starting point for a conversation on getting the much required “second implementation” done?

It has been suggested that they may be an ally. Although I was also informed that they are frustrated with participating in the W3C specification process and have seriously cut back their participation (certainly we haven’t seen their active participation in the SVG group for a couple of years).

Do you have any advice to users others than creating more content that uses proposed SVG 2 features?

There are three things that the browser vendors seem to be sensitive to:

  1. The opinions of major JavaScript library authors like D3.
  2. Large corporations.
  3. Use counters.

I’m not sure about 1). 2) won’t help, although Boeing is a possible ally for hatches since they are converting their technical drawings to SVG. 3) is the easiest place for us to have an impact.

How do browser vendors assess use counters?

They add code to their browsers to track things. Here is Chrome’s publicly visible use statistics: https://www.chromestatus.com/metrics/css/popularity.

Basing decisions off this has some serious flaws. It doesn’t take into account the fact that something isn’t used due to it not being cross-browser available. For example, SVG would have rated very low before implementation in IE.

Will Inkscape 0.92 expose SVG 2 features by default in team’s own binary builds? What will be the team’s recommendation to 3rd party distributors?

We should encourage them to enable them. Already, we have ‘paint-order’ and new filter blending modes in the GUI. Speaking of which, Firefox has never supported Inkscape’s layer blending using filters and we’ve never heard complaints about it.