Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add HTML Modules entry to the report #60

Merged
merged 1 commit into from
Sep 13, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 29 additions & 11 deletions reports/2022.html
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -1794,33 +1794,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>
Expand All @@ -1832,13 +1845,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>
Expand Down