[declarative-custom-elements] template language
Opened this issue · 0 comments
To be proposed on https://github.com/WICG/webcomponents/issues/new
Declarative Custom Element goals
The goal of DCE (Declarative Custom Element) is to register the custom element which behavior is defined DECLATATIVELY by default. Unlike in JS-driven behavior declaration in proposal #884 this proposal is about NO-JS , pure declarative syntax to be functional with JavaScript disabled.
Security and scope insulation
In order to be trusted within the page with disabled JS, DCE has to behave without side effects. I.e. all changes are self-concluded and no means to interact with external non-approved content available.
Data insulation and retention
The context of all data reside in the context root which by default is the DCE itself. If there is a need to work with external to DCE data, those are retrieved and copied inside, preserved sufficiently for the final render after which can be discarded. In case of single data source DCE would discard data slice immediately after final render into DOM.
MicroApplication and External resources use
The Web Application Manifest, which originally is designed for page level restrictions on data interactivity, have to be applicable on DCE level shaping the MicroApplication context. That is essential when embedding the DCE sourced from 3rd party vendor or in case of partial dependency coming from outside. It is up to page owner to decide whether to put DCE into walled garden. The shadow DOM is another layer of insulation and can be applied in order to guard the CSS layer.
Templating
In order to be sufficiently functional the templating in DCE need to be capable of
- using different data sources for conditions/ loop through/ rendering into HTML and web components and their attributes
Data variations
- DCE attributes
- DCE payload including slots
- various data sources like url parameters, history, local storage, or http request
- re-render DCE on data changes
As the functionally complete programming language templating has to
- support modules import ( with import maps URL resolving and local names mapping for exported names )
- call other templates and functions with parameters, define own functions
- capable of rendering DOM nodes with namespaces (SVG, MathML, etc. )
As of now the XSLT in browsers matches the ^^ criteria. With slight changes the XSLT 3.0 based template would be backward compatible with TEMPLATE with SLOT functionality.
The SLOT is the data in payload which already has a syntax to work with but other data sources still need to be defined and interact with template.
SLICE is the concept to work with data
The default
lifecycle
- Initial content
- 1st render
- data pending and changes
SDLC support
internal data preview
Browser plugin
debugging
via IDE, instructions TBD