WCCG in Declarative custom elements about webcomponents-cg HOT 19 OPEN

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?

from webcomponents-cg.

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.

from webcomponents-cg.

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.

from webcomponents-cg.

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.

from webcomponents-cg.

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

from webcomponents-cg.

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.

from webcomponents-cg.

@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 ?

from webcomponents-cg.

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

from webcomponents-cg.

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?

from webcomponents-cg.

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.

from webcomponents-cg.

@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.

from webcomponents-cg.

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

from webcomponents-cg.

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

from webcomponents-cg.

@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

from webcomponents-cg.

@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.

from webcomponents-cg.

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.

from webcomponents-cg.

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

from webcomponents-cg.

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.

from webcomponents-cg.

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.

from webcomponents-cg.