A reminder that if you're interested in #SVG and the #WebStandards process, and specifically about trying to get SVG standardization back into gear, there is an open meeting on the topic today. It's hosted by Eric Meyer ( @Meyerweb ) of Igalia, as part of W3C Breakouts Day.
Starts in 5.5 hours. You'll need a w3.org account to sign up; meeting is via zoom with irc chat.
https://www.w3.org/events/meetings/09b7b3fd-9e91-4696-a96d-ee8df6c404f3/
Rough minutes from the #SVG session, if you were interested but couldn't call in:
https://www.w3.org/2025/03/26-svg-neglect-minutes.html
There will also be a video of Eric's opening presentation.
We didn't come up with any grand solutions in 1 hour, but I think there was a loose consensus on the following priorities:
- Getting a published SVG standard that is consistent with browser SVG implementations.
- Creating a comprehensive test suite to identify interop issues.
- Using smaller feature module specs in future.
If the W3C flattens (i.e. destroys) document SVG; then Inkscape will have no choice but to fork the standard.
The domination by Browsers and what they choose or fail to implement is a serious problem. That no SVG creators were involved in this discussion is damning and furthers the rift between SVG as a document standard and SVG as a CSS add-on.
Thanks for the at FMQ.
@doctormo As I mentioned in another reply, I think the lack of clear & consistent browser implementations is an issue for SVG-based design tools, too.
But at a certain point, yeah: there's a discussion to be had about whether an open standard for advanced vector graphics is needed regardless of browser feature support. What would that look like, beyond Inkscape custom extensions? What other tools & software would use it? Can it be built as modular extensions on web SVG?
@doctormo @federicomena There was a brief effort to use a W3C Community Group as a way to encourage a wider pool of people to contribute to discussion of new SVG features, while the working group could focus on getting a standard representing what was actually being supported in web browsers.
But since the people pushing for the CG were mostly those who *didn't* want to prioritize that work, it's probably not surprising that it never took off. (says the person tasked as chair of that group)
I think yes to both. There's a good reason to have the editable SVG spec developed by multiple parties and plenty invisible data to include in it.
For us the rendering result is most useful for browser support, not all the intermediate data useful for SMIL, JavaScript or CSS. Though maybe other tools would have views on that.
Penpot is currently developing their own svg engine to replace the web browser's as it just can't keep up with the demands.
@AmeliaBR @doctormo @federicomena
For Inkscape I am working on conversions between SVG and other vector formats; I’ve written importers for CGM, HPGL2, Affinity Designer and Illustrator.
Even with Inkscape-custom extensions, there are many features in all of those formats - even the ones predating SVG - that SVG just cannot do. In terms of keeping up with proprietary tools, the current state of SVG(WG) is holding us back.
@joneuhauser @AmeliaBR @doctormo @federicomena As someone recently having moved my vector design work from Affinity Designer to Inkscape juat wanted to say thank you! I'm glad there's work being done on importers.
@travisj @AmeliaBR @doctormo @federicomena you’re welcome! We are aware of the importance to users. Please do report all issues you encounter - the Affinity importer will also get a major update in 1.4.1