[w3c/webcomponents] Named slots and the slot attribute requirement (#726)

So after building quite a few components and reading through #343, I was wondering if you could clarify something for me:

Given a complex shadowDOM template with multiple named-slot locations I am curious why an element selector cannot be used if it is only focused on the children of the element involved. In-house we are trying to develop multiple elements that have specific styling inherent to them. Some of these elements have specified child elements that can be used which are not dissimilar to a `<tr>` in a `<table>` element (the `<tr>` does not really have a use outside a `<table>`). 

For the developers that use our elements, there is now required boilerplate to place that child element in the named slot due to the required `slot="someSlotName"`. This can be overcome by the child element generating its own `slot="someSlotName"` attribute but it cannot not do so during its own construction, only during the connectedCallback. This creates quite a bit of unnecessary churn during the initial connection of an element because it starts unslotted then gets moved/projected into place (the most noticeable slowdown happens when using polyfills like Polymer).

Staying within the context of only selecting from the element children and without pretending to know the complexity involved, I am curious if the v0 `selector="someElementType"`  or the more preferred method @rniwa [had mentioned about interface selection](https://github.com/w3c/webcomponents/issues/343) . Maybe something like

```html
<slot interface="SomeElement" />
```

This would allow certain element types to be slotted according to the design of the shadow template instead of the boilderplate attribute.....kinda like `<table>` knows where to place a `<thead>` element without `<thead slot="head">`.

Thoughts?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/726