– DRAFT –
SVG Interoperability

Karl: The SVG is chartered to _maintain_ the spec
… the spec currently has a lot of ambiguities
… tests results shows interop issues
… sometimes implementation, sometimes spec
… there's a bit list of open issues
… we have new editors and aim at republishing
… huge work needed for interop testing

[showing the tests that are in WPT]

<ntim> wpt.fyi/svg

Karl: some more tests in blink repo, some others (maybe similar) in webkit repo
… we need to figure out how to organize testing from now on
… people contribute, from Webkit, Edge, Igalia...
… we want to keep the fire going

ydaniv: there was a session in Sevilla about adding more features
… there was a session organized by Igalia in spring 2025
… actions items were on interop
… suggestion to pay someone to convert old tests to get a new test suite
… 2nd action item about updating the spec

Karl: I don't think there's desire from browser vendors to implement new features
… we're chartered to clarify/fix the spec

Dirk: the charter says we should only maintain the spec. Browser implementers create WPT tests and open issues when they find problems
… testing the interop is the major focus of this charter

Neha: big supporter of SVG
… in India we try to provide books in epub formats to children in school
… and images in SVG
… for kids with disabilities. SVG accessibility with labels is incredible

Karl: please join!

Neha: I'll try to help

foolip: interested in the testing effort in WPT, what kind of approach are you taking?

Karl: I'd like to go through all the tests. It's hard to figure out where it's in the spec

foolip: there's a triage mode
… if you want to have a triage queue, you can associate bugs to tests

<ntim> ... you can use the bugs filter to get a burndown list

<ntim> ... you can search by chrome only failures

<ntim> (chrome:fail safari:pass firefox:pass)

<ntim> you can filter by tests associated with a bug or not

<Zakim> ydaniv, you wanted to react to foolip

ydaniv: maybe we can assess where we are using the Interop project

<ntim> ydaniv: i tried to suggest SVG as a focus area to Interop 2025, but we could do an investigation some time

Karl: if we demonstrate in the WG that we do the work, the Interop project might be interested

<ntim> ntim: we shouldn't use the interop project as a forcing function for spec work

Mike: Do we have a list of breaking sites or something outside of the test suite

Karl: in my job (webcompat) we sometimes have reports of broken websites
… (example of the unimplemented unit issue)

<ntim> WebKit didn't understand rem and other relative units, and we just implemented it because it fixed a site

Karl: so there are sites that suffer from lack of interoperability

<ntim> compat is a forcing function for webkit to handle things

<foolip> https://github.com/web-platform-tests/wpt.fyi/blob/main/api/query/README.md#triaged is the docs for the wpt.fyi feature to filter by triage status. The feature to link bugs is the "Triage Mode" toggle to the top right.

karlcow: webkit tries to prioritize things that impact sites

karlcow: if wix has a broken site because of svg, that will be higher priority than a vague project around SVG

miketaylr: that's probably how most browsers do this. users first

<foolip> Example for untriaged Chrome failures: https://wpt.fyi/results/svg?label=master&label=experimental&aligned&q=chrome%3Afail%20and%20none%28triaged%3Achrome%29

kbabbitt: I was looking at the list of failures, it's a lot. ydaniv, I want to ask, how did you submit the proposal for Interop project? was it bits and pieces or just the whole of SVG?

ydaniv: first one was SVG 1.1, second was an investigation effort.

now that the group is back again, we should try to get together again

kbabbitt: Is SVG potentially too big? should we pick one or two submodules?

dirk: I am a member of the working group, it is up to the browser vendors to decide the priorities

sid: I'm also from MS. One of the modules we feel strongly about is SVG link params

foolip: a small proposal is more likely to get into the interop project than a big one
… if there's evidence of concrete bugs, it's easier to get in interop than "all of SVG"

foolip: i like the interop project, but interop should happen everywhere, in all groups. Interop project should really be the last resort. Getting rejected doesn't mean no progress

ydaniv: i want to echo something from leaverou: browser vendors kept saying that there was not enough interest from web devs to work on SVG. State of HTML proved otherwise. There's definitely interest.

caribou: it's all of SVG. i recall that SVG in maps was a big use case

ydaniv: i think filters was a big issue. We probably need more thought if we want to get more specific

Karl: the interop work should be happening in the WG

karlcow: W3C is where we create the technology. The interoperability should be happening in the working group, because it's the way the tech works. The Interop project should really focus on small details that differ across browsers. We should not use the Interop project to solve all of SVG, that is the job of the WG.

<satakagi> I did the breakout for the distributed architecture using SVG for maps.

<satakagi> However, that's about features for newer SVG, like SVG 2, so it's not relevant to this session.

foolip: I just checked the SVG use counters, it's around 60%. It's used a ton on the web, there's not a lot of bugs, presumably because they use editors that use only the interoperable parts.

foolip: only way to run into issues is to write them yourself by hand

foolip: we should see a path to adoption to do the work

karlcow: yes. in addition to SVG editors, there are graphic libraries that do the link between SVG in canvas. Most of the bugs I've identified in webkit, were bugs where SVG was generated by JS which was setting width/height/etc.

ydaniv: My company is an authoring tool, we allow uploading SVGs from users, we inline it because we want to allow the user to repaint it/change it/etc. We allow any SVG you want, and you can use them as mask/clip-path/etc... We use almost every single way that you can incorporate SVG and we encounter a lot of issues. It's not just when you write SVGs by hand, it's when you combine with other CSS features, etc.

filters is one of the big issues. When we got interop on masks, things got better

karlcow: things can be handled differently depending on the platform. WebKit uses CoreGraphics to handle gradients for instance, so sometimes there are dependencies, and it's harder to convince.

foolip: It's 60% of page loads

krit: Yes most of the content is created with editors, that said, we still find issues despite that.

krit: editors really try hard to create content that is interoperable

to avoid putting the burden on creators

ydaniv: A huge pain point of SVG is security. One of the goals should be improving security.

karlcow: security inside SVG?

<foolip> https://en.wikipedia.org/wiki/Billion_laughs_attack

ydaniv: could we remove legacy tags that allows billions laughs attacks?

foolip: this is a problem with XML not SVG

foolip: browsers have mitigations or crashes?

ydaniv: they come to me and ask for help, and all the uploads are sent through santization

foolip: you can parse SVG through an HTML parser which does not have this problem

karlcow: Do you use copy paste for SVG? being able to copy an SVG and paste it elsewhere

karlcow: SVG in clipboard is a security problem

<foolip> This is https://webstatus.dev/features/clipboard-svg

<foolip> Without knowing any details, I'll assume that the security problems were solved since it's shipped now.

ydaniv: if SVG is used, it's usually added by a component that embeds it.

karlcow: chrome implements SVG in clipboard

ydaniv: was possibly implemented as a paste option

karlcow: please feel free to open bugs on spec or browsers

krit (Dirk) is the chair of the WG

Please join! we need more people