Dynamic creates ambiguous SVG elements in the HTML namespace during client rendering

Describe the bug

When <Dynamic> renders an SVG element whose tag name also exists in HTML, the element is created in the HTML namespace during client-side rendering.

For example, a static <a> inside <svg> is correctly created in the SVG namespace, while <Dynamic component="a"> in the same parent becomes an HTML element.

This creates a CSR/SSR discrepancy:

CSR creates an HTML <a>.
Server-rendered markup is parsed by the browser as an SVG <a>.
Hydration can therefore begin with the correct namespace, while client-only rendering or a later dynamic replacement produces a different DOM structure.

Steps to Reproduce the Bug or Issue

Render an containing both a static and .
Read namespaceURI from both elements.
Observe that the static element uses the SVG namespace while the dynamic element uses the HTML namespace.

The following regression test demonstrates the difference:

  test("creates ambiguous SVG tags in the SVG namespace", () => {
    let svg!: SVGSVGElement;

    createRoot(() => (
      <svg ref={svg}>
        <a id="static" href="#target" />
        <Dynamic component="a" id="dynamic" href="#target" />
      </svg>
    ));

    const staticAnchor = svg.querySelector("#static")!;
    const dynamicAnchor = svg.querySelector("#dynamic")!;

    expect(staticAnchor.namespaceURI).toBe("http://www.w3.org/2000/svg");
    expect(dynamicAnchor.namespaceURI).toBe("http://www.w3.org/2000/svg");
  });

The final assertion currently fails with:

Expected: "http://www.w3.org/2000/svg"
Received: "http://www.w3.org/1999/xhtml"

Expected behavior

<Dynamic component="a"> inside an <svg> should create an element in the SVG namespace, matching:

<svg>
  <a />
</svg>

Client rendering and server-rendered markup should produce elements with the same namespace.

Platform

Solid: next at f051db6
The same tag-set-based creation path is present in Solid 1.9.15
Test environment: Vitest with jsdom
OS: Linux

Additional context

The client runtime determines the namespace only from the tag name:

  SVGElements.has(tagName)
    ? document.createElementNS(Namespaces.svg, tagName)
    : MathMLElements.has(tagName)
      ? document.createElementNS(Namespaces.mathml, tagName)
      : document.createElement(tagName, { is });

Ambiguous SVG tag names such as a, title, script, and style are not included in SVGElements, because the same names also exist in HTML. As a result, always falls back to document.createElement("a"), regardless of its SVG parent.

A possible fix may require propagating the parent namespace to dynamically created intrinsic elements or providing an explicit namespace hint for .

The closest related work I found was ryansolid/dom-expressions#494, which addressed namespace handling for static XML partials but does not appear to cover dynamic intrinsic elements.

fix(web): create ambiguous SVG tags in the SVG namespace in Dynamic c…

Fixed in 3c357fb on next — Dynamic now defers intrinsic element creation until insertion, so ambiguous tags (a/script/style/title) resolve against the actual insertion parent's namespace and SVG elements are created in the SVG namespace. Ships in the next RC.

revert(web): restore eager element creation in Dynamic (#3187 deferral;

Reverted on next in d2b50e9, and re-closing this as an accepted limitation rather than a bug to fix.

The fix that shipped in rc.6 (3c357fb) deferred Dynamic's element creation into a thunk pulled by the consuming insert(), so the live insertion parent could supply the namespace hint. The namespace result was correct, but the mechanism changed render semantics for a primitive the ecosystem builds on: string-component Dynamic stopped being an element at component creation on the client (while still being one under hydration), spread and ref callbacks moved to first insertion — or never ran for content that is not inserted — and for <Dynamic> inside <Portal> the ref write moved into the render phase of the flush, where createTrackedEffect readers never observed it. That broke every Kobalte popper on rc.6 (#3291). It was also partial by construction: content resolved outside an insert() (the children() helper) had no insertion parent and fell back to HTML anyway.

There is no fix for this edge that keeps creation eager. createElementNS needs the namespace at creation, and the parent is not known until insertion; the parser resolves static templates from surrounding markup, and a runtime has no equivalent without either deferring creation or adding API. So the behavior returns to what 1.x had for its whole life: a, script, style and title rendered through Dynamic inside SVG content are created in the HTML namespace. Use a static element for those (<a> inside <svg> in a template resolves correctly), or a small component that returns the static element.

If this becomes a real-world blocker, the acceptable shape would be an explicit, opt-in hint (something like a namespace prop on Dynamic) — a change to what the caller says, not to when the runtime does things.

— Claude via Cursor

refactor(web): unified For hole demote is synchronous in all modes; r…

Navigation Menu

Repository navigation

Dynamic creates ambiguous SVG elements in the HTML namespace during client rendering #3187

Describe the bug

Steps to Reproduce the Bug or Issue

Expected behavior

Platform

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Dynamic creates ambiguous SVG elements in the HTML namespace during client rendering #3187

Description

Describe the bug

Steps to Reproduce the Bug or Issue

Expected behavior

Platform

Additional context

Activity

ryansolid commented on Sep 1, 2026

ryansolid commented on Sep 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions