Re: [w3c/webcomponents] HTML Modules (#645)

Thanks everyone for the feedback so far!  I want to address some points that were raised in the first round of comments.
 
1. @AshleyScirra, @annevk, @GrosSacASac, and @justinfagnani provided some feedback on import.meta.document.  There seem to be 3 possibilities: (A) Keep import.meta.document as in our original proposal, (B) Switch to import.meta.scriptElement with the same constraints, or (C) eliminate it altogether in favor of the approach below where a JS module re-imports its owner HTML Module as pointed out by @GrosSacASac:

**import.html:**
```
<template id="myTemplate">
  ...
</template>
<script type="module">
  import importDoc from "./import.html";
  let template = importDoc.getElementById("myTemplate");
  ...
</script>
```
  Approach B as pointed out by @justinfagnani makes sense if we expect an inline module to need access to its script element’s location.  Is that really a common pattern though?  This could be worked around with known ids, querySelector etc.  We had initially proposed (A) given that we expect access to the document to be the more common use case, and import.meta.document is shorter than import.meta.scriptElement.ownerDocument.  I’d like to learn a bit more about which we expect to be the common use case here.  Overall, import.meta.document seems like a developer convenience feature and could be eliminated to simplify the proposal.  We’re open to any of these possibilities at this point.

2. @AshleyScirra had a point on keeping HTML modules limited to static content.  I think that our proposal doesn't limit developers from adopting static-only content as a convention, but our preference is to not prevent devs from including a script module into an HTML module.  The example above wouldn't be possible, and the simplicity of being able to author a single file component that has declarative content seems like an appealing use case.

3. We're open to the idea that @jkrems brought up, where the HTML module exports elements based on id or an 'export' attribute.  However our main point in using inline scripts to create exports for an HTML module is that it addresses the "export pass through" problem.  If I want to author a single page widget that includes declarative content, then how can I import a JavaScript API from that widget?  The answer we're proposing is below... inline script exports have a new purpose when used in an HTML module.

**index.html:**
```
<script type="module">
    import {widgetAPI} from "./widget.html"
    widgetAPI.use()
</script>
```
**widget.html**
```
<template id="widgetTemplate">
   ...
</template>
<script type="module">
    let widgetAPI = ...
    export {widgetAPI}
</script>
```

4. @davatron5000: For that case a simple ```import "./import.html"``` would work.   The window.customElements.define call runs in main.html’s realm and thus ```<my-element>``` can be used in main.html without any other explicit plumbing.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/645#issuecomment-427534090