Instruct compiler to treat designated <slot>s as regular Elements

[dane-skipper]

Describe the problem

I've been using Svelte in a project in the following ways:

• Rendering the application to a shadowRoot, as the application is a widget that is included in other websites, and we value style encapsulation
• Leveraging the typical Svelte-defined behavior of <slot> throughout the application

However, I've recently run into a problem with this setup in an attempt to integrate a needed vendor SDK. Roughly, the vendor SDK exposes an init function that takes as an argument a targetId. The init function then searches over the Light DOM (presumably via a document.getElementById call) for the element designated by targetId and then appends as a child to that element an iframe.
A toy reproduction of the situation can be found here.
Since my Svelte application is rendered in the ShadowDOM, such a search proves fruitless.

Unfortunately, I cannot configure the SDK in question to search for the targetId in the Shadow DOM tree under Shadow Root, and because of the style encapsulation needs, I strongly prefer to keep rendering to the shadowRoot. Because of our use of the Svelte-specific behavior of <slot> and other features listed here, and the tepid support of Web Components by the core Svelte team, I strongly prefer not exploring solutions that involve compiling our application as a customElement

Describe the proposed solution

I want to be able to optionally instruct the Svelte compiler to treat a use of <slot> as a regular Element so that I can rely on the default browser behavior of <slot> as defined in the Web Component spec.
Doing so through an attribute flag (named, say, compiler-ignore) seems reasonable, and would be a non-breaking addition to the framework.

<slot compiler-ignore name="slotty"></slot>

The above solution would entirely solve the conundrum that I'm facing. I'll be posting the solution I developed (that is working) as a PR shortly.

Alternatives considered

• style isolation through non-shadow DOM means -- in short, we'd rather not play style-reset-whack-a-mole, and have a pretty bread-and-butter use case for Shadow DOM
• solutions like the one described here don't work for my use case -- because of our rendering our application to a shadowRoot and the use of a vendor SDK with the limitations I described above, I have to be able to define slotted content that is outside the scope of the Svelte compiler as used by our application

Importance

i cannot use svelte without it

[baseballyama]

You can use <svelte:element>

<svelte:element this="slot" name="that-header" />

[dane-skipper]

@baseballyama per the discussion on #8057, I'll change this issue to be specific to adding to the documentation how to use <svelte:element> to effect an HTML slot in a Svelte application