From a87657453c00e6e04d312c3e318a77730178f056 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 11 Sep 2022 14:19:21 -0400 Subject: [PATCH] add HTML Modules entry to the report --- reports/2022.html | 40 +++++++++++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 11 deletions(-) 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

    -
  • ---
  • +
  • What sort of "scope" should the imported HTML be allowed to have? Should it execute inline script tags?
  • +
  • What should the inline API look like for this?
  • +
  • How to treat the incoming HTML; as a Document? As a string? (see the scope concern above)
  • +
  • Would / should this align with the the import assertions spec, like with CSS Modules?