Use cases:

• <custom-element tag="dce-internal" src="#template1"> - reference the template in page DOM
• <custom-element src="#template2"></custom-element> - inline instantiation, no tag
• <custom-element tag="dce-external" src="toc.html"> - external file
• <custom-element tag="dce-hash" src="../index.html#shared-template"> - by ID in external file
• <custom-element tag="dce-hash" src="embed-1.html" > - external file with embedding of another external DCE
• <custom-element tag="dce-hash" src="../index.html#shared-template" > - deep external files, complex rendering
• own import maps
• deep external files with own import maps
• local template as a “loading…” or fallback for remote , error handling

More on the handling

Out of scope:

• DCE tag name
• DCE template

DCE as DWA container

The DCE is a container for Declarative Web Application which, of course can be run standalone. It would require the page itself be treated as template, the proposal is coming. In worst case the browser plugin, bookmarklet, and self-served polyfill would be provided as part of implementation/POC.

third party web page into a web component

The DWA purpose is to be embedded into 3rd party apps via DCE as a container. That is a main web 3.0 feature addressed by DWA/DCE. This proposal enables the DWA serving by DCE.

A thousand times, yes!!!

I have a few comments on this:

1. For concerns about security, perhaps url’s that aren’t relative (at a minimum) would have to pass through a “test” to make sure the web site has given a green light to the url: Either an import map or a link rel=preload path with an onerror attribute. I address that in more detail here . I realize this proposal is for purely declarative custom elements, but I think it should be extended to support elements with js dependencies (carefully).
2. Support for streaming declarative shadow DOM a must.
3. A strategy for bundling needs to be included, so that it is possible with a single modification to switchc between bundlind and not bundling. I suggest how that could be done here
4. Also, support for specifying loading=lazy.

I also think the ability to specify some snip criteria, to ignore some stuff that could allow the web component to act as a standalone page would be super. I support that here, and I can say from personal experience, that simple support makes developing a whole lot easier. Perhaps not optimal when deploying to production, at which it could be turned off during the build. But think of how many things we support in the browser for JavaScript developers, starting with supporting non-minified code. Maybe a little HTML love can be spared for us HTML-firsters?

The snipping ability could also be useful for turning a third party web page into a web component. Jquery’s load function supports snipping, in case there’s any doubt about the demand for that feature.

The Content Security Policy (CSP) would be responsible for cross-origin handling. That is a general security mechanism and not specific to DCE or template.

The streaming is more related to template parsing and is implementation specific. Browsers currently are capable of XML and HTML parsing using streaming, the transformation (mix of data and template) as streaming process is available on XSLT. But whether the template and transformer would be XSLT based yet to be defined and out of scope of this proposal.

The support for import maps is part of this proposal. But details including the bundled containers are out of scope for this proposal. It belongs to import maps itself.

support for specifying loading=lazy.

The hydration rules and life cycle are out of scope of this proposal. It would be addressed in separate proposal and include whole range of loading/rendering cases including not just the template but also the data.

allow the web component to act as a standalone page

The DCE is a container for Declarative Web Application which, of course can be run standalone. It would require the page itself be treated as template, the proposal is coming. In worst case the browser plugin, bookmarklet, and self-served polyfill would be provided as part of implementation/POC.

third party web page into a web component

The DWA purpose is to be embedded into 3rd party apps via DCE as a container. That is a main web 3.0 feature addressed by DWA/DCE.

Sounds promising.