Issue

To do conditional wrappers, one has to repeat code.

Example:

<script>
    let first = 'first';
    let second = 'second';
    let third = 'third';
</script>

{#if wrap}
    <div>
        <div>
            <span>{first}</span>
            <span>{second}</span>
            <span>{third}</span>
        </div>
    </div>
{:else}
    <span>{first}</span>
    <span>{second}</span>
    <span>{third}</span>
{/if}

But this would also be true for small pieces of code being repeated often and for which a full custom component would not be the most practical solution.

Proposal

<script>
    let first = 'first';
    let second = 'second';
    let third = 'third';
</script>

{#fragment block}
    <span>{first}</span>
    <span>{second}</span>
    <span>{third}</span>
{/fragment}

{#if wrap}
    <div>
        <div>
            {#include block}
        </div>
    </div>
{:else}
    {#include block}
{/if}

A fragment should also support scoping, and therefore could be defined inside a {#each} block and use the local bindings. It would be reused inside that block and only inside that block.

Concerns

A fragment definition disrupts with the usual semantics: it defines a piece of content which is not displayed where it's defined.

Also the design scope should be clear, simple and straightforward: custom components should be the solution as much as possible!

Alternatives

Use a custom component, but it would be nice to have one bound to a set of input properties (because otherwise it's not resilient to have to repeat the values all the time). Otherwise, right now, since this component sole purpose would be to serve as a fragment, the context feature could be used, but still not the most practical.

However, I don't know how it would fit with local template variables (i.e. in {#each}) anyways...

Issue

For now, slots can be filled only by a DOM element, e.g.: <h1 slot='slotname'>any content</h1>.

This can enter in conflicts with the design of some CSS frameworks (with a very specific expected DOM structure) and preventing the reuse of generic components then.

It is also surprising this can't be added on custom elements...

Besides all that, using an attribute for that purpose could potentially enter in conflict in case that attribute would be relevant on an element, primary or custom.

Proposal

Introduce a {#slot slotname}{/slot} statement, which would solve all issues: allows text nodes only, allows list of elements, allows custom components.

It's also very concise and logical and there's already the code base to support such statements (it's like if, each and so on).