Re: [w3c/webcomponents] Declarative components proposal (#897)

Declarative custom elements is a topic that's come up a lot over the years, and we have a strawman proposal here: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md I think the current implicit status is that we need to get through Template Instantiation, and then a built-in expression syntax that we could use in HTML, before doing a lot more on declarative custom elements, though maybe we could work on them in parallel and maybe the two proposals would lend each other momentum.

I'm very glad to see more interest and new proposals here, though at this point I personally think we'll need more discussions in issues and meetings before another PR, and don't think we should have two proposals in the proposals folder. A new proposal PR right now is likely to have deeps discussion on specifics in review comments that should be had in separate issues.

But a few things on this proposal that I think are worth mentioning:

1. To be viable, I think declarative custom elements need dynamic templates, we'll need lots of consideration over the data model they have access to and the security implications.
2. `<style>` can't just be a child element outside of a template, at least without a new value for `type`, as it'll apply to the document. We need a solution for adopted style sheets with declarative shadow DOM, so hopefully we can share a solution there with something like `<style type="adoptable">`.
3. I don't think we should special case a "root" element in the shadow root, since we haven't yet. `:host()` isn't inconvenient, IMO. `:host([foo=bar])` is barely different than `div[foo=bar]`. CSS custom state and Accessibility Object Model should alleviate other pressures to have a root element.
4. For upgrades with a `<script>` tag we shouldn't need to require anything dynamic wrt the base class. Elements can extend `HTMLElement` and upgrade as they do now. For association between a script and a declarative definition we should be able to either use a default export for inline scripts, or have a new API to upgrade a declaratively defined element. We have an issue here now: https://github.com/w3c/webcomponents/issues/884

I think it'd be great to open more issues and discuss this more there and in upcoming meetings.

-- 
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/pull/897#issuecomment-712535024