Re: [w3c/webcomponents] [idea] Allow custom element naming on a per-shadow-root basis. (#488)

I find the suggested mechanics of this proposal are weird but I still agree with namespacing elements to shadow doms, it's one of the reasons I've had little interest in the Custom Elements part of webcomponents and have really only looked at using Shadow DOM directly with divs. My only real interest in Custom Elements is the life-cycle events (which if [this issue](https://github.com/whatwg/dom/issues/533) happens then that sole reason to even consider using custom elements vanishes).

I'd suggest a simpler proposal that guarantees that when an element is created it's already associated with a Shadow DOM for example instead of this auto-magically associating itself when attached to a shadow DOM like currently proposed:

```js
const foo = new FooBarElement()
shadowRoot.customElements.define('foo-bar', FooBarElement)
// foo magically adopts the semantics within shadowRoot
shadowRoot.appendChild(foo)
```

I'd instead just propose that a shadow root must be provided when creating the element (and that `new CustomElement` only remains for backwards compatibility with global `customElements`) e.g.:

```js
shadowRoot.customElements.define('foo-bar', FooBarElement)

// Some options

// 1. Just have a shadowRoot as optional second argument to createElement
// although I think this might be backwards incompatible?
const foo = document.createElement('foo-bar', shadowRoot)

// 2. Just have createElement be a method of shadowRoot, definitely 
// compatible and pretty simple to use really
const foo = shadowRoot.createElement('foo-bar')

// 3. Method on HTMLElement itself, possibly useful for creating
// elements from the constructor itself
const foo = FooBarElement.create(shadowRoot)
```

---

Now given something like this we'd need to consider what sort've surface area it would have. These are the things I can think of that would need changes:

- Assignment to `.innerHTML` would need to during the fragment creation stage store the current ShadowRoot of the current element and lookup element names in that ShadowRoot before checking `window`
- Similarly we'd ideally have a similar thing for `importNode` so we clone nodes from templates as if they were already associated with the current ShadowRoot
- CSS rules would probably need a need some additional block-thing (like `@scoped { }`) or something like that would allow adding rules to shadow root defined elements (for example `@scoped { local-registered-name { color: red; } }`)

Overall I don't think the necessary surface area of changes is likely to be huge, and it wouldn't need to have anything that breaks current semantics in order to be easy to use and safe for distributing components.

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