add browser parity and spec alignment sections

reports/2022.html

@@ -56,6 +56,25 @@ <h2>Introduction</h2>
       <p>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.</p>
       <p>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.</p>
       <p>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.</p>
+      <section>
+        <h3>Browser Parity</h3>
+        <p>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.</p>
+        <ul>
+          <li><a href="#form-associated-custom-elements">FACE (Form-Associated Custom Elements</a></li>
+          <li><a href="#constructable-stylesheets-adoptedstylesheets">Constructible Style Sheets</a></li>
+          <li><a href="#css-module-scripts">CSS Modules</a></li>
+          <li><a href="#imperative-slot-assignement">Imperative slots</a></li>
+        </ul>
+      </section>
+      <section>
+        <h3>Spec Alignment</h3>
+        <p>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.</p>
+        <ul>
+          <li><a href="#cross-root-aria">Aria</a></li>
+          <li><a href="#scoped-element-registries">Scoped Registries</a></li>
+          <li><a href="#declarative-shadow-dom">Declarative Shadow DOM</a></li>
+        </ul>
+      </section>
       <section>
         <h3>Table of Contents</h3>
         <table>
@@ -245,11 +264,11 @@ <h3>Initial API Summary/Quick API Proposal</h3>
         <p>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.</p>
         <pre>
           <code>
-    %gt;form>
-      %gt;fancy-input name="fancy">%gt;/fancy-input>
-    %gt;/form>
+    &lt;form>
+      &lt;fancy-input name="fancy">&lt;/fancy-input>
+    &lt;/form>
 
-    %gt;script>
+    &lt;script>
       class FancyInput extends HTMLElement {
         static get formAssociated() {
           return true;
@@ -270,7 +289,7 @@ <h3>Initial API Summary/Quick API Proposal</h3>
 
         console.log(formData.get('fancy')); // logs 'I can participate in a form!'
       });
-    %gt;/script>
+    &lt;/script>
           </code>
         </pre>
         <p>The <code>setFormValue</code> method can accept several types of data including strings, <code>FileData</code> and <code>FormData</code> objects, the latter of which can allow a nested form to participate with a parent in its entirety.</p>