From 03b4834cf483fc9f6774b65ffc36e36a7f05ba23 Mon Sep 17 00:00:00 2001 From: Westbrook Johnson Date: Sat, 26 Aug 2023 14:36:19 -0400 Subject: [PATCH] Initial 2023 draft preparation --- .github/workflows/reports.yml | 2 + reports/2023.html | 431 ++++++++++++++++++++++++++++++++++ reports/status.html | 1 + 3 files changed, 434 insertions(+) create mode 100644 reports/2023.html diff --git a/.github/workflows/reports.yml b/.github/workflows/reports.yml index ce97f91..477be8a 100644 --- a/.github/workflows/reports.yml +++ b/.github/workflows/reports.yml @@ -21,6 +21,8 @@ jobs: destination: 2021.html - source: reports/2022.html destination: 2022.html + - source: reports/2023.html + destination: 2023.html steps: - uses: actions/checkout@v2 - uses: w3c/spec-prod@v2 diff --git a/reports/2023.html b/reports/2023.html new file mode 100644 index 0000000..e314846 --- /dev/null +++ b/reports/2023.html @@ -0,0 +1,431 @@ + + + + + Web Components Community Group: 2023 Spec/API status + + + + +
+

The following aims to support implementors in prioritizing, finalizing, and shipping new and agreed upon specifications in accordance with what is most needed by the web component developing community.

+
+
+

The 2023 report is currently being drafted.

+
+
+

Introduction

+

Web component features in the platform swing broadly from twinkle in someone's eye to just waiting for that last browser vendor to ship in the wild. Along that spectrum, there are a myriad of features that browser implementors and web developers could focus on and it's difficult to always align on which are most important. We, the Web Components Community Group, look to build on our work from 2021 and 2022 and continue to shed light on the priorities in this space as seen by developers conuming these features.

+

Taking the feedback from previous years to heart, we are drew out four features of the highest priority. Each are at different places on the spectrum of "ready to consume", and we look forward to working more closely with vendors in making progress towards that goal. The four features are listed below by status:

+
+

Seeking Browser Parity

+

We noticed the following specs already have a high degree of alignment from an implementation perspective, but support in browsers is still not equally distributed. Filling in these gaps would be a big win for users and developers alike for a more predictable web.

+ +
+
+

Seeking Initial Prototyping

+

The following specs have recieved a quality review at the proposal stage and are ready to be prototyped in browser. What sort of support could the Web Components Community Group lend to browser implementors as part of this process?

+ +
+
+

Seeking specification concensus

+

The following specs we see as highly valuable to the developer community for being able to deliver great web experiences to users when using Web Components. As it pertains to topics like Aria and SSR, these specs just need a little more alignment across browser implementors so that consensus can be achieved.

+ +
+
+

Table of Contents

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Feature or ProblemGitHub Issue(s)Status(?)
Cross-root ARIA + WICG/aom#169
+ WICG/aom#107
+ WICG/webcomponents#917
+ WICG/webcomponents#916 + 		Uncertain
Declarative Shadow DOMwhatwg/dom#831Concensus, lacking parity in implementation
Scoped Element RegistriesWICG/webcomponents#716Consensus
CSS Slot Content Detection + w3c/csswg-drafts#7922 + WICG/webcomponents#936 + w3c/csswg-drafts#6867 + Uncertain
+
+
+
+

Cross-root ARIA

+
+

Links

+
+
Previous WCCG Report(s)
+
2021
+
GitHub issues:
+
Cross-root ARIA Delegation
+
Cross-root ARIA Reflection
+
Browser positions:
+
---
+
+
+
+

Description

+

+ Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time. +

+

+ Developers of a custom element should be able to outline to browsers how content from outside of their shadow root realtes to the content within it and visa versa. Cross-root ARIA Delegation would allow developers to define how content on the outside is mapped to the content within a shadow root, while Cross-root ARIA Reflection would define how content within a shadow root was made available to content outside of it. +

+
+
+

Status

+

+ Implementors participating in bi-weekly Accessibility Object Model syncs with WICG have all been favorable to the delegation work and are interested in the reflection work as a tighly related API that maybe is a fast follower. Leo Balter is working on finalizing proposal text for the delegation API at which time Westbrook Johnson will apply similar teminology to the reflection API proposal. +

+
+
+

Initial API Summary/Quick API Proposal

+

Delegation API

+

HTML

+ 
+          
+            <span id="foo">Description!</span>
+            <template id="template1">
+              <input id="input" autoarialabel autoariadescribedby />
+              <span autoarialabel>Another target</span>
+            </template>
+            <x-foo aria-label="Hello!" aria-describedby="foo"></x-foo>
+          
+
+

JS

+ 
+          
+            const template = document.getElementById('template1');
+
+            class XFoo extends HTMLElement {
+              constructor() {
+                super();
+                this.attachShadow({ mode: "open", delegatesAriaLabel: true, delegatesAriaDescribedBy: true });
+                this.shadowRoot.appendChild(template.content.cloneNode(true));
+              }
+            }
+
+            customElements.define("x-foo", XFoo);
+          
+
+

Reflection API

+

HTML

+ 
+          
+            <input aria-controlls="foo" aria-activedescendent="foo">Description!</span>
+            <template id="template1">
+              <ul reflectariacontrols>
+                <li>Item 1</li>
+                <li reflectariaactivedescendent>Item 2</li>
+                <li>Item 3</li>
+              </ul>
+            </template>
+            <x-foo id="foo"></x-foo>
+          
+
+

JS

+ 
+          
+            const template = document.getElementById('template1');
+
+            class XFoo extends HTMLElement {
+              constructor() {
+                super();
+                this.attachShadow({ mode: "open", reflectsAriaControls: true, reflectsAriaActivedescendent: true });
+                this.shadowRoot.appendChild(template.content.cloneNode(true));
+              }
+            }
+            customElements.define("x-foo", XFoo);
+          
+
+
+
+

Key Scenarios

+

When developing many of the patterns outlines in the ARIA Authoring Practices Guide having this capability would allow for encapsulating responsibilities outlined by the `role` attribute in a shadow root.

+
+
+

Related Specs

+ +
+
+

Open Questions

+
    +
  • Should these two ideas can/should really ship separately? While the reflection API was ideated after the delegation API it may not be practical to separate them at the implementation/consumption level.
    • +
  • Is `delegation` and `reflection` the right name for these APIs? Particularly, "reflection" is used in ARIA Reflection.
    • +
  • There are non-ARIA attributes that would benefit from being supported by these APIs. Should they be drafted in a more general way?
    • +
+
+
+ +
+

CSS Slot Content Detection

+
+

Links

+
+
Previous WCCG Report(s)
+
N/A
+
GitHub issues:
+
---
+
Browser positions:
+
---
+
+
+
+

Description

+

---

+
+
+

Status

+
    +
  • ---
    • +
+
+
+

Initial API Summary/Quick API Proposal

+

Summary or proposal based on current status; paragraph(s) and code.

+
+
+

Key Scenarios

+

---

+
+
+

Concerns

+
    +
  • ---
    • +
+
+
+

Dissenting Opinion

+
    +
  • ---
    • +
+
+
+

Related Specs

+
    +
  • ---
    • +
+
+
+

Open Questions

+
    +
  • ---
    • +
+
+
+
+

Declarative Shadow DOM

+
+

Links

+
+
Previous WCCG Report(s)
+
2021
+
GitHub issues:
+
https://github.com/whatwg/dom/issues/831
+
Browser positions:
+
Chrome (Shipped)
+
Mozilla
+
Safari
+
+
+
+

Description

+

Declarative Shadow DOM is a mechanism to express Shadow DOM using only HTML, with no dependency on JavaScript, much like light DOM can be declaratively expressed today.

+
+
+

Status

+
    +
  • Partial consensus, some implementation
    • +
+
+
+

Initial API Summary/Quick API Proposal

+

Below is an example taken from the web.dev blog on Declarative Shadow DOM. + 

+            <host-element>
+              <template shadowroot="open">
+                <slot></slot>
+              </template>
+              <h2>Light content</h2>>
+            </host-element>
+
+

+
+
+

Key Scenarios

+

Server-Side Rendering: Without Declarative Shadow DOM, servers cannot deliver complete websites that include web component content. Markup cannot be efficiently delivered and then hydrated with JavaScript client-side.

+

JavaScript-less environments: Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled. Developers who are more comfortable with markup than with scripting may avoid shadow DOM altogether due to its tight coupling with JavaScript..

+
+
+

Concerns

+
    +
  • Mozilla considers this to be non-harmful, though debates the merits on ROI to developers weighed against the added complexity to be added to the HTML parser from a performance perspective.
    • +
  • Safari would like to see compatibility with Scoped Element Registry addressed first.
    • +
+
+
+

Dissenting Opinion

+
    +
  • N / A
    • +
+
+
+

Related Specs

+ +
+
+

Open Questions

+ +
+
+
+

Scoped Element Registries

+
+

Links

+
+
Previous WCCG Report(s)
+
2021
+
GitHub issues:
+
WICG/webcomponents#716
+
Browser positions:
+
+ +
+
+
+
+

Description

+

Scoped element registries allow custom element definitions to be scoped to one or more shadow roots. This allows the same tag name to be used with different implementations in different parts of the page, greatly reducing tag name collisions.

+
+
+

Status

+
    +
  • Chromium: prototyping
    • +
  • WebKit: ?
    • +
  • Mozilla: ?
    • +
+
+
+

Initial API Summary/Quick API Proposal

+

Summary or proposal based on current status; paragraph(s) and code.

+
+
+

Key Scenarios

+
    +
  • Building an app npm lbiraries that define elements. npm may duplicate packages and therefore custom element definitions.
    • +
  • Complex multi-team applications. Sub-teams often develop and deploy subsystems separately and may include multiple copies of libraries that define custom elements.
    • +
  • Complex elements with other custom elements as internal implementation detail. These elements may not want to take up names in the global registry for their sub-components.
    • +
  • Distributing elements via npm and CDNs. If both distribution methods are used on a page, one will error. npm usage can be directed to use scoped registries to avoid collisions.
    • +
  • Plug in systems. Plug-ins might bring their own custom element definitions which should not collide with the application or other plugins.
    • +
+
+
+

Concerns

+
    +
  • Interaction with declarative shadow DOM (addressed)
    • +
+
+
+

Dissenting Opinion

+
    +
  • None
    • +
+
+
+

Related Specs

+
    +
  • ---
    • +
+
+
+

Open Questions

+ +
+
+
+

+ This is required for specifications that contain normative material. +

+
+
+ + diff --git a/reports/status.html b/reports/status.html index b6c4a90..bc382a4 100644 --- a/reports/status.html +++ b/reports/status.html @@ -60,6 +60,7 @@

Web Components Community Group

Spec/API Reports Table of Contents