From ad72fa880163c8c257f20e5bd8b82d74c5c3971a Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 4 Sep 2022 13:41:08 -0400 Subject: [PATCH 1/5] add introductory sections for browser parity and spec alignment callouts --- reports/2022.html | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/reports/2022.html b/reports/2022.html index a6e3d9d..40013d1 100644 --- a/reports/2022.html +++ b/reports/2022.html @@ -56,6 +56,25 @@

Introduction

The initial slate of APIs that browsers shipped with web components "v1" left many important features and use-cases on a future to-do list, to be finalized out after the core custom element and shadow DOM features landed. While the web components GitHub issues and face-to-face meets have tracked and discussed many of these features individually, there hasn't been a comprehensive overview of what's left to "finish" web components.

This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers.

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.

+
+

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. Filing in these gaps would be a big win for users and developers alike for a more predictable web.

+ +
+
+

Spec Alignment

+

The following specs we see as highly sought after within the developer community and just need a little more alignment across browsers from an implementation perspective. The alignment around these really unlocks from incredible potentials for Web Components, including techniques like Server-Side Rendering (SSR).

+ +

Table of Contents

From 5fa85c8dc17af1f2018601d99676e7e8c4ed663f Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 4 Sep 2022 13:41:51 -0400 Subject: [PATCH 2/5] fix some code formatting --- reports/2022.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/reports/2022.html b/reports/2022.html index 40013d1..3ec70e0 100644 --- a/reports/2022.html +++ b/reports/2022.html @@ -264,11 +264,11 @@

Initial API Summary/Quick API Proposal

The form-associated custom elements APIs are implemented within the attachInternals method on the HTMLElement prototype. Calling attachInternals returns an instance of an ElementInternals object which grants developers the ability to interact with form elements provided they designate their element as a form-associated element.

           
-    %gt;form>
-      %gt;fancy-input name="fancy">%gt;/fancy-input>
-    %gt;/form>
+    <form>
+      <fancy-input name="fancy"></fancy-input>
+    </form>
     
-    %gt;script>
+    <script>
       class FancyInput extends HTMLElement {
         static get formAssociated() {
           return true;
@@ -289,7 +289,7 @@ 
Initial API Summary/Quick API Proposal

         
         console.log(formData.get('fancy')); // logs 'I can participate in a form!'
       });
-    %gt;/script>
+    </script>

The setFormValue method can accept several types of data including strings, FileData and FormData objects, the latter of which can allow a nested form to participate with a parent in its entirety.

From 9f841863dd935cb422e7a96b754acb363dd2bdc6 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 4 Sep 2022 13:47:19 -0400 Subject: [PATCH 3/5] spec alignment phrasing --- reports/2022.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reports/2022.html b/reports/2022.html index 3ec70e0..39849e9 100644 --- a/reports/2022.html +++ b/reports/2022.html @@ -68,7 +68,7 @@

Browser Parity

Spec Alignment

-

The following specs we see as highly sought after within the developer community and just need a little more alignment across browsers from an implementation perspective. The alignment around these really unlocks from incredible potentials for Web Components, including techniques like Server-Side Rendering (SSR).

+

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.

From 17888ac328152976273cd6a834165bfa3917ff14 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 4 Sep 2022 20:06:27 -0400 Subject: [PATCH 5/5] fix spelling mistake --- reports/2022.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reports/2022.html b/reports/2022.html index f13dc7e..e7e22d4 100644 --- a/reports/2022.html +++ b/reports/2022.html @@ -58,7 +58,7 @@

Introduction

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.

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. Filing in these gaps would be a big win for users and developers alike for a more predictable web.

+

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.