Re: [WICG/webcomponents] Functionally complete declarative templating (Issue #997)

Quite a bit of this overlaps with [similar proposals, of which this is one](https://github.com/bahrus/templ-mount), but syntax wise this is as good as if not better than that one.  I like the way the url can be added to the include tag as an alternative to the template tag.  That puts it more in line with [this proposal](https://github.com/WICG/webcomponents/issues/863).  So supporting both would make us both happy.

But I do want to chime in that the ability to declaratively make the loading lazy, like images, and iframes, would be quite beneficial (loading="lazy").  Also, streaming support is crucial, but perhaps it should be optional (I don't have a strong reason for preferring opt-in vs opt-out).  The reason being that unless a way is provided to adjust the content as it streams (which XSLT 4 might provide), then there would be some circumstances where we would optionally want to insert dynamic data before it lands in the live DOM.  Also, the ability to specify different "sandboxing" levels, similar to iframes (maybe using the syntax of the [setHTML](https://developer.mozilla.org/en-US/docs/web/api/element/sethtml)/parseHTML options?)

I also wonder if it makes sense to allow the include tags to reference id's of templates within the ShadowDOM, or even traverse up the ShadowDOM hierarchy for a matching id, rather than all such definitions be in the head or body tags?

I assume with your mention of slots, that this proposal would allow us to specify whether the streamed/downloaded include should go into the light children / shadow DOM?  

Would this proposal be meant as a very useful "side-effect" of HTML Modules, or be treated independently?  In my view, getting something like this going without delay could potentially be one of the most significant ways we can help developers achieve acceptable performance as the application grows, so should be priority uno (if reducing carbon emissions / poverty is of any interest to the powers that be :-) ).  Not to mention the other apparent side-effect of making the barrier to entry for new developers easier, it seems.

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

Message ID: <WICG/webcomponents/issues/997/1496648702@github.com>