DCE proposals matrix

[sashafirsov]

Declarative Custom Elements(DCE) has various POC and ideas on architecture and individual features.

Here is a list to be compared during demo day #80. The list meant to highlight the commonality/difference on each POC. As of now most of it is part of @epa-wg/custom-element implementation.

• element for DCE
  • use template as DCE declaration tag
  • new tag seen element and custom-element
  • allow any DOM element to become a DCE as long as it has tag or root attribute( tbd, shadowrootmode , etc.) as shadow is not only option discussed, the generic root is more appropriate IMO.
  • ?
• tag
  • tag as attribute for DCE element. Seems no disagreement.
  • scoping of the tag. Related to the scoped registries.
  • scoping implementing as part of DCE POC. _{Planned in @epa-wg/custom-element}
• src or other attribute for external template.
  • ability to pick any DOM-embeddable content like html, template, svg, mathML
  • ability to use non-DOM entities like PNG, video, etc. - need the content node override somehow, i.e. img tag
• hidden - enabled by default attribute to prevent declaration rendered in page, needed for legacy browsers
• template
  • use as payload root to prevent internal content execution. I.e. <style> should not be applied on page level; <script> is not executed.
  • optional use as DX convenience

parameters

Support for

• IDE suggestions
• HTML validation
• WYSWYG editors

Syntax

• <xsl:param> - with optional xsl namespace.
• name - parameter name, also DCE instanve attribute name
• value selection, select is a standard template parameter attribute for value selection.
• default value. See examples

Data injection

• syntax
  • standard (xslt) {} single curbed brackets
  • mustache double curved brackets
  • special tag like <xsl:value-of>
• slots support as in <template>, native is not working on standard level :(
• attribute names as default selector
• other data
  • dataset from data-xxx attributes
  • payload - content of instance payload including all slots
  • slice - internal elements value reflected in datadom/slice
• data storage
  • presented as data dom hierarchy to be accessed via query
  • query variations:
    • XPath
    • JS dot notation ( no operators and functions )
    • full JS
  • A declarative syntax compatible with serialization, needed for hydration
    • xml

      template

• slots support
• data binding
• conditions
• loop over data
• sub-routines(templates, functions)
• modules (import/export external)
• pipelining
• AOP, i.e. declarative override of specific data handling
• translation support
• localization support

Dynamic data manipulation and state change reflection

Sufficient set of functional components for simple app flows

• form validation, submission
• submission to local page and remore via XHR
• storage: localStorage, cookies, fs, etc.
• routing: location get/set, url parsing, assembling, etc.

events handling

reflect the event to state lead to UI re-render.

non-declarative syntax

• pure markup based
• hybrid DCE definition with inline <script> for exporting DCE class
• ?

[EisenbergEffect]

Things that may be missing:

• Not just parameters generically, but specifically:
  • attributes (including common patterns)
  • properties
  • context
• Custom states
• form association
• ARIA Mixin
• slot assignment mode
• light vs. shadow dom rendering
• focus delegation
• custom element registries
• named vs. default exports, and private module-level resources

[sashafirsov]

@EisenbergEffect , can you

• elaborate on parameters vs attributes.
• And explain what "context" means in DCE. We obviously understand that differently.
• how the general "state" differ from "custom state"?
• what is form associations - link if possible.
• ARIA mixin - link?
• slot assignment mode is it slotAssignment prop?
• custom element registries - should it be scoped registries instead?

[sashafirsov]

• import names mapping, functionally to match JS module import with local names(read tags) overriding.
• import maps compatibility

[EisenbergEffect]

@sashafirsov

• I don't know what "parameters" means. That was in your list. I'm referring to actual DOM constructs that I think should be supported, features of custom elements today, such as attributes and properties.
• When it comes to "context", I'm referring to the W3C CG's Context Protocol.
• For "state", I'm referring to the CSS Custom States usable via ElementInternals.
• For form association, I'm referring to the standard form association API for custom elements that we have today.
• For ARIA Mixin, that's the ARIA Mixin capabilities available via ElementInternals today.
• I'm not referring to the slotAssignment property. That is read-only. I'm referring to the slotAssignment configuration setting for Shadow DOM that we have today.
• Custom Element Registries is the same as scoped registries, yes.

I have attempted to take the features we have today in the imperative API for custom elements, things that have been discussed as W3C protocols (e.g. context), ongoing W3C standards efforts (e.g. DOM Parts), ongoing TC39 efforts (e.g. Signals), and make those the foundation of a declarative model for custom elements, while avoiding things that browser implementors said they won't/can't do. I am not trying to invent a bunch of new core features. There are gaps (template expression syntax), which I am trying to fill in. But on the whole, I'm mainly trying to figure out how we support our current imperative capabilities in a declarative fashion.

[sashafirsov]

• isolated option - no side-effect DCE