Join GitHub today
Extend the slotting algorithm so that a slot can select an element which doesn't have slot attribute. #343
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.
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.
Ok, got it.
And probably something like below introduces same performance and lifecycle issues, like
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.
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
More, concretely, you could imagine adding methods on