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/shadow-dom-element@0.0.9/demo/dce.html