– DRAFT –
Vectors of Neglect

scribe nick:bkardell

Intro Presentation

Slideset: https://notes.igalia.com/p/ArMVOqf-h#/

emeyer: Welcome to this breakout session. Thank you all for being here.

emeyer: SVG has some very deep roots at W3C.
… call for proposals in 1998, work started officially 1999
… first W3C REC in Sept 2001, and first browser support in Konqueror in Feb 2004

emeyer: Various proposals to move forward in recent years
… a lot of interest in SVG, maybe more than people realize
… Popular in web design, e.g. used in logos, buttons, navigation, icons
… Consistenly cited as a developer pain point.
… In the most recent State of HTML survey, it was #2.
… and is a common StackOverflow topic
… The <path> element is in the top 10% of elements. More popular even than <br>
… Also currently the most popular color font format, though other formats starting to catch up.

emeyer: But there's a lot of inertia on the standards side.
… In 2024, almost not even rechartered.
… But the only discussion has been these 4 messages to the email list this year asking what's up.
… This is unfortunate.
… And there's also inaction on the implementation side.
… Every year proposed for Interop project, and every year gets passed up.
… The stakeholders in Interop don't rate it highly enough to make the cut.
… (To be fair, Interop gets way more proposals than it can take on.)
… And when it comes to investment, while major implementers do put in some work
… a lot of outside funding.
… E.g. Wix funding work a replacement SVG engine.
… It's awesome that 3rd parties fund development of SVG, but sad that so little investment from in-house.

emeyer: What are the alternatives to the current system?
… Because the current system is not producing anything.
… Servo is starting to gain some momentum, can't fund a full staff, but starting to pick up speed.
… There's a MathML collective that Igalia has worked with to push forward MathML work
… It had a couple of generous individual donors who helped make that happen.
… Grants? E.g. sovereign tech fund in Germany.

emeyer: In a way, almost easier to ask where to get money, harder to create momentum within the WG and among implementers.
… This session is about brainstorming -- how can we make these things happen?
… What are examples of successful momentum-building that we could look to?
… What are some mistakes to avoid?
… Would love to hear ideas.

Discussion

<bkardell> Thanks to Apple and Microsoft engineers who attended today

AmeliaBR: For those who don't know, I was an Invited Expert in SVGWG from 2015-2020.
… I dropped out due to health issues, though by 2020 WG was grinding to a halt anyway
… Fewer and fewer people having time to contribute or even show up to meetings.

AmeliaBR: Summarizing issues I was seeing at that time...
… SVG is a really big component. Not really one little feature to fix, it's a complicated and united system.
… Original SVG spec was created before the W3C had learned from experience about how to do Web stanards
… So it was published as a huge thing, this is how it should be, then wait around for implementers.
… No back and forth.
… No comprehensive test suite in the way that we now expect for Web platform features.
… And implementations that did come are ~20 years old now
… And those are built on top of other vector graphic libraries that have similar features but not exactly the same.
… It's a huge complicated project, and very few people know what the browser code needs to be.
… And those people were not active in the WG.
… People involved were more coming from graphics side, and more high-level web standards folks. Not implementers.
… This led to a lot of disconnect.

AmeliaBR: When SVG2 developed, wanted to be a high-level graphics language.
… But after publication, became clear that not a lot of support in browser teams for implementing these features
… that people had spent a lot of time specifying.
… Those who put a lot of work in felt disappointed and burnt out
… and on the other side, implementers were frustrated that not designing features in a way that integrated with implementation work
… And meanwhile other tech exploding and taking interest, e.g. CSS.

AmeliaBR: So here we are, not much progress in the last 4-5 years of SVG.

AmeliaBR: We need to break down this project. Saying "we need interop on SVG" is a paralyzingly large project.
… The spec needs work. SVG2 as published has a mix of compatibility improvements over SVG 1.1, specifying undefined behavior and getting better interop
… There were features that have been picked up by browsers, like setting geometry from CSS.
… And then all these other features, which didn't get adopted.
… So the spec needs to be broken down to what can we reasonably get interop on.

AmeliaBR: Another huge aspect is building a test suite.
… There are just not tests to the modern standards.

AmeliaBR: Finally, there needs to be people actually implementing. Spec and test alone are not enough.

<astearns> more tests can help with getting it into the interop project

AmeliaBR: This is multiple years of work. We need clear tests, and a clear spec, and only then can we put pressure people to work on implementations.
… Maybe we narrow down and work section by section. Idk.
… But one of the big issues is, there are lots of people who say they support SVG and want it to be more reliable, but getting people with the skills and the time and the funding support or organizational support
… Getting people talking, the people who know what the want, and the people who know how to work in these messy codebases.
… That's the major blocker.

emeyer: Very much appreciate the perspective.

bkardell: Some of the things you were doing before 2020 or so, that I thought was really useful and mostly happened, was creating consistent IDL for things
… Clarifying how SVG integrates into the platform.
… Not even specified previously.
… I know there's a lot of spec-work to do, but I think that there's a lot of things that we could be working on.
… In Interop, you said multiple years; but every year more than one proposal relating to SVG. E.g. this year one about focus filters.
… But there weren't tests for it in WPT.
… So we proposed an investigation area, to write SVG tests
… But that also didn't happen.

ydaniv: Thanks for organizing this discussion.
… A lot of what AmeliaBR said, I can relate to.
… I proposed SVG as an investigation area before, and got rejected.
… Once was because SVG1.1 test suite, obsolete test suite is already there, but not usable.
… One of the things maybe somehow we need to get is to modernize and rewrite it, to be full-fledged test suite for SVG1.1
… That could improve state of existing SVG.
… Then there are tests for various SVG 2.0 features that have been implemented in engines.

ydaniv: Then there's the problem of 20yr-old code.
… Many people want to work on it, but not prioritized.
… The LBSE project from Igalia could maybe spark life into this.

<emeyer> s/???/LBSE/

<bkardell> s/???/LBSE (Layber Based SVG)

ydaniv: If one engine is rewritten and starts to do wonders in SVG's performance and animation and new capabilities like 3D tranforms etc.
… That could put pressure on other browsers to start prioritizing the work in their engines.

<bkardell> s/(Layber Based SVG)/(Layer Based SVG Engine)

ydaniv: Create a competetition.
… A lot of stuff in CSS today started in SVG, came to CSS and got better.
… If SVG can overcome the distance, things could start influencing back and forth
… could lead to more progressin in both CSS and SVG.
… Just like we have shape() function in CSS.
… Stuck because we can't evolve SVG.

ydaniv: Things changed in how we write specs. Now we write in modules.
… SVG1.2 such a monumental huge piece of work, hard to figure out where to start.
… Maybe break apart into modules.
… Some might be important to implement, some maybe not so much.

emeyer: Proposing to split into modules?

ydaniv: it's a thought.

ydaniv: It's tests, implementations, spec.
… I come from Wix. We've been trying to kick off LBSE project to get implementation rolling
… Thanks so much to Apple for allowing this to happen.
… I hope we can see this project to its final end.

Said: Want to respond to Amelia wrt SVG2.
… When I looked at the spec... I couldn't understand [missed]
… Most disappointing, it didn't talk about backwards compatibility.
… When changing interface, do I keep old one? change ot new one? something else? What do I do?
… SVG is defined in isolation, but not so clear about how it handles integration in CSS, in source document.
… Part of why SVG2 was so hard to adopt is because no clear benefit.

<Zakim> Mike, you wanted to comment

Mike5: I work for W3C on staff in Tokyo. sideshowbarker on GH.
… I've contributed to various browser projects, WebKit more than others in the past.
… But main place now is Ladybird.
… The philosophy of Ladybird is to implement from scratch all the existing web platform specs
… As part of that, we have people working on implementing SVG.
… We are among the people feeling acute pain about the lack of investment in SVG.

<Mike5> https://svgwg.org/svg2-draft/

Mike5: One pain point, if we look at currently published SVG spec

<Mike5> 08 March 2023

Mike5: 8 March 2023 is the last publication.
… Some PRs have been getting merged in the meantime, but not getting reflected in the published spec because the auto-publishing mechanism for SVG
… broke some time ago
… and we need to fix that!
… Right now only one person can do it, discussing with them.

<AmeliaBR> To be clear, the spec draft Mike is talking about is the *Editor's Draft*, not even the formal W3C published version!

Mike5: When he has time to fix immediate problem, but we have an ongoing probme that we should take over ownership -- W3C taking ownership of that domain -- so that it doesn't break.
… Or set up a redirect

<emeyer> s/from main to master/to main from master/

Mike5: Another problem is we don't have anyone reviewing PRs
… I merged a few myself, but we had nobody else responding to PRs.
… I am not an SVG implementer, so I have no business merging edits to this spec.
… What would be extremely helpful would be if we had implementers, anyone working on an SVG implementation who could devote some amount of time to reviewing PRs as they come in.
… Please reach out if you can do this, here, on IRC, or to mike@w3.org
… Minimally if we could just get someone reviewing PRs, that would be progress.

<Mike5> https://wpt.fyi/results/svg?label=master&label=experimental&product=chrome&product=firefox&product=safari&product=ladybird&product=servo&product=flow

Mike5: We have an embarassment of riches here -- no shortage of SVG implementation
… at least 6 different implementations just in browsers
… This is results against the existing test suite, which does not adequately capture requirements.
… But you can show how Chrome and Firefox are doing well on these tests, but still have a lot further to go.
… Ladybird is reporting results ,and we have another dedicated SVG engine.
… That engine marketed on the basis of their SVG support, I guess if they can do that even though not passing so many tests, maybe the situation is not that bad.
… Ladybird implemented by Andreas Kling originally, now other developers are working on it.
… Philosophy is, if we run into a site where site experience is degraded due to lack of SVG support
… We had a crash on reddit, for example,
… That was fixed.

<Mike5> https://github.com/LadybirdBrowser/ladybird/commit/b8adf193f52c4c7089e4e97edd380db189bd6362

Mike5: Minimally, to get it to stop crashing.
… What I see is usage across normal sites. You cannot implement a browser engine without implementing SVG.

<Zakim> fantasai, you wanted to comment on CSS modularization

Mike5: #1 thing I wish is people to help review PRs

fantasai: When we modularized CSS, we did that on top of CSS 2.1
… Took us about 13 years to get 2.1 to be solid enough
… For SVG, modularizing makes sense, but you need a core specification that you can build on

<bkardell> like mathml core :)

fantasai: Originally in CSS, the plan was to creaet a network of modules that replaced 2.1
… We eventually realized that was essentially impossible
… So we defined 2.1 to be the basis, and modules to add things on top of it

<fantasai> AmeliaBR: Idea of switching to more modular approach to SVG was definitely something strongly discussed in the WG

<fantasai> ... Idea was to get SVG2 as that baseline and then all future work would happen in modules.

<fantasai> ... There are a number of secondary specs built to push out some of the newer more exciting features that didn't have implementer support.

<fantasai> AmeliaBR: Said brought up issue of not defining interactions with HTML etc.

<fantasai> ... There was a separate spec that defined all that, but apparently not referenced well enough that ppl can find or reference it

<fantasai> AmeliaBR: It all comes back to, need people to work on it.

<fantasai> ... Define baseline support, find conflicts, fix errors, etc. Need people to do the work.

<fantasai> caribou: Carine from W3C, staff contact for SVGWG.

<fantasai> ... thanks Amelia for the background

<fantasai> ... I've never been in charge of such a non-functional WG

<fantasai> ... Issues raised, but no responses.

<fantasai> ... I also merged a few trivial PRs.

<fantasai> ... Given state of WG last year when the charter was expired, I proposed to close the SVGWG and hand the work over to the larger community.

<fantasai> ... But the CG was not very successful either.

<fantasai> ... There was pushback, as long as browser implementers interested in partiicpating, should keep the group open.

<fantasai> ... But I've not seen any progress.

<fantasai> ... I asked if there were any volunteers to edit the spec

<fantasai> ... But no responses.

<fantasai> ... I'm still wondering what to do to revive the effort.

<fantasai> ... Interesting to discuss how to organize, but if we have nobody, nothing will happen.

<fantasai> smfr: I think a good goal for the near term is to get a spec that reflects what browsers are currently shipping.

<fantasai> ... E.g. WebKit adopted a bunch of changes from SVG2, e.g. dropping namespace requirement

<fantasai> ... It would be useful to come up with that subset, and work on WPT tests.

<fantasai> ... That thing can become SVG2, or 1.8 or whatever.

<fantasai> ... I think that's a good initial goal.

<fantasai> smfr: 2nd thing is, I see interest in version of SVG without scripting support.

<fantasai> ... a huge amount of complexity in the implementation are due to scripting ability

<fantasai> ... a scriptless implementation could be much simpler

<fantasai> emeyer: Do you mean no DOM scripting?

<fantasai> smfr: No JS access to the SVG DOM

<fantasai> emeyer: Could still have CSS scripting? Animations

<fantasai> smfr: Need to think about animations. E.g. SMIL.

<fantasai> ... But majority of SVG use is unscripted.

<AmeliaBR> A rough draft of something like what smfr was discussing: https://svgwg.org/specs/svg-native/

<fantasai> ydaniv: No scripting might make sense, but problem with SVG in <img> is

<fantasai> ... you can't bring any resources from outside

<fantasai> ... And this is a problem for fonts.

<fantasai> ... Still being able to use resources from outside, like fonts

<fantasai> ... that could work.

<fantasai> smfr: There's room for a lot more SVG-CSS integration.

<fantasai> ... Proposals to have CSS variables passed into SVG.

<fantasai> ... Propagating light mode / dark mode

<fantasai> ... We could increase utility of SVG as used now.

Wrapping Up

<fantasai> emeyer: Took 3 points

<fantasai> ... Modularizing

<fantasai> ... Improved test suite

<fantasai> ... Spec that matches reality

<caribou> public-svg-wg@w3.org

<fantasai> emeyer: Thanks everyone who attended, came to speak, came to listen!

<fantasai> ... Hopefully we can take some ideas and move forward into the future.

<kizu> Biggest missing thing: missing people who could work on the spec, I guess

<AmeliaBR> Yep. I definitely agree with Eric's 3 priorities, but we still have to find people with the time & commitment to do the work.

<AmeliaBR> (And I can't volunteer to lead it, sorry. I can maybe work on small tasks like writing tests, especially if there's funding.)