Extend the slotting algorithm so that a slot can select an element which doesn't have slot attribute.

[hayatoito]

I am afraid that component users would complain when they find that shadow host's children should always have a slot attribute, after shipping v1.

I don't have an intention to include this feature in v1. Let me file an issue here with v2 label, so that users can know that we are aware of this concern.

[rniwa]

You mean adding a declarative way to do this? Once we have an imperative API, authors can do whatever they want, right?

[hayatoito]

I don't have any concrete plan. I just wanted users to know what we are thinking, like your comment.
When we hear complaint from users, we can point this issue's URL to users. That would make users feel comfortable.

[annevk]

Is this issue still needed?

[rniwa]

Yes, this issue about being able to select elements based on other criteria like element names slated for v2. I think we should address this by imperative API.

[hayatoito]

Yes, I think this issue is important because we can remove "slot" attribute from markup.

It makes sense to keep this issue open, though I guess we do not start to work on this issue soon. This is not easy.

[annevk]

Didn't we have an issue for an imperative API that we also closed because of a lack of a concrete proposal? I'm not sure that we need issues for ideas.

[hayatoito]

That's #60.

[annevk]

Right, let's just mark this as a duplicate.

[hayatoito]

However, the imperative API is not the only way to resolve this issue, I think.

[tomalec]

We do have created many custom elements (with shadow DOM v0) that acts as a containers for any content. It would be great if we could be able to achieve same functionality with v2, and to be able to do declaratively something like:

<my-fancy-container> <!-- , my-app-layout or any other element that should consume variaty of different elements -->
  <h1>Goes to `slot name="header"`</h1>
  <div>Any</div>
  <span>other</span>
  <p>element will be distributed where `slot`(?) or any other replacement for `content` without `select` attribute is</p>
</my-fancy-container>

With v0 we were able to to it simply with:

<!-- shadow root -->
<div class="makeContainerLookFancy">
   <div class="addUnicornToTheHeader"><content select="h1"></content></div>
   <content></content>
</div>

Personally I think it's not a duplicate of imperative API, as it would be great to be able to do something that simple declarative way.

[annevk]

My main point was that this is just an idea. Without a concrete proposal, I don't think an issue is warranted.

[tomalec]

Ok, got it.

And probably something like below introduces same performance and lifecycle issues, like content select from v0, doesn't it?

---

Input
NODE, a node
Output
(nullable) SLOT, a slot to which NODE is assigned.

1. If the parent node of NODE is a shadow host:
   1. Let TREE be the shadow tree that the parent node of NODE hosts
   2. Let NAME be the value of the slot attribute of NODE
   3. If NAME is missing:
      1. Let SLOT be a default slot for TREE if it exists, Otherwise, null
   4. If NAME is the empty string:
      1. Let SLOT be the first slot which select attribute matches NODE, If there is none null
   5. Otherwise:
      1. Let SLOT be the most preceding slot in TREE whose slot name is NAME if it exists. Otherwise null.
2. Otherwise:
   1. Let SLOT be null

---

However with such algorithm, we will be able to specify that some nodes are allowed to be distributed, without awareness of shadow DOM structure (slot name), keeping the fully efficient slot selector.

[annevk]

Yeah, that has the same problem.

[rniwa]

I don't think using CSS selector is the way to go here. That would have the same problem where if you have an instance of custom element A that gets slotted to S, then an instance of a subclass of A would not be slotted the same way. This was a big problem for Polymer and Component Kitchen, and that's why many components relied on explicit classes and other attributes to slot elements.

I think selecting elements based on interface would be a better alternative. That is, instead of selecting an element based on DOM state, we select based on the [[Prototype]] internal slot. This allows every subclass of an element slotted to S would also be slotted.

More, concretely, you could imagine adding methods on HTMLSlotElement to specify a list of element interfaces to assign to the slot. e.g. slot.addSelectedElement(HTMLSummaryElement).

[hayatoito]

Let me close this since we do not have any clear idea to achieve this.

[WalterWeidner]

@rniwa you also have the case where you don't want subclasses to be slotted into where a base is allowed (which seems like it would be more common).