For those of you who would like to take part in the March meeting of the Web Components Community Group, please share your availability here as we work to schedule the right day/time to gather. Don't forget, all WCCG events are listed on this calendar. 📆

The earlier in the month that we can meet, the more time we have for breakouts (like these) before we meet with implementors in April.

Some topics for conversation may come directly from the WICG/webcomponents#1031 (comment) that were gathered at the Q1 Face-to-face with implementors that happened this week. Anyone interested in supporting the completion of the Action Items should speak up below or on Discord. 🗒️

Please share your thoughts below as to subjects that you'd like to cover during the February meeting! 🙇🏼

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+

We should link to https://w3c.github.io/webcomponents-cg/ from here:

... and probably also from the README.

Now that all browsers support complex CSS selectors inside of :not(), what prevents the same within ::slotted() or :host()?

Browser announcements for reference:

• https://webkit.org/blog/3615/css-selectors-inside-selectors-discover-matches-not-and-nth-child/
• https://hacks.mozilla.org/2020/12/and-now-for-firefox-84/
• https://blog.chromium.org/2020/12/chrome-88-digital-goods-lighting.html

Naively, this seems like the same internals would go into both resolutions, so much so that the idea of not just getting deep children, but resolving cascades up to next shadow root seem like they should just come for free now.

Example:

<parent-element>
    #shadow-root
        <div class="wrapper">
            <child-element>
                #shadow-root
                    <style>
                        ::host(.wrapper *) {
                            color: blue;
                        }
                        ::slotted(.wrapper *) {
                            color: red;
                        }
                        ::slotted(p a) {
                            color: green;
                        }
                    </style>
                    <p>This should be blue.</p>
                    <slot></slot>
                <p>This should be red...</p>
            </child-element>
            <child-element>
                #shadow-root
                    <style>
                        ::host(.wrapper *) {
                            color: blue;
                        }
                        ::slotted(.wrapper *) {
                            color: red;
                        }
                        ::slotted(p a) {
                            color: green;
                        }
                    </style>
                    <p>This should be blue.</p>
                    <slot></slot>
                <p>This should be red...</p>
            </child-element>
        </div>
        <child-element>
            #shadow-root
                <style>
                    ::host(.wrapper *) {
                        color: blue;
                    }
                    ::slotted(.wrapper *) {
                        color: red;
                    }
                    ::slotted(p a) {
                        color: green;
                    }
                </style>
                <p>This should NOT be blue.</p>
                <slot></slot>
            <p>This should NOT be red... but, <a href="#">This should be green</a></p>
        </child-element>
</parent-element>

Use cases:
The ability to use :host(.wrapper *) aligns with the use of complex selectors on top of the idea of self references like :host([open]) etc. while allowing for the capabilities of :host-context() that never found footing outside of Blink, without the need for a completely new selector. This sort of functionality gives a component author the ability to outline specific realities about the delivery of their component is specific context. This is similar to how the details > summary:first-of-type element gets upgraded to have toggle UI: https://codepen.io/Westbrook/pen/QWGLdxP

This sort of .parent * resolving selector is interesting, and would seem like you'd want to apply it to content in a ::slotted() selector for all the same reasons, thought I do see how having the extended capabilities in the :host() selector outlined above would allow you to make this same ::slotted(.wrapper *) selection with :host(.wrapper *), in the case that we can't have it all. Certainly the more important addition of complex selecting in ::slotted() has to do with the ability to target styles on non-direct children.

A great power feature of an element with shadow DOM is its ability to encapsulate a world of both functionality and styles. Slotted content puts a really cool inside/out, outside/in twist on that. The ability to progressively enhance content with a custom element, turning vanilla content into vibrant content currently falls a little short when the encapsulated space can't really bring descendent content into the family without addressing it with styles from JS. While the content being slotted means we do have the means to style it from the outside, the benefit of slotting it into an element with shadow DOM should be that we're not required to. Imaging the child-element in the above example is an article or aside or callout that should take on a new background color when upgraded, without the ability to control the color of the anchor tag grandchild element it's possible that the content can become unaccessible without requiring advance knowledge of custom element usage (if a custom element and the :not(:defined) selector is even available) for a consuming developer to ensure that their content will be delivered appropriately.

It's possible that this issue belongs in https://github.com/WICG/webcomponents/issues, and I'm happy to move it if so. However, I wanted to start by asking this as an opportunity to learn about the possible reasoning behind the currently available APIs and gather community interest in the capabilities it unlocks before attempting to more formally position it as a proposal for standardization.

Reply here with a link and description of your concept to present on demo day. I'll update OP to list them:

• Tram-Deco - @JRJurman - A DCE implementation that leans on Declarative Shadow DOM, existing Web Component APIs, and has some affordances for external component definitions (nothing super close to HTML Modules, but would certainly benefited by it 😅).
• element-modules - @trusktr - Proof of concept of declarative custom elements that are importable from .html files or JS files, no build step or tooling needed, in an HTML-first format akin to component systems like Vue or Svelte with JS being optional.
• custom-element - @sashafirsov - Pure declarative DCE POC
• "HTML Modules and Declarative Custom Elements Proposal" - @EisenbergEffect
• define-element - @dy - Custom element to declare custom elements. (Similar to in SVG).
• heartml - @jaredcwhite - Define Heartml components entirely in JavaScript, in declarative Single-File Component HTML module files, or simply embedded directly in any HTML page.
• stampino-element - @justinfagnani - A web component for creating declarative web components. That is, defining web components entirely in HTML.

This is a conversation teaser, would be implemented in @epa-wg/custom-element, as TypeScript plugin to render typings and IDE support, as NPM module build target.

Goals

• support imports in DCE with declarative syntax

Provide functional pairing to JS modules imports with import default, particular/list of DCE , DCE tags mapping to local context.

• DCE imports to JS/TS modules

DCE exports compatible with imports by JS/TS code, DCE class as subject for export for further inheritance, use, registering tag, etc.

• CE import from DCE

As DCE works only on markup level, import semantics would be in registering of imported CE class to locally scoped registry.

• IDE syntax / suggestion / docs

When DCE imported as a tag in HTML, it should have full support as a code source with ability to jump to definition, docs on tag and parameters( name, description, def value, doc links ), validation on allowed/prohibited, attributes, attributes value by type.

Syntax

parity with JS import:

• default import

CE JS: import MyElement from "./my-element.js"

DCE from JS: import MyElement from "./my-element.html"

DCE from DCE

<custom-element tag="my-element" src="my-element.html"></custom-element>

CE from DCE

<custom-element tag="my-element" src="./my-element.js"></custom-element>

While JS import always expect the class as resolved module value, the DCE is content-type sensitive. If defined as attribute, it treates as a hint for build transformation. application/javascript would resolve module as CE, others would be treated as DCE DOM sources (SVG, HTML, XSLT,...)

• named import

CE JS: import {Element1, Element2 } from "./my-element.js"

DCE from JS: import {"id-1" as Element1, "id-2" as Element2} from "./my-element.html"

id is used for imported HTML as tag assumes to use registry, while import in JS does not use it.

DCE from DCE

<custom-element tag="element-1" src="my-element.html#id1"></custom-element>
<custom-element tag="element-2" src="my-element.html#id2"></custom-element>

implementation notes

• Typescript import plugin would generate the code to load DCE class without tag registration from HTML file or its part.
• DCE code would load the DOM from URL or DOM part if #id defined.
• IDE support is done by manifest and IDE-specific JSON generation

Now that both Mozilla and WebKit have standards position repos, and more recent specs have been implemented by multiple browsers, I think it would be useful to expand the status section to list each browser engine, like:

Status

• Chromium: implemented
• Firefox: position
• WebKit: position

• host on github pages
• content taken from meeting notes (https://docs.google.com/document/d/18xlVgmpN5JtMaoy6qzuwCQLvMj8FRb4SOdlY1892ctY/)
• can use Rocket with a default theme

For those of you who would like to take part in the December meeting of the Web Components Community Group, please share your availability here as we work to schedule the right day/time to gather. Don't forget, all WCCG events are listed on this calendar.

If you've topics that you'd like to have included in the December meeting, please comment below. Any additional information and/or pre-reading that you could share with fellow attendees would be much appreciated.

Ongoing meeting topics are as follows:

• preparation for the Q1 Face-to-Face with implementors
  • these are the topics from TPAC that we're looking to follow up on
  • ways that the CG can be more active in "landing" specs/APIs
• review of issues/PRs/etc submitted to the Community Protocols project
• longer future spec discussions for Face-to-face meetings with implementors later in 2024

While you're waiting, join the conversation on Discord!

Exports maps are now available in node & rollup & webpack.

Maybe we can have a convention/recommendation for what to define for web components? 🤔

Given the following component/package my-input;

src/MyInput.js
src/my-input.js
index.js

From a users point of view it would probably be nice to have imports like this:

import { MyInput } from 'my-input'; // <--- side effect free
import 'my-input/element'; // <--- side effect customElements.define(...)

This would lead to the following export map

"name": "my-input",
"exports": {
  ".": "./index.js",  // <--- side effect free
  "./element": "./src/my-input.js"
}

What do you think?

Sections we likely need:

• Abstract
• Introduction
• Impact
• Prioritization methodology
• Cross-cutting Themes

For impact we'd like to highlight the large and growing web component usage across the web. Show chromestatus.com number. Any improvements will have a large impact on existing users and open WCs up to new users.

For cross-cutting themes I could see a few areas:

• Re-enable existing HTML/DOM features that are restricted by shadow DOM
• Make WC features work without JS for SSR
• Open up WC usage to more developers - remove walls between WC-style development and global-style development.
• Thoughts on encapsulation: we've had a number of requests to either loosen encapsulation or make it a-la carte. These speak to a number of different potential usages of shadow DOM in particular, starting from what seems to be a base level of having a tree for internal DOM and composition - even without further encapsulation.

For those of you who would like to take part in the April meeting of the Web Components Community Group, please share your availability here as we work to schedule the right day/time to gather. Don't forget, all WCCG events are listed on this calendar. 📆

This will be our last session in preparation for the face-to-face with implementors on May 3rd. We can also use it for scheduling any breakout that should happen through the rest of May. 👥

It'll be great to sync on progress around user story generation and collection for Declarative Custom Elements and Open Styleable Shadow Roots. That leaves only a small number of action items from our last face-to-face not covered. 🥳

Please share your thoughts below as to subjects that you'd like to cover during the February meeting! 🙇🏼

We are nodeJS developers, right?
It would be nice to talk more about nodeJS, in relation to our development.

From our last community call, we thought that it might make more sense to put the status (e.g. Shipped / Not Shipped) with a direct link to the browser status page for said feature closer to the top of each spec entry.

Positions can come after, providing that longer form context, likely linking to a GitHub issue.

This was cleaned up in other PRs

Also, we have two _Link_ sections for the following specs 1. CSS Module Scripts - https://w3c.github.io/webcomponents-cg/2022.html#css-module-scripts 1. DSD - https://w3c.github.io/webcomponents-cg/2022.html#declarative-shadow-dom 1. Declarative CSS Modules - https://w3c.github.io/webcomponents-cg/2022.html#declarative-css-modules

so maybe something we should consolidate those?

At the risk of disrupting our WIP, we can save this task for when we get closer to presenting the finished report, and swap those two sections for each entry in the appendix.

Per #43 , just wanted to track all the items in the Appendix we would like to capture for our report in one place, that we can check off as they get added.

Discussions for all these are happening in #31

1. 🌟 Form-Associated Custom Elements - #42
2. 🌟 Cross-root ARIA - #46
3. 🌟 Constructable Stylesheets & adoptedStyleSheets - #50
4. 🌟 CSS Module Scripts - #58
5. 🌟 Scoped Element Registries - #51
6. 🌟 Declarative Shadow DOM - #45
7. Composed Selection
8. Declarative CSS Modules
9. Children changed callback - #40
10. Open styling of shadow roots
11. Declarative custom elements - #41
12. 🚫 Theming - #54
13. Styling children of slotted content
14. Custom CSS State - #56
15. 🌟 Imperative Slot Assignment - #55
16. 🚫 CSS Properties and values inside shadow root
17. Lazy custom element definitions - #41
18. DOM Parts - #41
19. HTML modules - #60
20. Custom Attributes - #41

• 🚫 - has no delegate / owner, or needs help
• 🌟 - featured as part of our #43

Accessibility is an easy nit to pick when discussing the potential usage of web components, and particularly shadow DOM, in a project. While shadow DOM is certainly not a requirement when working with custom elements, its benefits (functional and style encapsulation, the slots API, etc.) make it quite enticing. In this way, advancing the specification and implementation of the AOM across browser seems like a great place for this group to spend effort.

In the fall of 2020 there was an accessibility and WCs face to face to discuss Design questions about IDREF/Element attribute reflection, Element reflection and shadow roots, Allow setting default accessibility semantics for custom elements, and Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? . Read the meetings notes here. The general energy was that everyone was excited about moving forward these concepts, specifications, and APIs.

With this in mind, I wanted to open the conversation around how we could support/prepare for/inform these APIs at the community level.

@calebdwilliams has done some interesting work around polyfilling attachInternals() in support of form association that might be worth discussing as a basis for further work in this area: https://github.com/calebdwilliams/element-internals-polyfill @kevinpschaaf has the Polymer team made any concerted efforts in this area? Could this be a great way to continue the larger conversation of separating the https://github.com/webcomponents/polyfills story from its Google centric upbringing?

Having a formal place for this story to live will also go a long way to dispel the certainty that can be had in developers that shadow DOM "cannot be accessible". What sort of canonical reference can this community group offer as a sign post of the realities that have actualized over recent years and will develop over the next few years? Lower investment options could be building out the wiki and/or markdown structure of this repo. Higher investment could including deploying that markdown as part of this repos GitHub pages or possibly expanding into a more "known" property like webcomponents.org, etc.

Of particular interest as we begin to document practices is discussing how we might go about documenting what is possible now (by browser even) and clarifying the upcoming capabilities both spec'd and proposed in a way that can empower this community and its followers to lean into the specification development process enabling even better capabilities over the long term.

We need a document to submit pull requests against for the 2022 report. I think we should start from a fork of the 2021 report.

Perhaps this is trivial but I think having an available logo for Web Components would be helpful for developers who want to reference Web Components on websites, in documentation, etc.

For example I created a JavaScript library and set of Web Components and for all external libraries and tech I am able to use a Logo from the vendor. Since nothing like this exists for Web Components (at least I’m not aware of one) I ended up created my own SVG logo for it. And before first publishing the site over a year ago I recall spending many hours looking up Web Component Icons and what other sites were using and if there was an official version.

Example
https://www.dataformsjs.com/en/

From the last image above the JavaScript icon is not official but it is widely used so in a way it's become the de-facto standard.

Perhaps if it doesn’t make sense to create an official logo an generic widely used logo would be nice. For my logo I choose a simple gear design to represent Web Components.

SVG Image from above Screenshots

• https://www.dataformsjs.com/img/icons/web-components.svg
• https://github.com/dataformsjs/website/blob/master/public/img/icons/web-components.svg
• Image source is Sketch file in root of this project: https://github.com/dataformsjs/static-files

Overview

As a nod to the corresponding survey's for JS and CSS respectively, I wanted to open this issue to start a dialog around the value of having some sort of survey or focus group style effort come out of this group, either in parallel or sequential to, some of the content and branding related efforts being done around WC and webcomponents.org site.

Motivation

I was mostly inspired from the work we did to prepare our report, and coming out of our last meeting, thought maybe it would be useful to apply our methods to a larger audience? This could yield more direct anecdotal experiences from evaluators and consumers of WCs who are specifically not implementors or those of with direct ties to the group that prepared the report in the first place. Having this kind of information I think would not only be useful to use making tools, docs, etc in the space, but also to surface back up to implementors.

It could also help confirm / deny bias or perceptions that we in this group may have.

I also feel given WC are mostly spec / (developer) use case driven, there can be less of a tooling popularity contest aspect that often times feels like it creeps into surveys like this, which I think is useful for us in the sense that I feel a lot of our work aims to be as objective as possible to ensure that we're trying to focus limited time and resources on the most impactful efforts / pursuits, and thus maximize the payoff to the ecosystem and developer communities as much as possible.

Details

To get into a few specific just to help seed the conversation, here are some possible questions or "dialog funnels", as I like to think of them:

• Do you already use Web Components?
• What kind of projects are you building with WC?
• What is your favorite thing about using WCs?
• What is your least favorite thing about using WCs?
• Do you use only WCs for your projects?
• Do you use WCs as part of a design system?
• Are you using any (meta) frameworks to build and / or deliver your WCs?
• Are you using any WC component/ UI libraries or frameworks?
• What would you like to see from WC in the future?
• What would like you like to know more about with WCs?
• What resources help you best when using WCs?
• What resources do you think are missing for WCs?

As a general theme, I think having questions that are quick to answer, but also allow for an optional "share more information" box, could be a good strategy to get a broad range of responses? I am by no means a professional survey creator / marketer, just spitballing it all at the moment. 😊

Anyway, that's what I was able to jot down real quick, hope it's a good and useful conversation starter. Looking forward to thoughts and feedback. ✌️

Declarative custom elements should be sketched out as a way to verify that other specs that it depends on are suitable to use for it. This includes things like template instantiation's built-in syntax, declarative CSS modules, various element internals APIs, etc.

Greetings Web Components Community Group!

I would like to start an informal topic on the possibility of having native browser support a templating language, some widely used templating language examples:

• Mustache: https://mustache.github.io/
• Handlebars: https://handlebarsjs.com/
• Shopify Liquid: https://shopify.github.io/liquid/
• Django Templates: https://docs.djangoproject.com/en/3.1/topics/templates/
• Mozilla Nunjucks: https://mozilla.github.io/nunjucks/

I think there are a large number of applications and sites that are too complex for basic <template> with <slot> but do not need the full power of Virtual DOM or a large Frameworks and instead could be developed using simple templating if it were allowed in the browser without HTML. For example a simple reporting site where data is downloaded from a web service and needs to be displayed with custom formatting, or really any site that needs to download and display data from a JSON service.

There was in fact a proposal in 2017 from Apple related to this, but it doesn't appear to be trending in any sort of tech news so I'm not sure what the status is:

• https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md
• https://scotch.io/bar-talk/an-overview-of-the-most-exciting-proposals-for-the-web-platform-related-to-web-components

For my brief background I've been developing websites with JavaScript for a little over 20 years with Web Components for probably about a year and a half now. Basically I've worked with a wide range of JavaScript libraries, frameworks, and server side tech over the years. I am now using Web Components for Production facing SPA's at work and I'm happy to report its working out very well. No build process just simple <script> to include the components. I found at least one major challenge needed to make them work properly was the need for basic templating.

To provide a brief example, here is a snippet from a demo app showing geographic data I had developed. Originally I had developed a <json-data> component where I passed data to a <data-table> component using a custom data-bind attribute. The custom labels and fields attributes specify what fields would display on screen. However to make the demo work properly (add links, formatting, icons) I resorted to JavaScript that ran after the table was rendered. At that point I had felt I was better off using non Web Components because I was using more JavaScript on the Web Component sites.

<json-data url="https...">
    <data-table
        data-bind="countries"
        labels="Code, Name, Size (KM), Population, Continent"
        fields="iso, country, area_km, population, continent">
    </data-table>
</json-data>

<!-- Lots of JavaScript needed for formatting -->
<script>
// ...
for (const row of table.tBodies[0].rows) {
    const iso = (pageIso ? pageIso : row.cells[0].textContent.trim().toLowerCase());
    const flag = document.createElement('i');
    flag.className = iso + ' flag';
    row.cells[1].insertAdjacentElement('afterbegin', flag);
    // ...
}
// ...
</script>

Later I had updated it to use JavaScript Template Literals (Template String) in replace of a templating engine and that worked well because then it made it fast enough for me to customize the result just like if I were using templating or JSX. Example:

<data-table
    data-bind="countries"
    labels="Code, Name, Size (KM), Population, Continent">
    <template>
        <tr>
            <td><a href="#/regions/${iso}">${iso}</a></td>
            <td>
                <i class="${iso.toLowerCase()} flag"></i>
                ${country}
            </td>
            <td class="align-right" data-value="${area_km}">${format.number(area_km)}</td>
            <td class="align-right" data-value="${population}">${format.number(population)}</td>
            <td>${continent}</td>
        </tr>
    <template>
</data-table>
<!-- No JavaScript Needed -->

That works for simple templates, but if resulting layout needs some logic the templates become much more complex and the result looks somewhat like JSX. While this is fine for advanced developers or developers familiar with React/JSX I feel using template literals is not easy enough for wider use (example power users at work who can create web content but are not programmers); plus development is not as fast compared to using a templating language with supported logic (Handlebars, Liquid, etc).

<template id="image">
    <li>
        <img src="${escapeHtml(image.src)}" />
        ${image.isUploading === true ? '<div class="loading">' + i18nText('Uploading...') + '</div>' : ''}
        ${image.hasError === true ? '<div class="error">' + i18nText('Error') + '</div>' : ''}
        ${image.predictions.map(function(prediction) {
            return '<div class="' + resultClass(prediction.probability) + '">' + prediction.label + ' = <span>' + format.percent(prediction.probability, 5) + '</span></div>'
        }).join('')}
    </li>
</template>

The above snippet is from a demo page I made where I wrote the same app with different client side technologies. Below are Vue and Handlebars versions of the exact same code. In my opinion of these 3 the most readable is the Vue version. Although if browsers could support native templating I would prefer it to be more like Mustache/Handlebars/Liquid.

<!-- Vue -->
<li v-for="image in images">
    <img v-bind:src="image.src" />
    <div class="loading" v-if="image.isUploading" v-i18n="'Uploading...'"></div>
    <div class="error" v-if="image.hasError" v-i18n="'Error'"></div>
    <div v-for="prediction in image.predictions" v-bind:class="resultClass(prediction.probability)">
        {{ prediction.label }} = <span v-format-percent:5="prediction.probability"></span>
    </div>
</li>

<!-- Handlebars -->
{{#each images}}
<li>
    <img src="{{src}}" />
    {{#if isUploading}}
        <div class="loading">{{i18n 'Uploading...'}}</div>
    {{/if}}
    {{#each predictions}}
        <div class="{{js (concat 'model.resultClass(' this.probability ')')}}">
            {{this.label}} = {{formatPercent this.probability 5}}
        </div>
    {{/each}}
    {{#if hasError}}
        <div class="error">{{i18n 'Error'}}</div>
    {{/if}}
</li>
{{/each}}

Kind of a long topic, but I my opinion having standardized browser built-in templating would be very useful for a large number of sites and apps. Granted there are a lot of templating solutions developed both for regular JS and Web Components already in existence.

Does anyone know whatever happened with the Apple proposal or if there is anything planned related to templating?

Also if you have yourself come up with good templating solutions for complex apps or pages I would be very interested in hearing about it. For the moment when I develop with Web Components I'll be using JavaScript Template Literals, however it has too many limitations I feel for some apps.

At the WCCG's February Meeting (#77), we resolved to hold a breakout session specifically focusing on gathering use cases and proposals to present to implementors in the April Quarterly Face-to-face. Here we're looking to get this session scheduled and gather an agenda for the conversation.

If you'd like to participate, please use this link to share your availability between February 21st and February 28th for this session. It would be great to have a consensus meeting time by February 16th at the latest.

I know that @EisenbergEffect, @trusktr, @sashafirsov and more have some prototypes that could lead to solid proposals in this area...hope to see you there.

From our most recent meeting, I believe we came to a consensus on what the report structure for this year would be

1. I) Introduction - Motivations / Aspirations (can re-reuse existing text)
2. II) Browser Parity - Specs that just need that one final implementor to obtain ubiquitous cross-browser support. Will focus on the open questions for each one.
   • FACE
   • Constructible Style Sheets
   • CSS Modules
   • Imperative slots
3. III) Spec Alignment - Key specs we hope we to get cross-implementor buy-in on
   • Aria
   • Scoped Registries
   • Declarative Shadow DOM
4. IV) Appendix - All the specifications (any particular order?) - see #44

I figure we can use this a top level tracking ticket to update the report with each section, so maybe multiple folks could help put it all together.

For reference, here is the wiki for putting together SessionIdeas for TPAC.

Somewhat related maybe, but what about issues still open from last years report? Should we close them out and / or port them over to this year's report instead, if applicable?

For those of you who would like to take part in the February meeting of the Web Components Community Group, please share your availability here as we work to schedule the right day/time to gather. Don't forget, all WCCG events are listed on this calendar. 📆

Hitting the first week of the month puts us on schedule to have three sessions (February, March, and April) before the Q2 Face-to-face with implementors. 🤞🏼

Some topics for conversation may come directly from the Action Items that were gathered at the Q1 Face-to-face with implementors that happened this week. Anyone interested in supporting the completion of the Action Items should speak up below or on Discord. 🗒️

Please share your thoughts below as to subjects that you'd like to cover during the February meeting! 🙇🏼

The URL https://w3c.github.io/webcomponents-cg/ (listed at https://github.com/w3c/webcomponents-cg as the repo's homepage) still leads to the 2021 report. Should it be updated to point to the latest version at https://w3c.github.io/webcomponents-cg/2022.html?

Tracking item for gathering inputs, fields and requirements needed for submitting a session
https://www.w3.org/wiki/TPAC/2022/SessionIdeas
https://www.w3.org/2022/09/TPAC/#schedule

1. session name
2. session facilitators and speakers and which will be physically present vs remote
3. one sentence session summary
4. type of session: (e.g.: open discussion, talk, panel, tutorial, demo, etc.)
5. goals of session - what outcomes can session participants expect?
6. is this breakout only for TPAC participants or should it be open to anyone? (public TPAC breakouts can be attended remotely free of charge by anyone)
7. a shortname that can be used to associate an IRC channel to your breakout
8. Optional: constraints on timeslots (1:30pm, 3pm, 4:30pm Pacific Time)

First draft coming out of our last Community Call

1. Session Name - Web Components Community Group API and Specs Report 2022
2. Session facilitators and speakers and which will be physically present vs remote - Westbrook, Owen (others welcome!)
3. One Sentence Session Summary - After a brief introduction, the Web Components CG will facilitate a discussion with implementers and community members about filling browser gaps in agreed upon features, and moving forward with the next wave of top priority asks.
4. type of session: +open discussion+
5. Goals of session - what outcomes can session participants expect?
   • Getting APIs missing full x-browser support into the "Interop 2023" campaign?
   • Discuss how we can work more closely on high important capabilities: cross shadow root Aria, scoped registries, DSD
   • Expand implementer and developer partnerships around bringing APIs & specs to the browser.
6. Is this breakout only for TPAC participants or should it be open to anyone? public
7. A shortname that can be used to associate an IRC channel to your breakout - webcomponent-cg
8. Optional: constraints on timeslots: 4:30pm Pacific Time

At the WCCG's February Meeting (#77), we resolved to hold a breakout session specifically focusing on gathering use cases and proposals to present to implementors in the April Quarterly Face-to-face. Here we're looking to get this session scheduled and gather an agenda for the conversation.

If you'd like to participate, please use this link to share your availability between February 21st and February 28th for this session. It would be great to have a consensus meeting time by February 16th at the latest.

@bkardell has shared a project called Half-light that could be part of the agenda and is gathering feedback on it here.

@trusktr has gotten everyone started with gathering proposals for demonstration when we gather back for March breakout via #80. Here we'll work on scheduling for one or more sessions of this.

If you'd like to participate, please use this link to share your availability between March 11th and March 22nd for this session. It would be great to have a consensus meeting time by March 4th at the latest.

Beyond the list of demos being gathered above, be sure to check out the notes from February's breakout on the same topic available here.

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