Functionally complete declarative templating #997
Comments
|
I wonder if |
|
Quite a bit of this overlaps with similar proposals, of which this is one, 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. 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/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. |
|
@bahrus , Shadow root The proposal is leaving the scoping with or without shadow root. POC gives the non-shadow root solution but could be altered to support various scopes once those clearly defined. I do not see the comprehensive proposal so far. No JS. This proposal is about pure declarative syntax of template, no JS involved. The declarative-first approach would allow to hook JS up but not be driven by JS, rather by browser engine. It would allow to run the page or microapplication inside with JS disabled option. The JS insulation and scoping would come as a part of microapplication container proposal separately. Custom Element syntax would come in separate proposal, it is a part of POC though. The syntax seems to be aligned with previous discussions but quite different from remote request props. Are not addressed in this proposal, good idea though as in dependent WICG proposal. In http-request part of POC for this proposal it is addressed in different declarative-first manner, i.e. via attributes without JSON kind syntax. But I agree that request parameters have to be configurable for all kind of content, not just for data layer as in POC. It worth a separate proposal. Would be glad to join the discussion or pair on creation. |
|
@keithamus , great idea, adding the fallback to proposal. loading and fallback. The "loaded" attribute by @bahrus is also a good idea. I would refer to the lifecycle of |
<template id="foo">Content</template> and <template ref="foo">Fallback content</template>
The <template src="url"> fallback</template> |
|
@bahrus ,
HTML modules are about the loading and content type. This proposal is about templating functionality and some syntax. They do not overlap much. HTML module can be used as template but also as string or a DOM. And template from this proposal could import (via XSLT or In case the HTML module would be capable of DOM and DOM streaming, it can be utilized efficiently by template. Have to review the related proposals to confirm or interfere. |
could you, please elaborate, perhaps with little sample? Not sure what you mean. |
|
Apologies, @sashafirsov , for jumping to the conclusion that I was addressing similar concerns as you with my POC link. I think I latched on to the little piece of your proposal that I thought I understood, without grasping the larger context. On a closer reading of your proposal, I think you are proposing something quite novel, with your desire to share a common reference to a template DOM node -- you envision being able to create something like "symbolic links" for DOM nodes, so that multiple DOM nodes that appear throughout the document can be "shared"? If I programmatically alter one "instance", it affects them all, because they are all one instance, really? If I'm understanding that correctly (probably not), that does seem like it could provide some radical performance improvements (but seems like a rather deep change with how the DOM works, but I'm no expert on that question). For the record, I jumped to the conclusion that this proposal was a bit less ambitious -- just laying out a formal mechanism for including HTML content from an external source. Within that context, the reason I think supporting having a separate template element that can be used to coordinate a client-side include (but ideally, the other link I provided, where the src/href is attached to the actual element where the include happens, would also be supported) is far more mundane -- I think it could make the decision whether to bundle or not to bundle much less of an ordeal going back and forth, in some scenarios where that question makes sense (in particular, when multiple DOM nodes are instantiated from the same template). So I agree, we were discussing apples and oranges. Anyway, thanks for presenting your ideas. |
yes, template DOM can and should be reused across multiple instances. The rendering can be optimized not to inject the whole DOM tree and re-render on each occasion instead of preserving between rendering cycles. The hydration of web components assumes that there is no guarantee the DOM would be constant say during the scroll, templating is another aspect of such dynamic behavior. Programming of web page in such highly dynamic DOM would be different than before as there is no such thing as "final DOM" and stable state. From another side it is not a dictated by the template semantics and syntax and would be up to platform to follow which would make an adoption easier. |
|
WCCG had their spring F2F in which this was discussed. Present members of WCCG identified an action item to take the topic of DOM Parts and break it out into extended discussions. You can read the full notes of the discussion (#978 (comment)) in which this was discussed, heading entitled "DOM Parts API". As this issue pertains to DOM parts, I'd like to call out that #999 has been raised for extended discussions and this topic may be discussed during those sessions. |
|
As this is conceptual and integral story, referencing particular issues with current templating |
|
Proposal related to relative and remote template loading: SRC attribute for Declarative Custom Element |
Part of Declarative Web Application stack proposals. Following discourse thread Fully functional declarative template.
Proposing the templating engine which would fit into "classic" template definition.
template as reusable resource
Once declared, the template could be used as is. Unlike TEMPLATE in custom element, it can be reused without the need to be cloned on each instance.
For example, template could comprise just SVG image. This image would be reused without re-instantiation on each template use.
ways to define
As the TEMPLTE element does not fit into requirements, it can not be used without significant update comparable with switching from
SCRIPTtoscript type="module". But the use of templating spread far beyond the inline template definition and as such theTEMPLATEalone is not sufficient. Here are some of template uses:id. As a template to be reused by other components.complete functionality
full data access
including data and input traversing as loop and in the depth, conditions, constants, and custom functions.
rendering
data injection as into final DOM and attributes. as into owned data layer.
data injection
The data
sliceis outlined separately. Its internal presentation is hidden, exposed over (XPath) selector inside of template.slicesamples:http-request,local-storage, and other DCE-compliant custom elements would emit the dataslice.slot
is a backward-compatible with SLOT in TEMPLATE. Internal implementation would treat named SLOT as own
slicemodular development with namespace insulation
has to be supported by template engine in order to be sufficient for "mature" platform which would include parts from different vendors and versions. XSLT does fit the bill with XML namespaces, modularity, custom functions, etc.
asynchronous & streaming
for embedded, low-RAM, or low-CPU is critical to be able to
XSLT 3.0 fits the bill with streaming on import of template and streaming the transformation output while the template is still loading.
no side effects
is the principle of Declarative Web Application itself and its components. The template should NOT bring external JavaScript and any another script which is capable to interact (change the state) with page and external elements. Only its content is subject for processing/modification.
POC
Most of proposed features can be polyfilled with current browser stack. You can try it withing the Declarative Custom Element
proof of concept
@epa-wg/custom-element
Is based on native in browser XSLT implementation, backward compatible with TEMPLATE+SLOTS, no shadow DOM. Does provide DX transparency on data layer and dev tools for debugging.
This description is going to be modified to reflect the input. The clone of previous content will be added to the thread for reference.
The text was updated successfully, but these errors were encountered: