Re: [WICG/webcomponents] Proposal: Composable shadow roots, for extending builtins and more (Issue #1108)

justinfagnani left a comment (WICG/webcomponents#1108)

@LeaVerou I don't think there's much complexity difference between re-using `<slot>` and making a new element like `<shadow>`. I think the complexities arise from answering the questions that naturally come up around how to compose to different shadow roots this way - things like the inner shadow root having slots itself that need to be filled.

I think one reason that a new element is desirable for this type of feature is just that the semantics are different from slots. it can be made to work, of course, but I think the meaning of what happens changes enough to make it more clear to differentiate by tag name rather than attribute value.

Especially with re-projection into the inner shadow root. As soon as you have an inner shadow root there's that possibility that the inner shadow root has slots, and then you need a fill to assign to them.

```html
#shadow
  <x-foo>
    <slot type="super">
      <div>abc</div>
      <slot name="bar" slot="bar"></slot>
    </slot>
  </x-foo>
```

Here we want the `<div>` to project into the unnamed slot in the inner shadow root, and the "bar" slot to re-project into the "bar" slot in the inner shadow root, but this looks like fallback content for the slot in the outer shadow root that would slot into `<x-foo>` instead.

@rniwa one question I've had about the additional complexity is how it differs from the shadow root nesting that we already have. One way to think about `<shadow>` is that it's just a `display: contents` element that has a shadow root (which just happens to be the older shadow root) attached to it. Unless I'm missing something, it seems like all event-path questions should have the same answer as if you had just done this in userland with today's available APIs.

```html
<x-host>
  #shadow
    <h1>Outer Content</h1>
    <x-shadow>
      #shadow
        <div><slot></slot></div>
      <button>Slotted Button</button>
    </x-shadow>
```

Today if `<x-shadow>` is a custom element with a shadow root, click events from the `<button>` will have a path of button, slot, div, x-shadow, x-host. If we replace `<x-shadow>` with `<shadow>` and the shadow root with an older shadow root, isn't the event path the same? Is there another scenario where paths are different from existing nesting?

This makes me wonder if this system could be polyfilled in userland by overriding `attachShadow()` so that it can be called multiple times. Each additional time that it's called it empties the current shadow root into a fragment and stores it, then when an `<x-shadow>` is connected it retrieves the fragment and moves it into its own shadow root. I think everything else should fall out of existing shadow root behavior. Except for customized built-ins, of course.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1108#issuecomment-3097664588
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1108/3097664588@github.com>