diff --git a/reports/2022.html b/reports/2022.html index 273d2fc..3436bbf 100644 --- a/reports/2022.html +++ b/reports/2022.html @@ -202,9 +202,9 @@

Table of Contents

HTML modules + WICG/webcomponents#645 - - + Partial consensus, no implementations Custom Attributes @@ -1794,33 +1794,46 @@

Links

Previous WCCG Report(s)
N/A
GitHub issues:
-
---
+
HTML Modules
Browser positions:
-
---
+
Chrome
+
Firefox
+
Safari

Description

-

---

+

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 import to load and initialize the template of a custom element, much in the same way CSS Modules would work for an adoptedStyleSheet.

+

Additionally, this could open up the concept of Single File Components (SFC) to the web.

Status

Initial API Summary/Quick API Proposal

-

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

+
+          import template from 'my-template.html' as HTMLTemplateElement;
+          
+          MyCustomElement extends HTMLElement {
+            constructor() {
+              const root = this.attachShadow({mode: 'closed'});
+              root.appendChild(document.importNode(template));
+            }
+          }
+        

Key Scenarios

-

---

+

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.

+

Additionally it will work great if you prefer to separate your technologies (e.g. my-component.(js|css|html) ), or your (CSS|HTML)-in-JS

in one file.

Concerns

@@ -1832,13 +1845,18 @@

Dissenting Opinion

Related Specs

Open Questions