add HTML Modules entry to the report

Author: thescientist13

reports/2022.html

@@ -202,9 +202,9 @@ <h3>Table of Contents</h3>
             </tr>
             <tr>
               <th><a href="#html-modules">HTML modules</a></th>
+              <td><a href="https://github.com/WICG/webcomponents/issues/645">WICG/webcomponents#645</a></td>
               <td></td>
-              <td></td>
-              <td></td>
+              <td>Partial consensus, no implementations</td>
             </tr>
             <tr>
               <th><a href="#custom-attributes">Custom Attributes</a></th>
@@ -1762,33 +1762,46 @@ <h3>Links</h3>
           <dt>Previous WCCG Report(s)</dt>
           <dd>N/A</dd>
           <dt>GitHub issues:</dt>
-          <dd>---</dd>
+          <dd><a href="https://github.com/WICG/webcomponents/issues/645">HTML Modules</a></dd>
           <dt>Browser positions:</dt>
-          <dd>---</dd>
+          <dd><a href="https://chromestatus.com/feature/4854408103854080">Chrome</a></dd>
+          <dd><a href="https://mozilla.github.io/standards-positions/#html-modules">Firefox</a></dd>
+          <dd><a href="https://webkit.org/status/#feature-html-import">Safari</a></dd>
         </dl>
       </section>
       <section>
         <h3>Description</h3>
-        <p>---</p>
+        <p>HTML Modules would provide a means of referencing HTML through the web's module system.  For Web Components specifically, this would allow the usage of <code>import</code> to load and initialize the template of a custom element, much in the same way <a href="#css-module-scripts">CSS Modules</a> would work for an <code>adoptedStyleSheet</code>.</p>
+        <p>Additionally, this could open up the concept of <a href="https://github.com/WICG/webcomponents/issues/645#issuecomment-343601237">Single File Components (SFC)</a> to the web.</p>
       </section>
       <section>
         <h3>Status</h3>
         <ul>
-          <li>---</li>
+          <li>Chrome (shipped, but not aligned with ESM)</li>
         </ul>
       </section>
       <section>
         <h3>Initial API Summary/Quick API Proposal</h3>
-        <p>Summary or proposal based on current status; paragraph(s) and code.</p>
+        <pre class="javascript">
+          import template from 'my-template.html' as HTMLTemplateElement;
+          
+          MyCustomElement extends HTMLElement {
+            constructor() {
+              const root = this.attachShadow({mode: 'closed'});
+              root.appendChild(document.importNode(template));
+            }
+          }
+        </pre>
       </section>
       <section>
         <h3>Key Scenarios</h3>
-        <p>---</p>
+        <p>The primary motivation for HTML Modules is to round out ESM so that all of the three main web languages (HTML / CSS / JS) can be leveraged through a module system.  For Web Components, this is especially helpful for scenarios related to Server Side Rendering or any form of templating, static or otherwise.  Having a common mechanism in JavaScript to author and use Web Components makes for a great experience all around.</p>
+        <p>Additionally it will work great if you prefer to separate your technologies (e.g. <em>my-component.(js|css|html)</em> ), or your (CSS|HTML)-in-JS</p> in one file.
       </section>
       <section>
         <h3>Concerns</h3>
         <ul>
-          <li>---</li>
+          <li>Main concern is that now that ESM and Import Assertions are a thing, it is recognized that the proposal for HTML Modules needs to be re-drafted accordingly.</li>
         </ul>
       </section>
       <section>
@@ -1800,13 +1813,18 @@ <h3>Dissenting Opinion</h3>
       <section>
         <h3>Related Specs</h3>
         <ul>
-          <li>---</li>
+          <li><a href="#css-module-scripts">CSS Modules</a></li>
+          <li><a href="#declarative-shadow-dom">Declarative Shadow DOM</a></li>
+          <li><a href="#declarative-custom-elements">Declarative Custom Elements</a></li>
         </ul>
       </section>
       <section>
         <h3>Open Questions</h3>
         <ul>
-          <li>---</li>
+          <li>What sort of "scope" should the imported HTML be allowed to have?  Should it execute inline script tags?</li>
+          <li>What should the inline API look like for this?</li>
+          <li>How to treat the incoming HTML; as a <code>Document</code>?  As a string? (see the scope concern above)</li>
+          <li>Would / should this align with the the import assertions spec, like with CSS Modules?</li>
         </ul>
       </section>
     </section>