feat(runtime-browser): add support for <svelte:element this="contents">

[dukhevych]

feat(runtime-browser): add support for <svelte:element this="contents"> to render children without wrapper

• Added handling in element block to treat "contents" as no-wrapper rendering
• Added runtime-browser test for this behavior

This enables <svelte:element this="contents"> to render only its children without an extra wrapping element.
This improves markup flexibility and reduces unnecessary DOM nodes in scenarios where a wrapper is not desired.

In issue #15666 discussion, it was suggested using a wrapper component like MaybeTag to achieve similar behavior.
However, this solution eliminates the need for an additional wrapper component altogether by handling this directly in the compiler runtime.
This simplifies usage and improves performance by avoiding extra components and markup.

This change provides a practical, built-in solution for the use case and aligns with idiomatic Svelte patterns.

Before submitting the PR, please make sure you do the following

• Reference an existing issue or RFC if applicable (e.g., Closes #15666)
• Prefix your PR title with feat:, fix:, chore:, or docs:
• Clearly explain the problem this PR solves
• Include a test that fails without this PR but passes with it
• If you changed code in packages/svelte/src, add a changeset with npx changeset
• Run all tests with pnpm test and fix any failures
• Run lint with pnpm lint and fix any issues

[changeset-bot]

🦋 Changeset detected

Latest commit: 32a29d9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@16392

[Rich-Harris]

Thank you but #15666 was closed for a reason. This is an extremely niche requirement that can already be easily solved in userland, and adding a particular string value that behaves differently is confusing, even if we could guarantee that it won't conflict with any future additions to HTML (i.e. <contents>).

FWIW the PR is broken in any case — if you switch from h1 or h2 to contents and back again, the content disappears altogether.

[dukhevych]

@Rich-Harris sounds reasonable.

Initially I just didn't like the default behavior of svelte:element when this is nullish value - removing element with all the content, though we still could have used if for conditional rendering for such cases.

What about adding an additional attribute unwrap for svelte:element that will make it possible when this is nullish value? This won't break it's default behavior and avoids possible issues with future HTML tags collisions.

[Rich-Harris]

avoids possible issues with future HTML tags collisions

What about future HTML attributes?

Every bit of added surface area has a cost — in implementation complexity (extra bytes for everyone if they use the feature or not), test suite bloat (making the feedback loop of working on Svelte slower, no matter what it is you're working on), extra documentation (which users then have to read) and so on. These costs compound over time.

So the bar for adding new stuff to the framework is high, and this feature (really I'd call it an anti-feature) is very far from meeting it.