Should native elements use slots?

[LeaVerou]

This comes up periodically (what reminded me today was whatwg/html#6636 (comment) but this is just one instance of many) and it would be good to have definitive guidance.

Slots are an excellent mechanism for HTML elements to make simple things easy and complex things possible. The pattern is that the component includes UI for certain things, but wraps it in a <slot> so that authors can slot their own UI and replace that part of the component's UI. Since these can be nested, authors can override UI at various levels of granularity.

Native HTML elements need this for exactly the same reasons as web components. However, so far the web platform has refrained for making this functionality available to them, as there is a widespread idea that slots should perhaps be reserved to authorland components, just like parts (which is another discussion…).

So, when this need arises in a native element, we generally auto-slot by element name, and if no suitable element type exists, we invent a brand new one. An example is <summary> where if it's not present the <details> element will generate one. Perhaps <selectedcontent> is another example.

Now, I'm not saying that <summary> was a mistake and it should have been <div slot="summary">. Since it is meant to be an interactive element, this would have likely been the right call anyway, otherwise the interactive element would have needed to be a shadow DOM wrapper. But this is not always the case, and because there is no established pattern for how native elements should solve these use cases (besides inventing new HTML elements, which is a very high bar), the result is often to do nothing. But customization of the UI of native elements is a pain point that always comes up at the top in every State of HTML survey and not everything can be dealt with CSS and pseudo-elements.

I could be missing something, but it seems to me that there is no benefit to having two different mechanisms for slotting, one for native elements and one for custom elements. It does not seem to introduce any ambiguity, since slots are always direct children. Both mechanisms are useful to both and there is a definite learnability benefit to not having distinct mental models for the same concept. Auto-slotting certain element types is definitely better when it comes naturally (for WC as well!), but slots are great for when it doesn't.

If there is TAG consensus on this, it would be helpful to document this guidance, so that it can be referenced in such discussions.

[jyasskin]

I do intuitively like the idea to have a single mechanism for this, but I see that @zcorpan doesn't like the idea of using slot for native elements: whatwg/html#6636 (comment). What's likely to go wrong if we take @LeaVerou's suggestion?

[annevk]

You can emulate built-in element behavior already with imperative slotting.

But I also quite firmly believe we don't want to expose the implementation details of built-in elements. Having some flexibility there in how they are implemented has been a good thing.

[LeaVerou]

You can emulate built-in element behavior already with imperative slotting.

Yes, the need is not very pressing there, though it would be a nice QoL improvement to have a declarative way to do this, especially since it's currently nontrivial to do well.

But I also quite firmly believe we don't want to expose the implementation details of built-in elements. Having some flexibility there in how they are implemented has been a good thing.

I imagine built-in elements will not use slots as extensively as custom elements, both in terms of quantity, and breadth. I expect their slots will likely be smaller and lower down the tree, possibly only for icons or text at first, or to insert content in certain places (e.g. add additional controls to a video player).

But having the ability to use slots can come in useful, and I'm not sure what's the rationale against it. It's not like built-ins will immediately get slots once the TAG says they can, just that it will be a design choice that is now within reach for them. We are already standardizing pseudo-elements and internal structure of several built-ins because UI customization is incredibly important to authors.

Perhaps the guidance can be that any slots exposed by built-ins need to be standardized if not vendor prefixed. That way, UAs won't just go rogue exposing whatever, if that's the worry.

[lukewarlow]

It's worth looking into the history of customisable select a bit too, that was at one point using slots among other things but was deliberately changed away from that based on feedback. I believe from Domenic but also potentially others.

I think conceptually using slots is a nice idea and I personally did like the original design for selectlist but at the same time it's also potentially a feature that the host elements and custom elements don't overlap in syntax in this way.