`<svelte:element>` behavior differs from using a tag literal

[michael]

Describe the bug

I wanted to create a reproduction of a browser bug in isolation, but then realized the problem only occurs when using <svelte:element this={"h3"}> instead of <h3>.

Could this potentially be due to a Svelte bug?

More context: https://discord.com/channels/457912077277855764/1023340103071965194/threads/1439669856977813656

Reproduction

https://svelte.dev/playground/4ef986b42c134728a92755d152eb86c2?version=5.43.7

Logs

System Info

System:
    OS: macOS 26.1
    CPU: (8) arm64 Apple M2
    Memory: 176.28 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.11.1 - /Users/michael/.nvm/versions/node/v24.11.1/bin/node
    npm: 11.6.2 - /Users/michael/.nvm/versions/node/v24.11.1/bin/npm
  Browsers:
    Chrome: 142.0.7444.162
    Firefox: 145.0
    Safari: 26.1
  npmPackages:
    svelte: ^5.43.4 => 5.39.8

Severity

annoyance

[michael]

Repro without Svelte by Roman (x0k_ds on Discord): StackBlitz

So the issue is that because of svelte's hydration markers we end up with something like this:

<div id="root">
  <!-- comment -->
  <h3 class="centered field empty"></h3>
  [text node]
  <!-- comment -->
  <h3 class="centered field empty"></h3>
  [text node]
  ...
</div>

and the addtional text nodes confuse the browser with regards to addressing the next selectable.

[7nik]

The behavior of the first block is already different in FF and Chrome. Contenteditable is painful and disappointing technology.

Also, Svelte cannot get rid of the anchor markers, which are introduced by any block.

[michael]

Contenteditable is painful and disappointing technology.

It really is. But the good news is, things got MUCH better over the past years. Over the past 15 months or so I was able to build a rich text editor on top of the Input Events Level 2 spec (https://svedit.dev). There's only a small number of workarounds left. So I reported a series of remaining issues at the W3C TPAC meeting, which took place last Thursday in Japan.

The behavior of the first block is already different in FF and Chrome.

This has been tracked and should be fixed by FF.

michael/web-editing#21

Also, Svelte cannot get rid of the anchor markers, which are introduced by any block.

Just for understanding <svelte:element> is considered a block which gets hydration markers around, while the tag literal <h3> does not? Would like to understand what's the difference between the two situations? My mental model of <svelte:element> was that it's equivalent to writing a tag, but with a dynamic tagName, so I wouldn't have expected additional hydration markers.

Aside from that I will bring the issue to attention at the W3C Editing Working group, maybe we can spec a desired behavior for such situations. But I can see that hydration markers that involve additional text nodes could be a general issue with regards to contenteditable.

I wonder how a browser should interpret this situation correctly?

<div id="root" class="editable">
  <!-- hydration marker -->
  <h3 class="centered field empty">[text node]</h3>
  [text node]
  <!-- hydration marker -->
  <h3 class="centered field empty">[text node]</h3>
  [text node]
  ...
</div>

There's a rule (not sure if intentional) that only elements that have a non-zero height and width, can receive a cursor position. So in the above example the browser would need to ignore the cursor positions inside .editable (as they have no dimensions), but recognize the cursor positions inside the empty .field elements, but only because they have a placeholder (which gives the element cursor-addressable space. Alternatively, one could add an additional <br> (this a common trick to make elements cursor-addressable, however there are other issues related to a having a br in combination with placeholders - see michael/web-editing#5).

In general for hydration markers, could maybe the format be changed to only using comment nodes like <!--start--><h3></h3><!--end--> so no unintentional text nodes are created by Svelte? This would make sure Svelte doesn't change the behavior of contenteditable.

[7nik]

<svelte:element this={undefined}>not rendered</svelte:element>

is a valid case that renders nothing, and thus you need a marker when the element is inserted.

Also, in this example the containers have identical HTML (including comments) but different behavior, which makes me think this is a browser's bug.

[michael]

Sorry my bad, I overlooked that hydration markers are added in the first .editable as well.

Seems they really share exactly the same DOM structure in the end, only the construction seems to differ. May indeed by a browser bug then. Interestingly both Chrome and Safari have that problem, so maybe a bug from pre-Blink times.

[7nik]

Sorry my bad, I overlooked that hydration markers are added in the first .editable as well.

No, I added #if to insert comments and make HTML identical.

[michael]

Ah got it.

But that doesn't change the conclusion: One way to use the browser's DOM API's leads to expected behavior (what Svelte runs for {#if true}<h3 class="centered field empty" placeholder="Hello"></h3>{/if}) while another way leads to unexpected behavior (what Svelte runs for <svelte:element this={'h3'}).

Even if the markup is identical, there must be something different in the document's DOM state in the end, that causes the different behavior of the caret. And it's not the existence or non-existence of comments or additional empty text nodes as your last example demonstrates.