custom-elements-manifest
custom-elements-manifest copied to clipboard
allowed elements for slots
How would a developer provide this information?
Is there a way to fully require this at runtime? The listing would be more of a suggestion, right? In this way maybe expectedChildren
might be more correct? Accepting selector strings, or base classes would be very interesting.
Maybe there's room for riffing on the attribute syntax:
* @attr {Boolean} disabled - This jsdoc tag documents an attribute.
Here you apply a type to the attribute, it would be interesting to be able to add a element type and/or tag name in a form like:
* @slot {Button | my-button} submit - the custom button used for the "submit" action interface.
Fits in with the feeling behind this tweet: https://twitter.com/UXtechnologist/status/1408438674702929922
Question to my colleagues who work on #designsystems: How are you dealing with the fact that web components can accept any other components as children? Our design tools don't seem to encourage defining components that are containers for a multitude of things. Lost potential? -https://twitter.com/UXtechnologist
How would a developer provide this information?
@thepassle for our purposes we would use a custom JSDocs Tags with Stencil.
/**
* @slot tabs - Tab bodies
* @slotChildren tabs: tab-items
*/
Is there a way to fully require this at runtime? The listing would be more of a suggestion, right? In this way maybe expectedChildren might be more correct? Accepting selector strings, or base classes would be very interesting.
This is a suggestion in the same way that only putting a td
in tr
is a suggestion. Obviously you can structure it differently, but it won't do what you want.
The HTML spec is litered with these kinds of things:
-
dl
,dd
, anddt
-
details
andsummary
-
table
etc.
Here you apply a type to the attribute, it would be interesting to be able to add a element type and/or tag name
@Westbrook this seems a little bit overly complex having both the selector and type information
I think these types of discussions should be had on an issue, and not in a PR. If someone wants to open an issue for this. (the HTML spec has the concept of "content models" btw: https://html.spec.whatwg.org/multipage/dom.html#content-models)
There is an issue: #46
There is an issue: #46
Thanks. I didn't notice that linked.