Top-level Anchor tags break out of the SVG namespace

[titoBouzout]

Describe the bug

On this example the red square doesn't render
https://playground.solidjs.com/anonymous/81577cd9-1162-4cf9-b312-9b8197bae11b

The underlying issue is that xmlns is lost in at least two situations:

1. on component change https://playground.solidjs.com/anonymous/133e8b12-defc-4a89-9c42-9cc401b3b602
2. when reactivity takes over and for example a Show toggles

I believe the only way to fix this is to create a context with the value of the xmlns and use it to create any children. This is not about SVG, this will happen with any XML element/future element that needs the xmlns to work correctly.

Your Example Website or App

https://playground.solidjs.com/anonymous/81577cd9-1162-4cf9-b312-9b8197bae11b

Steps to Reproduce the Bug or Issue

Expected behavior

Screenshots or Videos

Platform

Additional context

No response

[ryansolid]

In your specific case it is because <a> is both an SVG tag and HTML tag and we treat it as HTML tag. It's hard to know out of context which one it should be. If I remove the <a> or use any other SVG element it works. Trying to figure this out at runtime seems like a significant overhead given we clone templates, which we don't introspect at the time of cloning (for good reason). I don't know enough about how these namespaces work, but I imagine if we always treated <a> as XML that would be problematic in others.

In general though what we do is decide based on the topmost element if it is an SVG element. If it is we clone it inside and SVG and then extract it from there. That preserves it. We assume that any SVG partial would need to be top-level as if there was a HTML element present it would break it. And there would need to be a nested <svg> element. The best I can think of doing here is changing our heuristic to look at more than the topmost tag and if it finds any SVG element not inside an <svg> it gets SVG treatment. Or rather, if the topmost element is an <a> then we should check its children. That being said this is imperfect if the <a> happens to just be alone in the middle. But that will probably just be a known issue (won't fix).

I have no idea how to support XML in the general sense and that is probably beyond the scope of the project at this point. I'd need to know how to identify it at compile time and how to clone XML partials. I think that we probably should separate the incorrect handling of anchor in SVG from XML in general. I've updated this issue to be the SVG issue which is mostly fixable. And if we want to support XML I suggest probably an enhancement request on DOM Expressions.

[fabiospampinato]

For context in this scenario React creates the <a> element under the SVG namespace, as @titoBouzout expected.

It's a tricky situation, because how does one fix it in general? Let's say I have a component that renders something inside an SVG, this components creates an <a> element, which namespace should be used for it? I think we can't know until it is attached somewhere, because if it's attached right inside an <svg> then we should use the SVG namespace, but maybe it gets rendered inside a <foreignObject> inside an SVG, or some other combination of what's possible. Basically until the node is attached to the DOM it looks like we can't know for sure what namespace to use.

Maybe there's some kind of assumption that can be made to 90% fix this with little downsides.

[titoBouzout]

Basically, whenever you find a xmlns attribute you create any children with that namespace, doesn't matter the tag names nor anything else. The foreingObject, you can think of it as a tag that resets the xmlns, the browser does it alone, nothing special about it.

Following that simple rule, it will make it work for most cases, if not all, without trying to be xml compliant.

If you can keep the xmlns attribute in a context (at compile time), then you can switch the template function based on that context.

For example, in the following snippet, if _el$ has xmlns attribute then children getter is wrapped in a function that switches _$template to use that namespace.

const xmlns = '..' // compile time xmlns value of `_el$`
 _$insert(_el$, _$createComponent(Show, {
      get when() {
        return read();
      },
      get children() {
        return useXMLNSTemplate(xmlns, () => _tmpl$())();
      }
    }), _el$4);

and _$template could do something in the lines of

function _$template(xmlns, content) {
  const template = document.createElementNS(xmlns, "template");
  template.innerHTML = content;
  const element = template.cloneNode(true);

  // should return childNodes instead, this is for demo purposes
  return element.firstChild;
}

const el = _$template(
  "http://www.w3.org/2000/svg",
  `<a href="https://example.org">
        <rect fill="red" x="25" y="25" height="50" width="50" />
      </a>`,
);

This should work with partials, playground https://playground.solidjs.com/anonymous/44630452-7e01-4097-90ce-84a080538c92

The issue @fabiospampinato mentions, about not knowing where you are going to be, that's right and expected, you can mess up like that with regular dom apis too. (ie creating a regular link to append it in a svg tag, it wont work). For example, there's no way to know where this is going to end:

const Link = () => <a href="https://example.org">example.org</a>

If the user does this to use somewhere else const link = Link()

That's why the framework should just handle the xmlns attribute, because the user is aware that they are creating an element out of nowhere, so they will do the following, and will work as expected when the framework respects the xmlns attribute:

const Link = () => <a 
    xmlns= "http://www.w3.org/2000/svg" 
    href="https://example.org"
  >
   example.org
  </a>

[ryansolid]

Hmm.. understanding the proposed solution it would need to be a bit more complicated than that because it can escape the analyzable scope. In our case we only look in the scope of a single JSX block, so like escaping into expressions and going back into JSX resets it. And I believe that is the case for children of components, like <Show> and definitely if people use the callback form. So there are always going to be exceptions.

And the namespace outside of analyzed scope would need to be restored in the future. Like the SVG could continue into a component with a Show in it. At which point the component does not contain an element that has a xmlns attribute. So if we set it like a global context, then we could read it in the component at runtime. But then we'd need to be able to restore it when the <Show> changes to continue propagation from that point. Basically with this sort of approach compilation alone would be insufficient.

This is a significant overhead I think. Mostly in that right now we create the template once and this would push us to allow the templates to be created either way. We'd also need a way of collecting and restoring xlmns at the base of each JSX template even if it didn't contain xmlns itself.

Although as pointed out (and with what I proposed) we currently have no way to know a lone <a> is in the right context otherwise as we can't tell that from compilation. It means currently stuff like @solidjs/router doesn't work properly when people use <A> in SVG. But a local compiler-driven solution also wouldn't handle that either. We'd need a full runtime context solution I described above to handle this completely properly.

This is always going to be tricky without a solution that impacts how every element is created.

<svg>
  <A href="/">
    <Show when={show()} fallback={<rect />}>Some Text</Show>
  </A>
</svg>

So far as I know the overlapping elements are <a>, <style>, <title>, and <script>. So the scope is small. But these elements tend to have text children. So my proposal above doesn't really work for them if they are the top level of their own partial. Most people will only ever run into <a> though being under a conditional.

I tested Svelte and found that they determine it at compile time only. However again the second you make a new component it breaks. For them template expressions aren't the bounds but the whole SFC. But again they have a forced single return so to speak so it isn't saying much. What I'm getting at is that <A> breaks pretty much anywhere there that isn't creating virtual context (like a VDOM). We could perhaps increase the scope of our analysis to cover the whole state it is found in and have Svelte's level of analysis to avoid the common cases. But this remains a hole regardless.

What I'm saying is I think that a pure compiled solution while not perfect is probably preferred because the other solution without taxing all element creation and compiled output is just as edge case. And realistically we are just talking about one element.