It would be nice to be able to write a slot without an extra DOM element

[chris-morgan]

Currently, you need a single DOM element to fill a slot. This limits slots’ usefulness in various scenarios.

#1037 and #1713 are about allowing a Svelte component to fill a slot, and I believe there is consensus in v3 that this is desirable and intended. Given that a component does not necessarily render to a single DOM element, this is interesting.

It would also be nice to be able to do this without needing to create a whole new component, or a DOM element. Two strawman syntaxes:

{#slot "foo"}
    …
{/slot}

<div slot="foo" svelte:slot-behaviour="exclude-wrapping-element">
    …
</div>

There may be considerations for Custom Elements, but if it’s sorted out for all Svelte components first then there should be nothing fundamentally new here.

[theSherwood]

This idea really seems to open up the possibility of using a component purely for doing operations on application state while remaining agnostic about how that gets rendered. Seems useful.

[steve-taylor]

Another strawman syntax:

<svelte:array slot="foo">
    …
</svelte:array>

[chris-morgan]

Yet another possible syntax I thought about a few days ago:

<template slot="foo">
    …
</template>

Giving this special meaning to <template> is likely to be controversial.

[steve-taylor]

Out of all these, I like {#slot expression} the most.

[tomblachut]

I vote for element syntax, I find it more consistent than using special block, because slot is standard attribute applied to elements.

There should be a way to declare elements that don't yield DOM Element by themselves but can contain children and affect them. Essentially what component tags do from consumer perspective.

• Angular has <ng-container> that you can apply directives to
• React has <Fragment> very roughly for that
• @chris-morgan I agree that overloading <template> is controversial. Namespacing with svelte: is much better IMO
• @steve-taylor I think <svelte:array> is misleading name for people coming from different backgrounds. Newcommers could think that <svelte:array> must contain elements of the same type for example.

I like <svelte:fragment slot="foo"> as there's already precedent with namespacing special elements.

[CreaturesInUnitards]

Out of all these, I like {#slot expression} the most.

💯 Svelte already has a special block syntax for other purposes. Adding another variant would be perfectly ergonomic and unceremonious.

I vote for element syntax, I find it more consistent than using special block, because slot is standard attribute applied to elements.

This is perfectly sane, of course, but I don't find it to be persuasive.

• element syntax creates the visual impression of further nesting, which block syntax does not.
• in fact, the purpose of this proposal is to wrap a fragment without nesting; block syntax visually reinforces author intent.
• I'm not sure the fact that slot is a standard attribute applied to elements is actually a feature, so much as it is a harmless byproduct. But either way, it would likely be trivial for the block implementation to apply the slot attribute to the top level elements.

[CreaturesInUnitards]

One final point regardless of the syntactic choice. This is the current state of things:

<!-- MyComponent -->
<div>
  <slot name="foo"></slot>
  <slot name="bar"></slot>
</div>

...

<!-- MyApp -->
<p slot="bar">1</p>
<p slot="foo">2</p>
<p slot="bar">3</p>
<p slot="foo">4</p>

...

<!-- results -->
2
4
1
3

...and that's just silly.

[Conduitry]

I suppose I don't have strong opinions about whether multiple things should be able to be inserted into one slot, but given that it's already possible, how is this silly? The component first renders the two foo slots (2 and 4) and then renders the two bar slots (1 and 3).

[pngwn]

As conduitry said, that behaviour is what I would expect.

The only issue with adding block syntax for this is that we then have two ways of passing elements into slots: via an attribute and via a block. Generally the Svelte philosophy has been to have only one way of doing things. This change would not only introduce another way but quite a different other way.

[CreaturesInUnitards]

@Conduitry I suppose "silly" is a bit reductive. I mean to say this enables a fairly gnarly type of indirection in markup that could be lead to some very frustrating pebkac scenarios. Block syntax for multiple unwrapped elements would be intuitive.

[CreaturesInUnitards]

@pngwn I agree wholeheartedly with the one-good-way philosophy where it makes sense. But, like Svelte's class syntactic variants, this calls for 2 ways because we're talking about 2 different problems.

Take class. If I want to specify 2 classes on a single element based on 2 different bools, it's better to use the shorthand class:foo={bool1} class:bar={bool2} than to jam checks for both bools in a single class={ ... }.

In the case of slot, block syntax for a single element would be excessive, but for wrapping multiples it would be the clearest and cleanest. I don't see that as two ways of doing one thing.

[tomblachut]

I've been thinking that block syntax for slots would - if I didn't miss anything - be one of it's kind. if, each & await simply stamp out zero or more elements based on their content, in place. slot block would apply attribute to it's children and moreover would be illegal outside components.

---

I'm not sure the fact that slot is a standard attribute applied to elements is actually a feature, so much as it is a harmless byproduct.

@CreaturesInUnitards just to be sure you understood me correctly, I meant that slot attribute is in HTML spec already. BTW there's bigger chance HTML later introduces grouping element that affects its children than it introduces blocks.

[CreaturesInUnitards]

@tomblachut yeah I get you. For my taste the tradeoffs favor block syntax, but I'm not gonna jump up & down about it :)

I'm confident the maintainers will make a good decision on this; I just wanted to make sure my points were considered. I feel like they're on the table now, so I'm good with whatever happens.