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”.
The Three Way Dance
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.
Three Four Way Dance
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.
From The Gut
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.
From my limited understanding, one of the major and exciting features are mesh gradients. The idea that you could make immersive and shadowed effects in an SVG open a giant amount of capabilities for responsive and performant web development.
I just want a flippin’
Inside/outside/centred stroke is a common request (since it’s supported in Illustrator & Sketch & elsewhere, and just because it would be darn useful).
There was a rough proposal for SVG, but when our Inkscape rep actually tried to implement it, he discovered all sorts of edge cases that weren’t defined. Without anyone committing time to figure out how existing software dealt with it, and without any commitments from browsers that they would implement the new feature if it was included, there was concern that it would drag down SVG 2 adoption.
The property (and a few others) was put aside to be pursued in a separate Stroke-features module (rough draft here, with details of the edge-case issues). Similarly, there are other draft “SVG Level 3” module specs that would include other interesting features that didn’t make it to SVG 2.
Unfortunately, with the browsers now backing away from SVG 2 features like mesh gradients and z-index (which we’d thought had wide support), it’s uncertain when if ever the new graphics features will be pursued.
There is now a proposed spec to get text-stroking into CSS, using all the existing SVG stroking properties. If
stroke-alignmentever happens, it might be through that effort.
That’s a real shame. There’s still a lot to be done about SVG before it becomes a real, modern and maintainable tool for all sort of usages.
Yes, z-index would be very welcome indeed; but I’ve discovered that several attributes now can be stylized – and animated! – via CSS, like
ror even path’s
d. We could get finally rid of that awkward XML syntax for filters and animations (really, it’s like still using the
Do we really have to wait and hope that Google will get things done?
Regarding the comment about software vendors not wanting to output things that might not work.
Adobe (and other vendors) have a long history of including new features willingly, and offering multiple options for output.
If you ever export or save anything from almost any Adobe software, surely you would have noticed the options that always pop up asking if you want it to be compatible or use the latest features, or which version of illustrator file you want it saved as, or in the case of SVG, which version of SVG file you want and what features to support.
I think it’s pretty clear that Adobe (or other software vendors) would ensure that they are not the ones left behind should this start gaining any momentum.
This might be “shocking” for Inkscape developers, but for the web developers it’s a good news.
The most useful parts of SVG have been already moved to CSS and are either implemented or being implemented by browser vendors (animations, fonts, clip-paths, masks, filters, transforms, gradients, etc.).
My guess is that browser vendors are now planning to kill SVG 2 and add a minimal set of vector elements directly to the HTML spec instead. Something akin to / VectorDrawable from Android would cover the needs of most web developers.
Bring back SMIL
Please look into mesh gradients and then come tell me that there are no killer features. All serious illustrators use them in their graphic tools, and then the exported SVG is full of bitmaps that bloat it hugely. The lack of excitement for SVG 2 is largely due to ignorance, not due to lack of killer features in the spec.
It really astonishes me, after all these years, that there are so many not in the know about the power of SVG compared to any other alternative. Especially those features that simplify making SVG fast, responsive (scalable) and accessible.
There is one other major category that was not mentioned and shoudn’t be forgotten — web software vendors and programmers who have tools and/or code to simplify dynamic generation of SVG on-the-fly as well as support dynamic interaction … Google Charts being just one such example. And yes … designers who create SVG content ideaally would influence features that “desktop” Software vendors support (mesh gradients for one) but the bigger issue I think is reaching a diverse audience to make them all aware … and get them all excited … about the potential of features that should be (likely would be) important to them.
First, stroke alignment, z-index are absolutely killer features. Dealing with dynamic stack order is very hard without them. They aren’t just nice-to-haves. They can be brutally difficult to work around. Gradient meshes are a very nice-to-have. SVG looks like MacPaint without them. It will look more and more archaic as time passes. Text flow in SVG1 is also a nightmare for anyone who’s had to deal with it. ForeignObjects with text don’t work as expected, anywhere.
To start off, we just need 1 functioning kickass demo, per feature, working in 1 browser. Bug tickets that say “Why does this awesome data visualization with gradient meshes not work in your browser?” have a legitimate shaming force. In my distant estimation, the Blink team has done a great job of closing SVG tickets, especially since Opera got on board.
More generally, I’m bummed that there doesn’t seem to be a solid strategy for adding features in a backwards compatible way. Switching the SVG parser to use the HTML5 parser seems like it opens possibilities here. Unrecognized elements and attributes could simply be ignored, without throwing a parse error. There has to be a way to structure SVG for basic progressive enhancement going forward, otherwise new features become impossible to add. HTML basically solved this problem of lock-in long ago.
Finally I think it’s useful to remember that SVG1 was a crazy christmas tree of a spec with a whole host of things that took a decade to get good interoperability on. We’re spoiled by the current environment of good conformance. For a long time, only Opera had really good impementation. But we have something incredibly powerful today partly because the original spec writers were thinking aspirationally. It is a bit sad to see the spirit of that futuristic orientation fading away. Keep dreaming, people!
I’m a little confused as to how “Gecko has implemented more of SVG2” ended up with the summary “Gecko is slow (to implement)”.
Marco Carosi wrote in: