From 054fcf7ca54591c316451c23d3388d9b2c428acc Mon Sep 17 00:00:00 2001 From: Westbrook Johnson Date: Tue, 1 Oct 2024 09:01:16 -0400 Subject: [PATCH] Initial 2023 draft preparation (#74) * Initial 2023 draft preparation * Publish draft and clean up link rot * Expand on Cross Root Aria section * Add Scoped Custom Element Registries section content (#75) * Intro to CSS Slot Content Detection * Correct "last year" * More authors * Update status.html --------- Co-authored-by: Michael Warren --- .github/workflows/reports.yml | 4 +- reports/2022.html | 22 +- reports/2023.html | 622 ++++++++++++++++++++++++++++++++++ reports/status.html | 1 + 4 files changed, 637 insertions(+), 12 deletions(-) create mode 100644 reports/2023.html diff --git a/.github/workflows/reports.yml b/.github/workflows/reports.yml index ce97f91..959b427 100644 --- a/.github/workflows/reports.yml +++ b/.github/workflows/reports.yml @@ -3,7 +3,7 @@ on: pull_request: paths: ['reports/**'] push: - branches: ['main', 'report'] + branches: ['main', '2023'] paths: ['reports/**'] workflow_dispatch: {} @@ -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/2022.html b/reports/2022.html index df85d53..1b444c9 100644 --- a/reports/2022.html +++ b/reports/2022.html @@ -210,7 +210,7 @@

Children changed callback

Links

Previous WCCG Report(s)
-
2021
+
2021
GitHub issues:
    @@ -288,7 +288,7 @@

    Composed Selection

    Links

    Previous WCCG Report(s)
    -
    2021
    +
    2021
    GitHub issues:
    Selection APIs for Shadow DOM (main issue)
    Add getComposedRange to Selection
    @@ -373,7 +373,7 @@

    Constructable Stylesheets & adoptedStyleSheets

    Links

    Previous WCCG Report(s)
    -
    2021
    +
    2021
    GitHub issues:
    WICG/webcomponents#468
    Browser positions:
    @@ -452,7 +452,7 @@

    Cross-root ARIA

    Links

    Previous WCCG Report(s)
    -
    2021
    +
    2021
    GitHub issues:
    Cross-root ARIA Delegation
    Cross-root ARIA Reflection
    @@ -563,7 +563,7 @@

    CSS Module Scripts

    Links

    Previous WCCG Report(s)
    -
    2021
    +
    2021
    GitHub issues:
    WICG/webcomponents#759
    Browser positions:
    @@ -927,7 +927,7 @@

    Declarative CSS Modules

    Links

    Previous WCCG Report(s)
    -
    2021
    +
    2021
    GitHub issues:
    ---
    Browser positions:
    @@ -983,7 +983,7 @@

    Declarative custom elements

    Links

    Previous WCCG Report(s)
    -
    2021
    +
    2021
    GitHub issues:
      @@ -1105,7 +1105,7 @@

      Declarative Shadow DOM

      Links

      Previous WCCG Report(s)
      -
      2021
      +
      2021
      GitHub issues:
      https://github.com/whatwg/dom/issues/831
      Browser positions:
      @@ -1328,7 +1328,7 @@

      Form-Associated Custom Elements

      Links

      Previous WCCG Report(s)
      -
      2021
      +
      2021
      GitHub issues:
      https://github.com/whatwg/html/issues
      Browser positions:
      @@ -1787,7 +1787,7 @@

      Open styling of shadow roots

      Links

      Previous WCCG Report(s)
      -
      2021
      +
      2021
      GitHub issues:
      ---
      Browser positions:
      @@ -1843,7 +1843,7 @@

      Scoped Element Registries

      Links

      Previous WCCG Report(s)
      -
      2021
      +
      2021
      GitHub issues:
      WICG/webcomponents#716
      Browser positions:
      diff --git a/reports/2023.html b/reports/2023.html new file mode 100644 index 0000000..a208d97 --- /dev/null +++ b/reports/2023.html @@ -0,0 +1,622 @@ + + + + + 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, lacking initial prototype
      CSS Slot Content Detection + w3c/csswg-drafts#7922 + WICG/webcomponents#936 + w3c/csswg-drafts#6867 + Uncertain
      +
      +
      +
      +

      Cross-root ARIA

      +
      +

      Links

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

      Description

      +

      + This problem space is expertly described by Alice Boxhall in this blog post. +

      +

      + In short, accessibility with shadow roots in broken when addressed via the patterns that web developers have come to be acustomed to in their work. +

      +
      +
      +

      Status

      +

      + Implementors participating in bi-weekly Accessibility Object Model meetings with at the WICG have implied +

      +
      +
      +

      Key Scenarios

      +

      + This plays out in a Combobox pattern as follows: +

      + 
      +          
+            <x-label id="x-label">
+              #shadowRoot
+              | <label for="">Example Label</label>
+            </x-label>
+            <x-combobox id="x-combobox-1">
+              #shadowRoot
+              | <x-input>
+              |   #shadowRoot
+              |   | <input
+              |   |   role="combobox"
+              |   |   aria-expanded="true"
+              |   | />
+              | </x-input>
+              | <button aria-label="Open" aria-expanded="true">v</button>
+              |
+              | <x-listbox id="x-listbox-1">
+              |   #shadowRoot
+              |   | <div role="listbox">
+              |   |   <div role="option">Option 1</div>
+              |   |   <div role="option">Option 2</div>
+              |   |   <div role="option">Option 3</div>
+              |   | </div>
+              | </x-listbox>
+            </x-combobox>
+          
+
      +

      Even when leveraging the available aria attributes in this case there is no way to assocaite the x-label to the x-input or either of the [role="listbox"] or [role="option"] elements to it either.

      +

      Less complex patterns are similarly blocked by current APIs. Here we see a custom radio group:

      + 
      +          
+            <div role="radiogroup">
+              <x-button>
+                #shadowRoot
+                | <button role="radio"></button>
+              </x-button>
+              <x-button>
+                #shadowRoot
+                | <button role="radio"></button>
+              </x-button>
+              <x-button>
+                #shadowRoot
+                | <button role="radio"></button>
+              </x-button>
+            </div>
+          
+
      +

      Due to the shadow boundary and DOM element between the [role="radio"] element and the [role="radiogroup"] ancestor, there is no way to complete the accessibility tree that is needed to provide information about this interface to screen readers.

      +
      +
      +

      Initial API Summary/Quick API Proposal

      +

      Leveraging the Element Handles API the Combobox pattern would be work out as follows:

      + 
      +          
+            <x-label id="x-label" importhandles="label-for: x-combobox-1::handle(the-input)">
+              #shadowRoot
+              | <label for=":host::handle(label-for)">Example Label</label>
+            </x-label>
+            <x-combobox id="x-combobox-1">
+              #shadowRoot
+              | <x-input 
+              |   exporthandles="the-input"
+              |   importhandles="my-activedescendant: x-listbox-1::handle(active), my-listbox: x-listbox-1::handle(the-listbox)">
+              |   #shadowRoot
+              |   | <input
+              |   |   role="combobox"
+              |   |   handle="the-input"
+              |   |   aria-controls=":host::handle(my-listbox)"
+              |   |   aria-activedescendant=":host::handle(my-activedescendant)"
+              |   |   aria-expanded="true"
+              |   | />
+              | </x-input>
+              | <button aria-label="Open" aria-expanded="true">v</button>
+              |
+              | <x-listbox id="x-listbox-1">
+              |   #shadowRoot
+              |   | <div role="listbox" handle="the-listbox">
+              |   |   <div role="option" handle="opt1 active">Option 1</div>
+              |   |   <div role="option" handle="opt2">Option 2</div>
+              |   |   <div role="option" handle="opt3">Option 3</div>
+              |   | </div>
+              | </x-listbox>
+            </x-combobox>
+          
+
      +

      Leveraging the Aria Delegate API the radio group pattern could be acheived via:

      + 
      +          
+            <div role="radiogroup">
+              <x-button role="radio">
+                #shadowRoot shadowrootsemanticdelegate="button"
+                | <button id="button"></button>
+              </x-button>
+              <x-button role="radio">
+                #shadowRoot shadowrootsemanticdelegate="button"
+                | <button role="radio" id="button"></button>
+              </x-button>
+              <x-button>
+                #shadowRoot shadowrootsemanticdelegate="button"
+                | <button id="button"></button>
+              </x-button>
+            </div>
+          
+
      +
      +
      +

      Related Specs

      + +
      +
      +

      Open Questions

      +
        +
      • Which is the best way?
        • +
      • Can all problems be solves with one API or is the variance of issue requiring multiple APIs?
        • +
      +
      +
      + +
      +

      CSS Slot Content Detection

      +
      +

      Links

      +
      +
      Previous WCCG Report(s)
      +
      N/A
      +
      GitHub issues:
      +
      w3c/csswg-drafts#7922
      +
      WICG/webcomponents#936
      +
      w3c/csswg-drafts#6867
      +
      Browser positions:
      +
      ---
      +
      +
      +
      +

      Description

      +

      In shadow DOM, projection is the concept of placing an element into the light DOM and rendering it in a custom position via slots in the shadow DOM. This allows for greater control over the layout and styling of elements while also giving the user direct control over the contents and styling since the nodes are in the light DOM.

      +

      These are the current mechanisms in which to interact with slotted content:

      +
        +
      • ::slotted() pseudo element +
          +
        • It can take selectors and can only select directly slotted children and not their subtree.
          • +
        +
        • +
      • + A <slot> can also have children +
          +
        • Those children will only render if there is no slotted content assigned to that slot
          • +
        • Content can include any Node including a whitespace text node
          • +
        +
        • +
      +
      +
      +

      Status

      +
        +
      • No official or concrete browser positions.
        • +
      +
      +
      +

      Initial API Summary/Quick API Proposal

      +

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

      +
      +
      +

      Key Scenarios

      +

      Currently there is no CSS-only way to determine whether a <slot> has content assigned to it without requiring the consumer of a web component to explicitly state so.

      +

      Use Case Example

      +

      In the web component-based https://github.com/material-components/material-web, there is the Dialog component. The dialog component can have three sections slotted in:

      +
        +
      • slot=headline
        • +
      • slot=content
        • +
      • slot=actions
        • +
      +

      When the dialog’s content is slotted, the dialog must show a divider which is rendered in its shadow DOM. In essence the <md-divider> which is a sibling to <slot name=”content”> must be styled. e.g

      + 
      +          
+            <md-dialog has-content>
+              <template shadowrootmode="open">
+                <style>
+                  md-divider {
+                    display: none;
+                  }
+                  :host([has-content]) md-divider {
+                    display: flex;
+                  }
+                </style>
+                ...
+                <div class="content">
+                  <md-divider class="before"></md-divider>
+                  <slot name="content"></slot>
+                  <md-divider class="after"></md-divider>
+                </div>
+                ...
+              </template>
+            
+              <div slot="content">
+                Really long content ...
+              </div>
+            </md-dialog>
+          
+
      +

      The DX would be cleaner if has-content could be inferred by the CSS rather than the user having to apply it or JS having to run at runtime. +

      Using /slotted/ for the sake of example.

      + 
      +          
+            <md-dialog>
+              <template shadowrootmode="open">
+                <style>
+                  md-divider {
+                    display: none;
+                  }
+                  .content md-divider:has(~ slot/slotted/ *),
+                  .content slot:has(/slotted/ *) ~ md-divider {
+                    display: flex;
+                  }
+                </style>
+                ...
+                <div class="content">
+                  <md-divider class="before"></md-divider>
+                  <slot name="content"></slot>
+                  <md-divider class="after"></md-divider>
+                </div>
+                ...
+              </template>
+            
+              <div slot="content">
+                Really long content ...
+              </div>
+            </md-dialog>
+          
+
      +

      This removes the need for the user to declare that there is slotted content twice:

      +
        +
      • div[slot=content]
        • +
      • md-dialog[has-content]
        • +
      +
      +
      +

      Concerns

      +
        +
      • ---
        • +
      +
      +
      +

      Dissenting Opinion

      +
        +
      • ---
        • +
      +
      +
      +

      Related Specs

      +
        +
      • ---
        • +
      +
      +
      +

      Open Questions

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

      Declarative Shadow DOM

      +
      +

      Links

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

      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, multiple implementations
        • +
      +
      +
      +

      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.
        • +
      +
      +
      +

      Dissenting Opinion

      +
        +
      • N / A
        • +
      +
      +
      +

      Related Specs

      + +
      +
      +

      Open Questions

      +
        +
      • Mozilla would like to see more real world uses cases of Declarative Shadow DOM in the wild. GitHub has confirmed that they are using DSD and see many architectural benefits from it, especially for their design system. Although a polyfill exists, it comes as a bit of a catch-22 when trying to target pure SSR Web Components (HTML) use cases.
        • +
      +
      +
      +
      +

      Scoped Element Registries

      +
      +

      Links

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

      Description

      +

      When building a custom element, the current API is the `customElements.define(tagName, klass)` which takes a custom tag name and a JS class reference and globally registers a new custom element.

      +

      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

      + +
      +
      +

      Initial API Summary/Quick API Proposal

      + + +
      +
      +

      Key Scenarios

      +

      The issue with the current custom element definition approach is that there is only a single registry in the global space. Having a single global registry means also having the possibility of tag name or class collisions which will present problems when different released versions of the same custom element need to exist on a single HTML page at the same time.

      + +

      Design system use case

      +

      Design system teams are largely responsible for making standalone reusable components that can be consumed in all manner of applications across an organization. Design system components can be small and directed (something like `x-label` or coarse-grained like `x-accordion`). For DRY principles, it is often very desirable for large coarse-grained components to internally (in the shadow root render template) use smaller components to keep logic encapsulated.

      + +

      When a design system component internally uses a component that a consuming application also uses, a version conflict can arise. If the large component uses `x-small-component` version 1.0.0, and the application uses `x-small-component` version 2.0.0, the custom element tag names will be the same, and both versions will attempt to register in the global registry.

      + +

      The first element registered will "win". The second registration will fail. Whichever element "wins" will cause functional failures for either the application or design system component, depending on which component registration "wins".

      + +

      Micro-front end use case

      + +

      Micro-front-end architecture (MFE) is rising in popularity as a way to develop smaller pieces of what will be the final user-facing application, then assemble those pieces at runtime in some sort of shell application, service worker, etc. The micro-front-end architecture basically means that whole pieces of applications will be developed independently by separate probably-siloed teams then placed on the same page at runtime.

      + +

      When MFE remote component 1 uses a certain version of a component, and MFE remote component 2 uses a different version of that same component, and both attempt to register in the same global registry under the same tag name, version conflicts arise.

      + +

      If MFE 1 uses `x-component` version 1.0.0, and MFE 2 uses `x-component` 2.0.0, whichever component registration comes first "wins" and breaks the other MFE remote component. If 1.0.0 wins, then MFE 2 is broken because it is expecting 2.0.0 and use the 2.0.0 component API. Likewise, if 2.0.0 wins, MFE 1 breaks because it is dependent on the 1.0.0 component API which may not be supported in 2.0.0.

      +
      +
      +

      Polyfills

      + + +

      Mixin

      +

      The mixins below are offered as helper libraries to consume the polyfill implementation in an consistent, automated way.

      + +
      +
      +

      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..5f6ff52 100644 --- a/reports/status.html +++ b/reports/status.html @@ -60,6 +60,7 @@

      Web Components Community Group

      Spec/API Reports Table of Contents