Comment by spankalee
6 hours ago
How would you solve that? To this day I've never seen a workable proposal.
Slots need to have a host element to select slotted nodes from. ShadowRoot provides that host. Everyone who I've seen say that it's easy comes up with an ambiguous system that doesn't work in many cases and could never be standardized.
Which is a common problem with most "web components suck" takes - they have no sympathy for standards developers or the difficulty of the problem and somehow assume the spec people are dumb or evil, and they don't do the work to show how something could realistically be better.
I don't think that standards did anything wrong or incompetent, but with hindsight considering all the complexities they bring i am hot sure they have been worth it
> How would you solve that? To this day I've never seen a workable proposal.
Stencil.js[0] has a working "proposal" or workaround. Not sure if it is good or bad but at least it seems to work. When you ask users of an API how it could be better they should not be responsible for the implementation. If it can't be done so it is better to not do it in place of having a half working solution that most people decide to not use because it does not work for their use cases.
> they have no sympathy for standards developers or the difficulty of the problem
The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user. All the standards developers I talked think shadowDOM is great and people that don't like it are holding it wrong.
0. https://stenciljs.com/docs/templating-jsx#slots
Stencil's is _not_ a workable platform solution. Stencil is emulating something close to slots _above_ the DOM. Stencil knows the host tree form Stencil's own component definitions, then it flattens before it gets to the DOM. This is basically just what React and every other framework does, just copying the browsers terminology. It's not compatible with anything but Stencil.
In the real DOM you need to know which element from project _from_. The <slot> itself is only half the connection. In a light-DOM only document full of <slot>s you won't know which elements to project where.
> The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user.
This could be slightly true, but the statement also misunderstands the role and priorities of standards. When adding new capabilities to first priority is to make something possible at all, and coherent with the rest of the platform. Making a sugary high-level API is often left to libraries at first, and is exactly what libraries like Lit are.
I'm not GP, but I would love to understand this issue in more detail. Do you happen to have a good link for me to read about what has been tried and why it failed?
Perhaps it's a naive solution, but I would imagine that much of that could be solved through deferring to component hierarchy and enabling a way to assign things more specifically when defining the components in the CustomElementRegistry. I recognize your username and I realize that you have spent a lot of time thinking about these problems, so I would really appreciate whatever insight you have to offer. Thanks!