The SVG we know and love today is “SVG 1.1 2nd edition”. SVG 2 is in Editor’s Draft status at the W3C, and it’s at serious risk of never getting past that, as it’s charter may not be renewed before it reaches recommendation status.
Tavmjong Bah on part of the reason:
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.
Like Tavmjong, I also spoke with Doug Schepers recently about SVG 2. He ran through most of the major new features for me. This is a good page to see a list of those, along with their status. My hot take after that:
- There isn’t very many killer features for the layman web developer, and it’s not overly surprising to me interest all around is waning.
- Several of the really useful things that are technically SVG 2 are already supported decently (e.g.
- I’m usually wrong about stuff. There is a good chance SVG 2 features unlock amazing things that I can’t even comprehend right now.
There are a few features that are fairly obviously useful. Here’s one:
z-index. Right now there is no way to control stacking order of SVG elements other than source order. SVG 2 supports
z-index and it will just work and that will be useful. No browser is supporting it yet and it’s considered “at risk”.
Usually I think of new features on the web as a three way dance between:
- Developers. They use the features. They are the voice of what is wanted. They are the measuring stick of what actually get used.
- Browsers. They do the implementing of features. They are the gatekeepers. They have their own ideas on what is needed. They are businesses.
- Specs. They document how features should work. Browsers look to them to see how to implement features, because the incentive is there to implement features interoperability. They are middlemen. They also have their own ideas of what is needed.
Any one of them can exert force and push features along, although ultimately everyone has to agree. Developers can be really loud about a need, which may excite browsers into wanting to deliver for them, or spec authors to jump in and define how it would work. Spec authors may have a serious desire to refine and evolve a language and it’s APIs and move things along themselves. A browser might feel strongly that their customers want something (or it makes good business sense to provide something) and move forward with an early implementation.
There is plenty of crossover as well. Browser vendor people can work as spec people. Developers are sprinkled everywhere.
SVG 2 feels mostly like a spec-driven endeavour. There is a decent amount of interest in SVG right now amongst developers, but perhaps not very much chanting about SVG shortcomings. I find developers are mostly just trying to wrap their heads around what is already there. But this newfound enthusiasm is perhaps what has driven long-time SVG spec-involved people to move forward on SVG 2.
As a spec-driven endeavour, it’s on them to excite the other parties into action. That’s the part that isn’t going well so far. From the developer angle, I see it as that lack of killer features. From the browser angle, here’s Bah again:
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.
Read: Blink does whatever it wants; Gecko is slow; Edge won’t touch it; WebKit is gonna wait it out.
It gets a little worse.
For SVG 2, there is a major fourth player involved: Software.
In my estimation, the vast majority of SVG in use on the web wasn’t authored directly by developers, but output by software. Inkscape, Adobe Illustrator, Sketch, Affinity Designer… there is loads of software that exports SVG.
Let’s take another SVG 2 feature, the
B command as part of the path syntax. It looks like it it will allow for more efficient path output by allowing you to change the angle of trajectory for subsequent path commands.
That’s great and all, but why would a company like Adobe touch that? If they implement it, they risk outputting SVG that no browser supports, which isn’t useful and would certainly irk customers. They almost certainly need to wait for browser support to be very solid before moving on something like that. Which starts a vicious circle: why would browsers implement something no one is ready to take advantage of?
So even if the spec gets to some state of finished, and the browsers bite on it, we’re still at the mercy of software also taking advantage of it.
Without knowing more, I lean toward agreeing with the browser vendors. Bah reports:
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.
Sounds like the removing of new features is pretty painful, but might be the chest of gold you have to toss off the wagon to make it through the pass.