How do slots work in light DOM components?

[MukundLadani]

WebJs components render light DOM by default. How does slotting work there, since native <slot> is a shadow DOM feature?

Is there full API parity with shadow DOM slots (named slots, fallback content, slot assignment)?

[vivek7405]

<slot> works exactly the same in light DOM as it does in shadow DOM, and there is deliberate API parity between the two. You write the same template, and moving a component between modes never requires a rewrite.

Native <slot> is a shadow-DOM primitive, so in light DOM WebJs implements slotting itself, but it does so to spec rather than approximating it. Everything you'd expect from shadow slots is there:

• Named slots and the default (unnamed) slot that catches leftover children, text, and comments
• Fallback content, the slot's own inner markup shown when nothing is assigned
• First-wins resolution and dynamic name=${...}

class Panel extends WebComponent({}) {
  render() {
    return html`
      <header><slot name="header"></slot></header>
      <main><slot></slot></main>
      <footer><slot name="footer">no actions</slot></footer>`;
  }
}
Panel.register('my-panel');

<my-panel>
  <h2 slot="header">Title</h2>
  <p>Body goes in the default slot.</p>
</my-panel>

The DOM API mirrors shadow slots too, so imperative code ports without changes: assignedNodes / assignedElements (including { flatten: true }), element.assignedSlot, and the slotchange event all behave the same.

On the SSR question, both modes render slotted content on the server, so it's there with no JS. Light DOM projects the assigned children into the slot at SSR (you'll see a data-webjs-light marker in the output), and shadow DOM uses Declarative Shadow DOM. Either way the first paint is complete HTML.

The one thing that is genuinely shadow-only is the ::slotted() CSS selector, since it depends on the shadow boundary. In light DOM you style slotted content with normal selectors (or Tailwind on the children directly), because there is no boundary in the way. That is the only parity gap, and it's a consequence of light DOM having no encapsulation by design rather than a missing feature.