SVG 2 Status
 
Back From the Dead

After a near death experience, SVG 2 is back. Anyone following SVG 2's progress knows that the W3C SVG working group's charter ran out and was not immediately renewed. The group finally was resurrected with a strict mission of finishing SVG 2.

Recently a lot of progress has been happening,. Surprisingly a big push is coming from Microsoft (which was the last major browser to implement SVG 1.1).

Hard Decisions

In order to get the specification finished, some hard decisions have to be made. W3C rules dictate that specifications need two independent implementations of features, both to ensure the specification is complete (bad experiences with some companies holding back implementation details) and to demonstrate wide support. For web-centric specifications at least one of those implementations should be in a browser.*

At the LGM meeting I discussed the specification with Liam Quin, the W3C contact person for SVG. I took away from this discussion that the browser implementation requirement could be satisfied by a JavaScript polyfill. I also understood from this discussion that at this point in the specification process what was most important was the availability of tests for each new feature. Thus I quickly got to work converting many of the tests I created while implementing things in Inkscape to the format required for the SVG test suite and then submitting them as pull requests to the Web Platform Tests  Git repository (the repository for tests for all W3C specifications).

Shortly after I returned from LGM, the SVG working group had a meeting to decide how to proceed. It was clear that many of the things in the specification would not survive the two implementation rule. The question was how aggressive should the group be in removing items? We had a relatively long discussion on this. The general consensus was that the sooner things are removed the better. There was also push back against the idea that a JavaScript polyfill was sufficient to satisfy the browser implementation requirement. And it was clear that having tests available for a feature, while technically sufficient to avoid removing the feature at this stage of the specification process, was just going to postpone when the feature was removed. In the end, the group agreed to remove mesh gradients and hatched fills from the SVG 2 specification.

This was of course, greatly disappointing  as both mesh gradients and hatch fills have been in the SVG 2 spec for a long time and Inkscape has supported rendering of mesh gradients since 2012 and hatch fills since 2014. (One claim during the working group meeting was that these were too new and untested features.)

Hope

The future isn't completely bleak. The removal of meshes and hatches from SVG 2 is more of a pragmatic thing. Meshes and hatches do have strong support within the working group. Adobe has expressed an intent to support meshes but they want to see at least one browser support them first. To demonstrate that removing things from SVG 2 isn't the end of the road, the working group voted to publish the current SVG 2 specification with meshes and hatches intact as a First Public Working Draft of SVG 2.1.

------

* Interestingly, the first SVG 1.0 specification lists 37 authors of which only 6 might be linked directly with browsers, and SVG 1.2 Tiny has 84 authors of which only 7 appear to be linked to browers. SVG has a long history of being a generic vector graphics specification.