Remove foreign namespace support

[benmccann]

Describe the problem

As far as I'm aware, only Svelte Native uses foreign namespace support. However, they can't use it in Svelte 5. The way they implement support is by overriding the DOM creation methods. However, we don't use those same methods anymore and so their support is going to break. The solution to that won't involve using foreign namespace

Describe the proposed solution

Remove foreign namespace
Add custom renderer API in a future 5.x release

Importance

nice to have

[trueadm]

I think foreign has more uses other than SN though? At least someone mentioned that a few months back on Discord. Maybe @dummdidumm can remember more.

[benmccann]

I couldn't find any others on GitHub: https://github.com/search?q=namespace+foreign+path%3Asvelte.config.js&type=code

Even if there were other uses, I imagine they would be similarly broken and would also require custom rendering or the old style dom rendering that they could override

[dummdidumm]

IMO It doesn't make sense to remove it only to re-add it in 5.x, when we introduce the API for custom renderers. It's theoretically sensible to use outside of Svelte Native, for example to get rid of certain warnings.

[trueadm]

IMO It doesn't make sense to remove it only to re-add it in 5.x, when we introduce the API for custom renderers. It's theoretically sensible to use outside of Svelte Native, for example to get rid of certain warnings.

I don't we'd need the namespace if we provide a custom renderer? The custom renderer would be a compiler option for the entire project, not an option per component. This is how it's done with Solid.

[dummdidumm]

Mhm true, AFAIK there's not a real use case outside custom renderers for the foreign namespace.
That said, someone could create a custom renderer for the DOM (AFAIK some people said the template approach has certain problems for them, so a document.createElement etc approach would suit them better), and in that case they probably would want the a11y warnings still but in foreign namespace they are turned off. But since that's so rare, it's maybe ok to always turn off a11y when a custom renderer is provided?

[Conduitry]

Or, alternatively, if we don't want to make that decision for people, if someone is already going so far off the path that they're writing a custom renderer, they can probably also just pass a warning filter callback.

[dummdidumm]

...or make the default for the filter !warning.code.startsWith("a11y") if a custom renderer is given? That way they can adjust it if they want to.
I think people using custom renderers for targets outside the DOM where a11y warnings don't make sense are in the majority compares to people using custom renderers for the DOM

[trueadm]

Mhm true, AFAIK there's not a real use case outside custom renderers for the foreign namespace. That said, someone could create a custom renderer for the DOM (AFAIK some people said the template approach has certain problems for them, so a document.createElement etc approach would suit them better), and in that case they probably would want the a11y warnings still but in foreign namespace they are turned off. But since that's so rare, it's maybe ok to always turn off a11y when a custom renderer is provided?

I actually imagined it to be implemented as a compiler thing only. i.e. when customRenderer is provided in the config to the compiler, it's passed a reference to the custom renderer import. Then when we create the templates etc in the compiler we instead just create element by element and reference their import:

{
  customRenderer: 'package/renderer'
}

import { createElement, insertBefore } from 'package/renderer';

function MyApp(anchor) {
 const container = createElement('div', attributes, ... );
  // …
 insertBefore(anchor, container);
}

[Rich-Harris]

So what's the verdict — are we removing it or not?

[trueadm]

I don’t see any reason to keep it.