Re: [w3ctag/design-reviews] Declarative Shadow DOM (#494)

With the proposal to [use an idref to an existing template](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#instead-of-inline-contents-use-an-idref-to-an-existing-template), it seems like this would address some of the concerns we had about this feature pointing to a missing "declarative custom element" feature.

@justinfagnani has pointed out to me that reusable elements _are_ a form of compression, although it's true that compression is also a form of compression!

Regarding the technical issues: 

- It seems that reasonable answers could be found to the question of what happens if `<template>` is defined after the `<custom-element>` (particularly since this would be poor practice, like having two `<template shadowroot>`s inside a single host element.
- Regarding IDREFs piercing shadow boundaries, this seems like a question that badly needs a solution. We have been working on this for AOM, with one strawman proposal being to [introduce a `globalid` attribute](https://github.com/whatwg/html/issues/5401#issuecomment-629982041) which can be used for shadow-piercing references (but not used in a `getElementById()` lookup). This would also address your comment about AOM IDL attributes in the "Other unanswered questions" setction.
- The question about "how often this would be helpful" seems like one that is worth answering in earnest - how often is shadow DOM contents strictly boilerplate, with stateful content slotted in, vs encapsulating state as well as structure?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/494#issuecomment-634333562