WCCG in Declarative custom elements

[sashafirsov]

Declarative custom elements - teaser

Not a proposal. Here we could outline the purpose and goals. WIGC proposal would follow.

Description

Defines the convention of defining the custom elements via HTML tags.

It is a part of declaratively defined functional web application running even with JS script disabled.

Links

• WCCG Draft report
• HTML modules
• proposal PR by Westbrook
• Initial strawman Proposal
• Single File Component Explainer
• Cross-over with HTML Modules

Status

• list

Initial API Summary/Quick API Proposal

<template element="garden-treat">
    <slot name="icon">🍓</slot>
    <slot>berry</slot>
</template>
<garden-treat>peach<span slot="icon">🍑</span></garden-treat>

Key Scenarios

Simple template use in custom element. The template DOM reuse for same kind of data presented multiple times in UI.

Extended use is a templates library to be reused across multiple pages. This feature requires external resource reference and include into page. Like HTML include.

Live POC for inline and external template library.

Concerns

• functionality of original Custom Elements usually is defined by JavaScript which gives a full power for business logic of web application. In order to be sufficient the template concept should be extended to support explicit conditions( in current standard only positive text on slot name match is implemented), iteration over collection ( current implementation has only given order slot multiplication ) - needs order customization, transaction (TBD)
• support of page life cycle: load, (de-)hydration

Dissenting Opinion

• starter in WCCG

Related Specs

• Declarative Shadow DOM

Open Questions

• what is MVP. Static site?
• full implementation scope. Shopping cart app.

follow up proposals

• Functionally complete declarative templating, 2023-04
• DCE POC, 2023-03+

[43081j]

it may be better to not imply a shadow root, i.e.:

<template element="my-element" shadowroot="open">

or some such thing. otherwise it seems we'd be unable to register an element which has no shadow root.

don't have a use case for having no SR off the top of my head, but i feel like someone might have a reason to

[bennypowers]

Some discussion from the WCCG slack produced some ideas around syntax:

<template element="has-open-shadow" shadowroot="open">...</template>
<template element="has-closed-shadow" shadowroot="closed">...</template>
<template element="has-light-only">...</template>

Thanks @43081j

or perhaps, per @EisenbergEffect

<element tag="custom-element">
  <template shadowroot="open">...</template>
</element>

with maybe an extension to apply a javascript class:

document.querySelector('element')
  .define(class CustomElement extends HTMLElement {...})

We'd also like to make it clear that Declarative Custom Elements builds on Declarative Shadow DOM. They are not competitive proposals but complimentary.

[sashafirsov]

@EisenbergEffect , @bennypowers How the payload of DCE would be treated for those 3 cases?

1. simple payload

<element tag="custom-element">
  <a href="#">link 😃</a>
</element> 
<custom-element><i>🍋</i></custom-element>

2. payload with slot definition and slot value

<element tag="custom-element">
   <slot name="slot2"> 😃</slot>
    <h2 slot="slot2" >heading 2 😌</h2>
</element> 
<custom-element><i slot="slot2">🥕</i></custom-element>

3. same with template

<element tag="custom-element">
    <template shadowroot="open">
        <slot name="slot3"> 😃</slot>
    </template>
    <h3 slot="slot3">heading 3 😌</h3>
</element> 
<custom-element><i slot="slot3">🥕</i></custom-element>

The most natural interpretation is

1. just render content(link), ignore payload🍋.
2. treat content as template and apply slot2 : just 🥕, no shadow.
3. same as 2, but what to do with template sibling ?

[EisenbergEffect]

Per the original strawman proposal, I'm not sure what would happen because the element definition only has behavior for the template and script tags. Here's a link to that strawman: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md I'd like to put together a new proposal based on my research, because the original proposal is very inadequate, but it's going to take some time because there are a huge amount of details that need to be worked through.

[sashafirsov]

This strawman proposal looks like a dead lead, it has a final stage but no references to discussion channels. Any idea how this strawman become a thing and ask questions?

CC: @rniwa, @hax

[sashafirsov]

I'd like to put together a new proposal based on my research

would you mind to have a conversation on the high level goals of new proposal and scope?

[EisenbergEffect]

I think the strawman has mostly been ignored because folks realize it's too early to really do anything for declarative elements, since they are dependent on so many other features.

I'm always open to discussion on high level goals, etc. It might be best to just create an issue like this one and list them out from your perspective.

[justinfagnani]

I want to point out that declarative custom elements and declarative shadow DOM have no relation, except that declarative custom elements must not use <template shadowroot> in the template definition, as in:

<element tag="custom-element">
  <template shadowroot="open">...</template>
</element>

This would attach a shadow root to that specific <element> element, which is not useful in any way. A plain <template> will do.

Likewise, this:

<template element="has-open-shadow" shadowroot="open">...</template>

would attach a shadow root to whatever the parent of that <template> element is.

[justinfagnani]

I wonder why this feature is being discussed here rather than in https://github.com/WICG/webcomponents? I don't think it's going to be great if we fork the venues for proposals. Are we expecting browser vendors to participate here as well, or develop some consensus opinion to bring to WICG?

[sashafirsov]

why this feature is being discussed here

I guess it is question about priority. The declarative use of WC and around( custom elements, shadow root/template, binding, etc.) seems got enough attraction. The 5 years vision would include those features, disregarding of current maturity status.

If you propose to move into WICG, it is expected that alignment on long term vision is in place and we are ready to work on details instead of just base principles. I am trying to keep my discussion points around principles and architectural parts, unfortunately it has to be accompanied with understandable samples. Which look like a proposal, but are not. At least not yet.

Are we expecting browser vendors to participate here as well, or develop some consensus opinion to bring to WICG?

IMO the conceptual consensus has a sense to be shaped here first. And then could be exposed to vendors as part of review and vision.

I would expect the vendors are more keen on discussions related to syntax and API, not a concepts to fit with each other. May be I am mistaken, did not have a chance to work on WICG level. For the user (not a vendor), the influence in discussions there do not expect to be fruitful.

[sashafirsov]

@justinfagnani

custom elements and declarative shadow DOM have no relation

Correct, till the moment when slots become a part of declaration

<element tag="custom-element">
  <slot name="greet"> Hello </slot> World!
</element>
<custom-element><b slot="greet">👋</b></custom-element>

Would you treat the content as a shadow-less template? That is where the DCE(here) and Declarative Shadow DOM meet. If the standard would make a decision to respect slots, it would be same as implementing light DOM version of template ( Open styling of shadow roots ).

I.e. we have 3 concepts overlapping semantically. Not necessary by syntax which yet to be defined.

[sashafirsov]

one more POC for DCE: https://unpkg.com/[email protected]/demo/dce.html

[sashafirsov]

DCE as alternative to TEMPLATE with shadowroot implementation.

What can not be achieved by template and custom element stack now?

• true reuse of template DOM without cloning.
• no variations of scoping for css and data binding. shadowroot="open" implemented, no shadow is under discussion, but no namespace(library).
• slot content can not be applied to attribute ( teaser )
• slots with same name unsupported ( bug )
• conditions in template (again this is a declarative method )
• loops in template
• CRUD is not supported for CE registry ( bug )
• some other features like versioning, upgrading, façade/overriding, slot data binding, etc.

With complete new implementation all of above would not be subject for incremental upgrades and can be implemented without looking back to legacy. This way we would be able to create "true" templating which overcome the JS implementations as by performance as by memory.

With given syntax as a basis ?

<element tag="my-element">
  <slot name="greet"> Hello </slot> World!
</element>
<my-element><b slot="greet">👋</b></my-element>

CC: @justinfagnani

[caridy]

@sashafirsov There are some intersection semantics with https://github.com/rniwa/webcomponents/blob/add-dom-parts-proposal/proposals/DOM-Parts.md, specifically on the loops and attributes. If you need to stitch together the content that you want to pass down to a custom element as part of the light-dom, a template system is a lot more powerful that trying to open new APIs on custom elements directly. I'm also very much against opening new slotting mechanism for attributes, you can do that today by opening an attribute on the custom element itself, and observe that attribute to place the value in the right place inside your shadowRoot dom tree. cc @rniwa

[sashafirsov]

@caridy the Parts proposal covers only concept and API for parts implementation, not even JS but rather in browser engine level. Which is premature as the interface is not even defined. Here is a discussion on Declarative custom element syntax which (or proposals on declarative Template itself) meant to be the basis for referenced parts proposal.

The closest statement for the connection between slots and parts is a single expression

The browser engine can cache the result of parsing the template content and use that to efficiently generate template parts.

The Parts proposal is baked in mind of few and there is no public forum to shape it up. As result it is not useful in any way. Only a good peace I was able to grasp from there is a curly braces {mydata} as a shortcut to data binding. But there is no mention on how data could be expressed via HTML.

• In current TEMPLATE design it is via SLOTS. And extension the SLOT availability in attributes plus multile use of slot with same name.
• In HTML data also exposed via data- attribute and dataset node property.
• In FORM the form controls/inputs could be expressed as key-values as well.

The SLOT, dataset, form values are competing to be available via {mySlot}{datasetVar} syntax. The parts proposal does not give any useful way to operate with those via HTML, just C++ and some JS.

As stated, Declarative syntax has to be shaped first before going to low level implementation requirements which seems to happen with Parts.

Here is a proposal for slots based HTML syntax. Please address its weak and strong sides. The JS/API are not relevant and should be shaped once the business requirements set.

[sashafirsov]

My AC for Declarative Custom Element:

• should be self-sufficient. I.e. completely declarative syntax to support Declarative Web Application concept( no JS )
• support passing parameters/data
• support distribution of those into any part of DCE content definition. I.e. treat DCE content as generic template
• declarative events to data transformation binding.
• support MVP for templates with conditions, loops, multiple inserts of data into different parts of template.

"Any part" meant to be either

• HTML DOM or text insert ( slots only syntax?)
• Element attribute or attribute part ( just a text )
• data as output ( for example into value or dataset )

DCE also meant to work as a part of DCE collections(libs) and application, hence support

• distribution as independent module. I.e. declarative import syntax
• name mapping, i.e. to export own names with import renaming
• import of DCE collection ( HTML with related DCE )
• referenced via namespace to avoid libs naming collision.
• DCE imports compatible with import maps, i.e defined via symbolic name in app and mapped to distribution (NPM, CDN, etc) in app descriptor.

Note, the last item usually delegated to build toolchain. In Declarative Custom Element it has to be part of standard proposal as many DCE expected to have external dependencies and have to work natively in browser without dev toolchain.

[sashafirsov]

DCE PoC with template functionality for critique: https://github.com/EPA-WG/custom-element includes

• slots
• attributes via {}
• data- attributes/ dataset object.
• variables, loops, conditions

Implementation as of now covers 1st half of AC ^^. Use cases live demo

[sashafirsov]

The DX for DCE have jumped to another layer. Devtools plugin for POC now shows the template, data used for transformation, and their string presentation for step-by-step debugging of template.

That is a must feature to be supported in browser if template is capable of working with complex data, or condition/loop/import other templates logic as in POC. Ideally the step-by-step debugging better to be supported by devtools itself. Looking how to achieve XSLT debug within browser.

[sashafirsov]

The Functionally complete declarative templating is the 1st in series of DCE proposals. It covers the template aspect. The Declarative Custom Element proposal which is more straight match to this discussion would follow.